Re: [cross-project-issues-dev] Lucene version problem for DTP

[Brian Payton <bpayton@xxxxxxxxxx>]

OK, a version range of "[0.0.0,3.0.0)"
appears to work for unspecified package versions.  (Apparently the
unspecified version is assumed to be 0.0.0.)  Thanks!

Brian Payton
DTP PMC Lead
Data Tools Development
IBM Silicon Valley Laboratory





From:      
 David M Williams/Raleigh/IBM@IBMUS
To:      
 Cross project issues
<cross-project-issues-dev@xxxxxxxxxxx>
Date:      
 01/14/2011 12:55 PM
Subject:    
   Re: [cross-project-issues-dev]
Lucene version problem for DTP
Sent by:    
   cross-project-issues-dev-bounces@xxxxxxxxxxx

---

I think, not that I've tested it, you can use 0 as lower
bound 
[0,3.0.0) 
if all you are trying to do is "wall off" higher future versions.

(But, admittedly is not as good as having a versioned package, and not
sure what else this might expose you to). 

Good luck! 





From:        Brian
Payton/Santa Teresa/IBM@IBMUS 
To:        Cross
project issues <cross-project-issues-dev@xxxxxxxxxxx>
Date:        01/14/2011
02:20 PM 
Subject:        Re:
[cross-project-issues-dev] Lucene version problem for DTP
Sent by:        cross-project-issues-dev-bounces@xxxxxxxxxxx

---

OK, I've changed the manifest to use Import-Package for Lucene instead
of Require-Bundle.   

One thing bothers me though.  Following recommended OSGi practice,
I tried to specify version ranges for the Import-Package statements (ie,
version="[1.9.1,3.0.0)").  However, I can't in this case,
because while Lucene 2.9.1 specifies version ranges for its packages, Lucene
1.9.1 does not, so I get unsatisfied version constraint errors when building
with Eclipse 3.6.1. 

The version range is relevant because Lucene 3.x will be removing deprecated
classes, one of which we happen to use.  Is there a way to specify
a version range that encompasses the case of versions not specified?

Brian Payton 
DTP PMC Lead
Data Tools Development
IBM Silicon Valley Laboratory





From:        "Oberhuber,
Martin" <Martin.Oberhuber@xxxxxxxxxxxxx>
To:        Cross
project issues <cross-project-issues-dev@xxxxxxxxxxx>
Date:        01/14/2011
09:39 AM 
Subject:        Re:
[cross-project-issues-dev] Lucene version problem for DTP
Sent by:        cross-project-issues-dev-bounces@xxxxxxxxxxx

---

BTW, 
 
I noticed that with Lucene 2.9, the format of pre-built index has changed.
 
This means: any documentation plugins that ship with a pre-built index
(typically built using the Eclipse 3.6 basebuilder today) but then run
against Eclipse 3.7 will need to have their index re-generated on performing
a doc search the first time. Rebuilding the doc index can take in the range
of 15 minutes on a large installation, and can create files of several
MB size in the config area / user's home directory in a shared read-only
installation. Which leads to very bad end user experience when performing
the first search! 
 
A couple learnings from this: 
- For the Indigo Release, we'll want to ensure that Projects use a 3.7
based basebuilder early enough such that their prebuilt index has the new
Lucene format. 
- When upgrading to Lucene 3.0 is considered (and assuming that 3.0 uses
yet another index format than 2.9) it's probably better doing that now
than forcing yet another migration step on consumers in the future.
- Consider testing / documenting a scenario where the 2.9 Lucene Index
can be added to existing old doc plugins with 1.9 index through fragments
(like NL fragments) 
- Consider testing / documenting a script that builds the doc index for
an entire installation from commandline at end user's site (ie as part
of an install program), in order to avoid the 15-minute-delay for the end
user when he wants to search docs the first time 
 
Thanks, 
-- 
Martin Oberhuber, Senior Member of Technical Staff, Wind
River 
direct +43.662.457915.85  fax +43.662.457915.6

---

From: cross-project-issues-dev-bounces@xxxxxxxxxxx
[mailto:cross-project-issues-dev-bounces@xxxxxxxxxxx]
On Behalf Of Chris Goldthorpe
Sent: Donnerstag, 13. Jänner 2011 22:32
To: Cross project issues
Subject: Re: [cross-project-issues-dev] Lucene version problem for
DTP

I can give some background 

https://bugs.eclipse.org/bugs/show_bug.cgi?id=248986
is the bug that tracked upgrading to Lucene 2.9 
Before the upgrade to 2.9.1  happened there was a lot of discussion
about whether the API changes between Lucene 1.x and 2.x would impact clients
and we ended up convincing ourselves that clients would be able to adapt
to the change with little or no disruption.On a related topic a Bugzilla
was just filed -  https://bugs.eclipse.org/bugs/show_bug.cgi?id=334305
requesting that we move to Lucene 3.x. 

One thing I had not anticipated was that splitting the Lucene class files
 into three bundles rather than two would cause any issues. Lucene
2.9.1 was already in the Orbit repository before the SDK switched to using
it for the help system so I'm not aware of why it went from two bundles
to three. 

Have you tried creating an optional dependency to  org.apache.lucene.core?

Chris 



From:        Brian
Payton/Santa Teresa/IBM@IBMUS 
To:        Cross
project issues <cross-project-issues-dev@xxxxxxxxxxx>
Date:        01/13/2011
12:33 PM 
Subject:        [cross-project-issues-dev]
Lucene version problem for DTP 
Sent by:        cross-project-issues-dev-bounces@xxxxxxxxxxx

---

Greetings Eclipse project leads, 

We (the DTP project PMC) would like to call on the collective wisdom of
the Eclipse projects. 

DTP is having a runtime problem with the versions of Lucene (org.apache.lucene)
that are shipped with Eclipse.  Eclipse versions up to 3.6 included
Lucene 1.9.1.  In Eclipse 3.7, however, the Lucene plugin versions
jumped to version 2.9.1.  As part of the version change, the main
Lucene plugin (org.apache.lucene) was restructured so that its content
moved into a new plugin named org.apache.lucene.core.

DTP makes use of Lucene services to implement one of its views, the SQL
Results view.  When run against Eclipse 3.7, the SQL Results view
does not open because the required Lucene classes cannot be found.

We build both of the current versions of  DTP (v1.8.2  for the
Helios release train and v1.9 the Indigo release train), against Eclipse
3.6.1.  We prefer building on an earlier, known stable Eclipse release
to provide flexibility for our adopters, who sometimes want to get the
latest version of our project without upgrading their Eclipse base.  And
up to now this hasn't been a problem; we have been able to run our DTP
builds on "the next version" of Eclipse, because the binary compatibility
has been good.  With Lucene in Eclipse 3.7 however, this appears to
be no longer the case. 

We would appreciate suggestions on how to address this.  Has any other
project had to deal with this issue, or a similar one?  

Regards,

Brian Payton 
DTP PMC Lead
Data Tools Development
IBM Silicon Valley Laboratory
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev