Community
Participate
Working Groups
Given recent issues discovered in creating EPP packages, see https://bugs.eclipse.org/bugs/show_bug.cgi?id=349267#c57 I think the eclipse help system should only prereq exactly what it needs from lucene. Not prereq the "umbrella bundle" it currently does. That umbrella bundle was created in Orbit, to provide "backwards compatibility", but that's not needed by the platform (as far as I know) and it has the side effect of causing optional, greedy requirements to be published to repository metadata, so someone installing with p2, from a repository that has those optional bundles, will get them all. Even though org.eclipse.help does not need them. I am not sure if it would be a breaking change to change prereqs to be more precise, but I think it should at least be evaluated for Indigo SR1 maintenance, so that EPP packages do not have to "pick them up". (Indigo SR0 packages do not have the optional ones ... but, that was an accident of timing). Another option might be for the Orbit bundle to specify p2.inf file for org.apache.lucene to make its optional bundles not greedy ... but, pretty sure that would be a "breaking" thing to do in maintenance stream. (though, not sure there is a spec or standard for "breaking changes" in repository metadata ... but common sense says someone might be counting on the greedy behavior ... even if they don't know it :). To cross reference, see also bug 340563 which is merely about "moving up" to 2.9.4. Some issues will apply there.
I agree that the Lucene dependency in org.eclipse.help.base needs to be re-evaluated. I would like to remove the re-export of lucene in org.eclipse.help.base and bump the major version of org.eclipse.help.base. This would be a breaking change for some clients but I think that it would be better to take this hit once than continue in a situation where the help system inherits all API changes from Lucene and creates issues every time we change Lucene versions. Because of he re-export any change to the way lucene is imported is a breaking change and so could not be considered for SR1 ( unless there is a way to do this while retaining full backward compatibility). This is another argument for removal of the re-export in 4.2 so as to unshackle org.eclipse.help.base from the Lucene APIs.
(In reply to comment #1) > Because of he re-export any change to the way lucene is imported is a breaking > change I'm not sure how breaking this is... The help.base imports a _bundle_ but re-exports _packages_. The org.apache.lucene umbrella bundle doesn't contain any code itself, it just re-exports the org.apache.lucene.core itself. The optional lucene bundles are imported but _not_ re-exported by the lucene umbrella, so these can be considered implementation details. If there is anything "breaking" it's probably the fact whether the org.apache.lucene bundle is _present_ in the Eclipse SDK or not, since adopters might rely on that precise bundle id to exist. So physically _removing_ that bundle might be considered a breaking change, but that's more of a packaging question (to be dealt with in the feature.xml) and IMO independent of the "require-bundle" that o.e.help.base has in its manifest. Is that the kind of breakage that you were referring to? Or am I missing something? I have actually filed bug 351833 asking Orbit to not markup the lucene optional bundles as greedy; but independent of that "greedy problem" I agree with Dave that it's wrong for help.base to pre-req the Lucene Umbrella when it really pre-reqs lucene.core.... I'm not sure whether the behavior of lucene that's used by help could change in any way depending on whether the optional lucene bundles are installed or not?
Closing this one. A lot has changed in the area. If you still face issues of any kind please open a new bug with details of the current state.
