Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cross-project-issues-dev] Lucene version problem for DTP

FYI, bundling the Lucene 1.9.1 plugin from Orbit with the DTP distribution solved the runtime problem.  We set our version range for plugin org.apache.lucene to [1.9.0,2.0.0) and Chris Goldthorpe set the corresponding version range in the Eclipse platform to [2.9.0,3.0.0) (thanks, Chris) and it seems to be working fine.

Regards,
Brian

Brian Payton
Data Tools Development
IBM Silicon Valley Laboratory





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




The next thing we are going to try is to bundle the old version of the Lucene plugin org.apache.lucene with DTP.  I believe that if DTP (and the platform) set our version ranges correctly, then we will each pick up the needed version of the plugin.

Regards,
Brian

Brian Payton
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/18/2011 08:01 PM
Subject:        
Re: [cross-project-issues-dev] Lucene version problem for DTP
Sent by:        
cross-project-issues-dev-bounces@xxxxxxxxxxx




I doubt this will help in every case, maybe not even in very many cases, but might be worth a try ... depends on Lucene, I guess ... my intuition is if you want something to run on several streams, and you have a choice, you'd normally want to build on the most forward version (Lucene 2.9), and then run/test against the older one (Lucene 1.9). The reason being is that some providers might provide some logic or code that preserves backwards compatibility ... but pretty hard to provide forward compatibility ... and after all, they did change major versions. Of course, you'd have to be extra careful then not to use new API, in newer Lucene, but not in older version. For true binary compatibility, this isn't required, but ... not sure if Lucene said they were binary compatible?

Also, it is not that uncommon to combat compatibility issues with reflection and/or catching exceptions like "class not found" and then doing something else when the class is not found.

Of course, there's 101 ways these compatibility issues can arise (especially if Lucene has any of its own class loaders?) so doubt there is any easy solution and my comments may not be applicable to your case. You might open a bug with a simple test case demonstrating the problem?  You might also ask/search on the Lucene  forum's? Its still unclear to me if this is a Lucene level problem ... or an OSGi/Orbit level problem.

Good luck,



.




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




It is a binary compatibility issue.  When I build against Eclipse 3.7, everything works fine.  However, we build DTP 1.8.2 and 1.9 against Eclipse 3.6.1 and just test and run against Eclipse 3.7.

Brian Payton
DTP PMC Lead

Data Tools Development
IBM Silicon Valley Laboratory






From:        
Chris Goldthorpe/Beaverton/IBM@IBMUS
To:        
Cross project issues <cross-project-issues-dev@xxxxxxxxxxx>
Date:        
01/18/2011 10:22 AM
Subject:        
Re: [cross-project-issues-dev] Lucene version problem for DTP
Sent by:        
cross-project-issues-dev-bounces@xxxxxxxxxxx




I'm wondering if there is a binary compatibility between Lucene 1.x and 2.x that is causing problems for you. Have you tried building against Eclipse 3.7M4 or later and if so do you still see problems at runtime when loading Lucene classes?


Chris




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




Unfortunately, while everything built OK with the Import-Package statements, when I tested the DTP build against Eclipse 3.7, I found that it does NOT solve the problem.  I still get the same runtime error of the Lucene class not found.


I tried it both with and without version ranges, and that made no difference.


I then tried using an optional Require-Bundle entry for the org.apache.lucene.core plugin.  Still no joy.  I tried it both with and without the Import-Package statements.


Perhaps there's something special about how the restructured Lucene packages are "forwarded" from the original org.apache.lucene to org.apache.lucene.core.  Or perhaps the problem is due to the "split" packages in org.apache.lucene.core.


I'd appreciate any further ideas that people might have.  I'm kind of stuck now.

Brian Payton

DTP PMC Lead
Data Tools Development
IBM Silicon Valley Laboratory






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




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
_______________________________________________
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
_______________________________________________
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


Back to the top