Bug 529432
Summary: | Apache Lucene Plug-in 1.9.1 is incompatible | ||||||
---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | fabricioepa <fabricioepa> | ||||
Component: | eclipse | Assignee: | Andrew Overholt <overholt> | ||||
Status: | CLOSED WONTFIX | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
Severity: | high | Docs Contact: | |||||
Priority: | low | ||||||
Version: | 11 | CC: | akurtako, overholt | ||||
Target Milestone: | --- | ||||||
Target Release: | --- | ||||||
Hardware: | i586 | ||||||
OS: | Linux | ||||||
Whiteboard: | |||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | Environment: | ||||||
Last Closed: | 2010-06-28 15:02:46 UTC | Type: | --- | ||||
Regression: | --- | Mount Type: | --- | ||||
Documentation: | --- | CRM: | |||||
Verified Versions: | Category: | --- | |||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
Cloudforms Team: | --- | Target Upstream Version: | |||||
Embargoed: | |||||||
Attachments: |
|
Description
fabricioepa
2009-10-16 19:43:48 UTC
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. |