Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 422101 - Help (info center feature) still requires org.apache.lucene
Summary: Help (info center feature) still requires org.apache.lucene
Status: VERIFIED FIXED
Alias: None
Product: Platform
Classification: Eclipse Project
Component: User Assistance (show other bugs)
Version: 4.4   Edit
Hardware: PC Linux
: P3 normal (vote)
Target Milestone: 4.4 M6   Edit
Assignee: David Williams CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-11-19 19:51 EST by David Williams CLA
Modified: 2014-02-03 14:20 EST (History)
4 users (show)

See Also:


Attachments
patch to change feature and repository pom (1.70 KB, patch)
2013-11-24 13:25 EST, David Williams CLA
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description David Williams CLA 2013-11-19 19:51:44 EST
org.apache.lucene is an "umbrella bundle" (these days) that simply requires and reexports a bunch of other lucene bundles, for compatibility reasons. 

Some time ago (I maybe even Kepler?) we decided to require only what we specifically needed, so as to not "pull in" all of the lucene bundles. 
The only two specific lucene bundles we need (as far as I know) are 
org.apache.lucene.core, and 
org.apache.lucene.analysis

But, while working on bug 400518 discovered someone was still requiring "whole" org.apache.lucene bundle. 

As best I can tell, this is only the 
org.eclipse.help.infocenter_feature

It requires all three: 

   <plugin
         id="org.apache.lucene"
         download-size="0"
         install-size="0"
         version="0.0.0"
         unpack="false"/>

   <plugin
         id="org.apache.lucene.analysis"
         download-size="0"
         install-size="0"
         version="0.0.0"
         unpack="false"/>
         
   <plugin
         id="org.apache.lucene.core"
         download-size="0"
         install-size="0"
         version="0.0.0"
         unpack="false"/>

The first can be removed (as far as I know). 

Several of the pom files are confusing also, in that they inconsistently specify which are "required pre-reqs before building" but don't think they are the cause of the issue I'm seeing at the moment. 

Thought I'd start by entering this bug, in case there was a good reason for requiring the whole thing?
Comment 1 David Williams CLA 2013-11-24 13:25:39 EST
Created attachment 237673 [details]
patch to change feature and repository pom

In addition to removing the umbrella lucene bundle from feature, I believe now that bug 400518 is fixed we can remove the whole "extra requirement" section of the repo's root pom. Its purpose, in the past, was to make sure we had extra restriction on expected version range for lucene bundles ... even if not this restrictive in manifest.mf files. 

<versionRange>[3.5,4.0)</versionRange>

I believe that now that we specify exact version we want in target file, we not longer need this "hint" from pom. 

It probably doesn't hurt anything being there (since the exact version we specify, 3.5.0.v20120725-1805, overlaps), it is now "redundant" information and likely will be confusing in future if/when the target version ever changes to be above 4.0. ... And, even if we did not remove the whole section, the umbrella specification should be change to be just 'core' instead of all of "org.apache.lucene". Specifying the umbrella version likely doesn't hurt much, except would make build very slightly longer ... and might make it easier in future for someone to mistakenly add a dependency on some other lucene bundle. 

I'll try a test build with whole section removed (and feature changed) to make sure there are no surprises.
Comment 2 David Williams CLA 2013-11-24 15:46:45 EST
See bug 422417 for similar change. 

I'll make same comment here. 
= = = 
In my test build, there was same number of jar files in SDK and (more important) the "repository" as there was in the last I build I20131119-0800. 

In fact, the I build repo had (only) 
org.apache.lucene.analysis_3.5.0.v20120725-1805.jar
and 
org.apache.lucene.core_3.5.0.v20120725-1805.jar

(Not the umbrella lucene bundle) 

So, I think this is a relatively safe change (though, I suppose, some other lucene bundle could "embedded" inside another jar/war file?
= = =
Actually, if I 'expand', the org.eclipse.help.webapp jar file, I don't find any embedded jars or wars (and no lucene of any type) ... so, I do not know how this "web app" works.
Comment 3 David Williams CLA 2013-12-07 11:03:26 EST
We should fix this by M5, if not M4, since, I've learned, some people (one way or another) "include" the eclipse parent pom in their builds, so they might be depending on this "overly wide dependency" without even knowing it. Whereas if they need "something else" from Lucene, they should be specifying that in their own build's pre-reqs, and not (unknowingly) depending on this mistake in our list.
Comment 4 Dani Megert CLA 2014-01-22 11:42:36 EST
Too late for this for M5.
Comment 5 Dani Megert CLA 2014-01-27 10:51:20 EST
David, I've submitted your patch together with updated copyright date with http://git.eclipse.org/c/platform/eclipse.platform.ua.git/commit/?id=84ce3faa1807416042770a2302728a98a9cb70b9

Also updated the bundle version with http://git.eclipse.org/c/platform/eclipse.platform.ua.git/commit/?id=7af2f53a15d3ac22f9f26232073e89d9c2b3e00d
Comment 6 David Williams CLA 2014-01-29 17:23:12 EST
I've now remove the umbrella lucene and the extra (unused) bundles from our pre-reqs. 

http://git.eclipse.org/c/platform/eclipse.platform.releng.aggregator.git/commit/?id=55b1bb26d9e12b73569ce6ddfe5a1e0fa492b4a4

Figured tonight's N-build would be a good time to confirm not required. 
Assuming that goes well, I may "announce" on cross-project list, since someone might have been getting them automatically (accidentally) from our repo/prereqs.
Comment 7 David Williams CLA 2014-02-03 14:20:32 EST
I've verified in recent "nightlies" that the umbrella bundle, and lucene.misc and lucene.queries are no longer "pulled down" during our build. And (re) verified they never were being included in our repo (so would not effect function).