Created attachment 365087 [details] Fedora Eclipse configuration details Description of problem: The org.apache.lucene_1.9.1.v20080530-1600.jar from current Fedora Eclipse Platform is not compatible with the same plug-in from the official Eclipse 3.4.2. I am a Plug-in developer in nokia projects (ESbox/Pluthon/Mica) and these project plug-ins fails when trying to use the apache lucene indexing engine, the eclipse shows the error log: !ENTRY org.eclipse.core.jobs 4 2 2009-10-13 09:24:22.427 !MESSAGE An internal error occurred during: "Loading Mica Hover Plug-in extensions". !STACK 0 java.lang.NoSuchMethodError: org.apache.lucene.document.Document.add(Lorg/apache/lucene/document/Field;)V See the full bug description on https://garage.maemo.org/tracker/index.php?func=detail&aid=4664&group_id=799&atid=2996 I have noticed that on Fedora Eclipse configuration details that the installed apache lucene plug-in has the right build number 1.9.1.v20080530-1600, but my plug-in does not work on it. Using the official Eclipse 3.4.2 with the same lucene version and lucene build number, my plug-in works fine. Version-Release number of selected component (if applicable): Fedora Eclipse Platform (where my plug-in crashes) Version: 3.4.2 Based on build id: 20090211-1700 The offcial Eclipse 3.4.2 (where my plug-in works fine) Eclipse SDK Version: 3.4.2 Build id: M20090211-1700 How reproducible: You can do a "diff" between the current fedora eclipse lucene plug-in and the official eclipse 3.4.2 with the same build number, and you will detect differences. I think this is enough to prove that these two files should have the same binary content but it doesn't. You can reproducing installing the following plug-ins: Steps to Reproduce: 1. Go to System> Administration> Add/Remove Software - Install Fedora Eclipse + C/C++ CDT Open the eclipse and install the following features using "Help > Software Update" 1.Install TM and RSE 3.0.2 http://download.eclipse.org/dsdp/tm/updates/3.0/ 2. Install Mica 2nd Edition http://mica.garage.maemo.org/update/2.0/ 3. Install Pluthon 2nd Edition http://pluthon.garage.maemo.org/update/2.0/ 4. Go to "Windown > Preferences" and open the page "Maemo > Hover Help" 5. Click "Reload" and wait until the error rise or the background job be finished. PS.: You should have internet connection available to run the reload command. Actual results: java.lang.NoSuchMethodError: org.apache.lucene.document.Document.add(Lorg/apache/lucene/document/Field;)V Expected results: No error should rise, open the error log view and you will can see the information logs: "GTK+ indexed." "Hildon .. indexed" "Qt indexd" .... Additional info:
I'm sorry to say it but we can't fix the problem. Lucene is required by a number of packages openoffice, netbeans, opengrok, eclipse. And some of these packages require Lucene 2 API to work. If you look closer org.apache.lucene_1.9.1.v20080530-1600.jar is a symlink to /usr/share/java/lucene-2.3.1.jar and the symlink is created because Eclipse expects the bundle to be named this way. We can not downgrade Lucene for a number of reaseons so it would be best if you update your code to work with Lucene 2. It shouldn't be a problem if you ship newer lucene bundle with your plugins.
Eclipse SDK is working fine with Lucene 2 so maybe it is even possible to update your plugin to work with Lucene 2 without breaking 1.9 compatibility. Please note that updating to Lucene 2.4 is planned for Eclipse SDK 3.6 from upstream developers.
It was quite easy to port Eclipse DTP to Lucene 2 API without breaking 1.9 compatibility I hope that this will be the case for you.
(In reply to comment #1) > I'm sorry to say it but we can't fix the problem. > Lucene is required by a number of packages openoffice, netbeans, opengrok, > eclipse. And some of these packages require Lucene 2 API to work. If you look > closer org.apache.lucene_1.9.1.v20080530-1600.jar is a symlink to > /usr/share/java/lucene-2.3.1.jar and the symlink is created because Eclipse > expects the bundle to be named this way. > We can not downgrade Lucene for a number of reaseons so it would be best if you > update your code to work with Lucene 2. It shouldn't be a problem if you ship > newer lucene bundle with your plugins. Hi, Thanks for your comments, I will try the compatibility with Lucene 2. IMHO this really is a BUG and it is broking the version and dependency architecture of Eclipse Platform, the eclipse expects that this plug-in named org.apache.lucene_1.9.1.v20080530-1600.jar matches exactly the right version. The plug-in/features are configured to depend/import on MANIFEST file the exact version number they are designed to work, when you make a "fake" jar point to another version with a different binary content, I think you are broking this contract. As an eclipse developer I know there is no problem if you have the true lucene 1.9.1 and the lucene 2 plug-in installed at the same time on the same eclipse platform, I really did not understand why you cannot use the right file. (no matter the 1.9.1 or 2.0.0 vesion, it should be the right file compatible with the version declared on manifest) So the developer can specify the right version he need. But when you use a fake "1.9.1" on manifest file and you really have a "2.0.0" you will introduce a bug into all plug-ins dependent on the right version. So the problem is on the platform that not respect the contract, not in the "client plug-in". Are you sure that this approach is a good pratice? Thanks for the help.
To summarize, If fedora should not support lucene 1.9.1, so when installing the Mica/Pluthon feature, the right behaviour of eclipse update manager would detects the depency and it would not make the installation and it would also inform the user about this. The problem is the fedora eclipse platform declares that support 1.9.1 and it really does not support and nobody is able to detect this.
(In reply to comment #5) > To summarize, If fedora should not support lucene 1.9.1, so when installing the > Mica/Pluthon feature, the right behaviour of eclipse update manager would > detects the depency and it would not make the installation and it would also > inform the user about this. > > The problem is the fedora eclipse platform declares that support 1.9.1 and it > really does not support and nobody is able to detect this. Yes, you're right but Eclipse SDK (srcIncluded tarball) has a really limitted build system which has the versions hardcoded in various build.xml files. As a result we have to supply jars with exactly the same bundle version even if the bundles requiring it support a range e.g. (1.9, 2.9] and this gives us one more problem by using the bundle with "fake" manifest it puts requires on this exact version when provisioning and we have to install this exact bundle with the fake manifest. On the bright side we are working on eclipse-build (http://wiki.eclipse.org/Linux_Tools_Project/Eclipse_Build) and it is already providing a flexible build system which allowed us to remove the exactly same problem with jetty for the upcoming Fedora 12. I'll work on fixing lucene case also but this is just too big change requiring to update half of the java stack to push to stable release (Fedora 11). If there is a problem with making it work with lucene 2 without breaking 1.9 compatibility tell me and I'll take a look.
By fixing the lucene case I mean for Fedora 12.
The best solution here is to have a separate lucene1 package in Fedora. fabricioepa, would you be willing to submit and maintain that?
Well this can be my first contribution on fedora project, so I can give a shot =] Can you say how I can start? any developer instructions, sources/compilation issues, etc...
(In reply to comment #9) > Well this can be my first contribution on fedora project, so I can give a shot > =] > Can you say how I can start? any developer instructions, sources/compilation > issues, etc... Cool :) This is good: http://fedoraproject.org/wiki/PackageMaintainers/Join with these being the specific Java packaging guidelines: http://fedoraproject.org/wiki/Packaging:Java Good luck.
This message is a reminder that Fedora 11 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 11. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '11'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 11's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 11 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 11 changed to end-of-life (EOL) status on 2010-06-25. Fedora 11 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.