Bug 529432 - Apache Lucene Plug-in 1.9.1 is incompatible
Apache Lucene Plug-in 1.9.1 is incompatible
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: eclipse (Show other bugs)
11
i586 Linux
low Severity high
: ---
: ---
Assigned To: Andrew Overholt
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-10-16 15:43 EDT by fabricioepa
Modified: 2010-06-28 11:02 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-06-28 11:02:46 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
Fedora Eclipse configuration details (274.81 KB, text/plain)
2009-10-16 15:43 EDT, fabricioepa
no flags Details

  None (edit)
Description fabricioepa 2009-10-16 15:43:48 EDT
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:
Comment 1 Alexander Kurtakov 2009-10-16 16:15:42 EDT
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.
Comment 2 Alexander Kurtakov 2009-10-16 16:21:44 EDT
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.
Comment 3 Alexander Kurtakov 2009-10-16 16:29:59 EDT
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.
Comment 4 fabricioepa 2009-10-16 20:22:33 EDT
(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.
Comment 5 fabricioepa 2009-10-16 20:31:30 EDT
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.
Comment 6 Alexander Kurtakov 2009-10-17 01:11:06 EDT
(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.
Comment 7 Alexander Kurtakov 2009-10-17 01:13:35 EDT
By fixing the lucene case I mean for Fedora 12.
Comment 8 Andrew Overholt 2009-10-26 09:24:31 EDT
The best solution here is to have a separate lucene1 package in Fedora.    fabricioepa, would you be willing to submit and maintain that?
Comment 9 fabricioepa 2009-10-26 09:58:15 EDT
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...
Comment 10 Andrew Overholt 2009-10-26 10:07:04 EDT
(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.
Comment 11 Bug Zapper 2010-04-28 06:51:33 EDT
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
Comment 12 Bug Zapper 2010-06-28 11:02:46 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.