Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 393739

Summary:	Remove package versions for possibly-JRE-provided packages
Product:	[Eclipse Project] Platform	Reporter:	Brian de Alwis <bsd>
Component:	UI	Assignee:	Platform-UI-Inbox <Platform-UI-Inbox>
Status:	CLOSED WONTFIX	QA Contact:
Severity:	major
Priority:	P3	CC:	david_williams, john.arthorne, krzysztof.daniel, tjwatson
Version:	4.2
Target Milestone:	---
Hardware:	All
OS:	All
Whiteboard:

Description Brian de Alwis

2012-11-06 23:42:08 EST

This is a follow-on to bug 380570 where we explicitly introduced Import-Package statements for org.w3c.css.dom.  The change explicitly specified a package-version of 2.0.0 matching the package provided by the javax.xml bundle normally shipped Orbit.  Unfortunately this means that apps have to ship with javax.xml from Orbit as the version from the system bundle will always be 0.0.0.

I mis-interpreted Paul's remark in 380570c10 to mean that he had committed a fix.  But this issue just happened to me and is happening to others as evidenced by bugs like bug 387869.

I've put a proposed patch to remove package-versions for org.w3c.css.dom, javax.annotation, and javax.inject.  javax.annotation is included in JRE 6 and 7.  javax.inject doesn't yet seem to be included, but likely will one day.  The patch is at:

   http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=9f09e00b82187ec6245516e588bf3829ce63f354

Paul, if you have a sec, could you please review? I'd like to commit this to R4_2_maintenance, so if you'd prefer I can avoid changing the javax.annotation and javax.inject annotations; it's a moot change since several other Eclipse bundles specify an explicit package version.

Comment 1 David Williams

2012-11-07 02:04:54 EST

I'm probably mis-remembering or confusing myself (as I often do) but thought if a package had 0.0.0 it was taken as a special meaning of "satisfy anything" for "import package" (thought not require-bundle).  

I've probably got that wrong, but CCing Tom, just in case. 

I'm just wondering if there could be some other error in an Orbit bundle that causes the observed problem?

Comment 2 Paul Webster

2012-11-07 08:27:26 EST

Brian, it looks like I never removed the versions.

Tom, remind me again :-)  If I remove the versions and we ship org.w3c.css we'll use that bundle, because it has a version (since the JRE ones export with 0.0.0)

We'll only use the JRE ones if we haven't shipped an orbit bundle, right?

PW

Comment 3 Thomas Watson

2012-11-07 17:32:18 EST

(In reply to comment #1)
> I'm probably mis-remembering or confusing myself (as I often do) but thought
> if a package had 0.0.0 it was taken as a special meaning of "satisfy
> anything" for "import package" (thought not require-bundle).  
> 
> I've probably got that wrong, but CCing Tom, just in case. 

0.0.0 is not treated as special.  For example, it will not satisfy an Import-Package with a version="[1.0,2.0)"

> 
> I'm just wondering if there could be some other error in an Orbit bundle
> that causes the observed problem?

(In reply to comment #2)
> Brian, it looks like I never removed the versions.
> 
> Tom, remind me again :-)  If I remove the versions and we ship org.w3c.css
> we'll use that bundle, because it has a version (since the JRE ones export
> with 0.0.0)
> 
> We'll only use the JRE ones if we haven't shipped an orbit bundle, right?
> 
> PW

Sorry, I'm confused.  If you remove the versions on the exports then the exported version becomes 0.0.0.  This means that it will have the same version as the ones exported by the system bundle (provided by the JRE) which are at 0.0.0.  In this case the tie breaker is to prefer the export from the bundle with the lowest bundle ID (in which case that will be the system bundle since it has an ID of zero).

Comment 4 Brian de Alwis

2012-11-07 23:20:20 EST

(In reply to comment #3)
> Sorry, I'm confused.  If you remove the versions on the exports then the
> exported version becomes 0.0.0.

We're talking about removing the package versions from the importers of org.w3c.css.dom, not from the exporters (in this case, as exported by the javax.xml bundle in Orbit).

In my case, we were having problems launching a product with PDE: we have a separately-packaged non-Orbit javax.xml that has a later bundle version but no package versions on org.w3.css.dom.  PDE selects this later bundle version over the version from Orbit, but then several of the e4 bundles fail to resolve due to not being able to resolve org.w3c.css.dom >= 2.0.0.

Comment 5 Brian de Alwis

2013-03-04 10:15:03 EST

There's little we can do here: it's difficult to identify what versions the system-provided packages map to (see bug 348630).  So the only recommendation is to specify a package version (bug 348155c8).

I did experiment with stripping the package versions from the E4 bundles.  This caused E4 bundles to be bound the the JVM-provided packages if any.  But the same problem occurred as app bundles that included a package version were be bound to a package from one of the bundles.