Community
Participate
Working Groups
Similar to bug 329361, we need to make sure that our Orbit bundles are using the bundle-version attribute when requiring a specific version or range. (rather than "version"). I'm not sure the best way to approach. I will talk to Tom and then comment here.
from a quick scan of my 4.1 install, here are the list of "broken" orbit bundles: org.apache.batik.css org.apache.batik.util org.apache.batik.xml org.w3c.dom.svg
I've written a tool to check all the Orbit bundles from the latest build. These are the ones which use "version" when they should be using "bundle-version": org.apache.batik.bridge_1.6.0.v200912221622.jar org.apache.batik.bridge_1.7.0.v200912221625.jar org.apache.batik.css_1.6.0.v200912221622.jar org.apache.batik.css_1.7.0.v200912221625.jar org.apache.batik.dom.svg_1.6.0.v200805290154.jar org.apache.batik.dom.svg_1.7.0.v200903091627.jar org.apache.batik.dom_1.6.0.v200912221622.jar org.apache.batik.dom_1.7.0.v200912221625.jar org.apache.batik.ext.awt_1.6.0.v200805290154.jar org.apache.batik.ext.awt_1.7.0.v200903091627.jar org.apache.batik.extension_1.6.0.v200805290154.jar org.apache.batik.extension_1.7.0.v200903091627.jar org.apache.batik.parser_1.6.0.v200805290154.jar org.apache.batik.parser_1.7.0.v200903091627.jar org.apache.batik.svggen_1.6.0.v200805290154.jar org.apache.batik.svggen_1.7.0.v200903091627.jar org.apache.batik.swing_1.6.0.v200805290154.jar org.apache.batik.swing_1.7.0.v200903091627.jar org.apache.batik.transcoder_1.6.0.v200805290154.jar org.apache.batik.transcoder_1.7.0.v200903091627.jar org.apache.batik.util_1.6.0.v200805290154.jar org.apache.batik.util_1.7.0.v200903091627.jar org.apache.batik.xml_1.6.0.v200805290154.jar org.apache.batik.xml_1.7.0.v200903091627.jar org.w3c.dom.svg_1.1.0.v200806040011.jar
Adding Anthony to the CC list since it is mostly the Batik bundles which are effected.
fyi I've run the tool against the Indigo M2 repository and only one other bundle was flagged. I have opened bug 329392 to address this.
Any chance of sharing the tool? (I'm not asking for support ... just anticipating others might need to check things ... not everything is in the common repository (e.g. unit test bundles). More importantly ... can you clarify the exact symptom? The bundle is "not resolved" is sounds like, but is there nothing written to log?
(In reply to comment #5) > Any chance of sharing the tool? (I'm not asking for support ... just > anticipating others might need to check things ... not everything is in the > common repository (e.g. unit test bundles). > > More importantly ... can you clarify the exact symptom? The bundle is "not > resolved" is sounds like, but is there nothing written to log? The bundle will not resolve. By default we only log unresolved bundle messages when in debug mode (specifying the -debug option) or if there was some exception while trying to launch the eclipse application. When we do log we only give information on the constraint that could not resolve. It will not give more details about why the constraint did not resolve. For example, it will not tell you that Require-Bundle: foo; xxx=yyy did not resolve because no attribute xxx was found to match yyy.
Created attachment 182337 [details] test bundle Here's a copy of the test bundle. Not production quality. :-) You should be able to import it into your workspace and use it. Edit the PATH var to point to your plugins/ folder and then run as an Eclipse application. It will print out error messages for unknown filetypes (not JAR, Zip or a folder) but you can hack the #start method to ignore known types if needed. (.pack.gz for instance) Yeah, I soon realized that the Eclipse SDK bundles aren't part of the Indigo M2 repo that I downloaded so I had to check those separately as well.
To be clear, this is about Require-Bundle. The attribute on Import-Package is "version" (package versions are independent of bundle version).
(In reply to comment #2) > I've written a tool to check all the Orbit bundles from the latest build. These > are the ones which use "version" when they should be using "bundle-version": > > > org.apache.batik.bridge_1.6.0.v200912221622.jar > org.apache.batik.bridge_1.7.0.v200912221625.jar > org.apache.batik.css_1.6.0.v200912221622.jar > org.apache.batik.css_1.7.0.v200912221625.jar > org.apache.batik.dom.svg_1.6.0.v200805290154.jar > org.apache.batik.dom.svg_1.7.0.v200903091627.jar > org.apache.batik.dom_1.6.0.v200912221622.jar > org.apache.batik.dom_1.7.0.v200912221625.jar > org.apache.batik.ext.awt_1.6.0.v200805290154.jar > org.apache.batik.ext.awt_1.7.0.v200903091627.jar > org.apache.batik.extension_1.6.0.v200805290154.jar > org.apache.batik.extension_1.7.0.v200903091627.jar > org.apache.batik.parser_1.6.0.v200805290154.jar > org.apache.batik.parser_1.7.0.v200903091627.jar > org.apache.batik.svggen_1.6.0.v200805290154.jar > org.apache.batik.svggen_1.7.0.v200903091627.jar > org.apache.batik.swing_1.6.0.v200805290154.jar > org.apache.batik.swing_1.7.0.v200903091627.jar > org.apache.batik.transcoder_1.6.0.v200805290154.jar > org.apache.batik.transcoder_1.7.0.v200903091627.jar > org.apache.batik.util_1.6.0.v200805290154.jar > org.apache.batik.util_1.7.0.v200903091627.jar > org.apache.batik.xml_1.6.0.v200805290154.jar > org.apache.batik.xml_1.7.0.v200903091627.jar > org.w3c.dom.svg_1.1.0.v200806040011.jar Andrew pinged me, it seems that this issue is blocking upstream adoption of Eclipse 3.7. Can we confirm?
(In reply to comment #9) > (In reply to comment #2) > > I've written a tool to check all the Orbit bundles from the latest build. These > > are the ones which use "version" when they should be using "bundle-version": > > > > > > org.apache.batik.bridge_1.6.0.v200912221622.jar > > org.apache.batik.bridge_1.7.0.v200912221625.jar > > org.apache.batik.css_1.6.0.v200912221622.jar > > org.apache.batik.css_1.7.0.v200912221625.jar > > org.apache.batik.dom.svg_1.6.0.v200805290154.jar > > org.apache.batik.dom.svg_1.7.0.v200903091627.jar > > org.apache.batik.dom_1.6.0.v200912221622.jar > > org.apache.batik.dom_1.7.0.v200912221625.jar > > org.apache.batik.ext.awt_1.6.0.v200805290154.jar > > org.apache.batik.ext.awt_1.7.0.v200903091627.jar > > org.apache.batik.extension_1.6.0.v200805290154.jar > > org.apache.batik.extension_1.7.0.v200903091627.jar > > org.apache.batik.parser_1.6.0.v200805290154.jar > > org.apache.batik.parser_1.7.0.v200903091627.jar > > org.apache.batik.svggen_1.6.0.v200805290154.jar > > org.apache.batik.svggen_1.7.0.v200903091627.jar > > org.apache.batik.swing_1.6.0.v200805290154.jar > > org.apache.batik.swing_1.7.0.v200903091627.jar > > org.apache.batik.transcoder_1.6.0.v200805290154.jar > > org.apache.batik.transcoder_1.7.0.v200903091627.jar > > org.apache.batik.util_1.6.0.v200805290154.jar > > org.apache.batik.util_1.7.0.v200903091627.jar > > org.apache.batik.xml_1.6.0.v200805290154.jar > > org.apache.batik.xml_1.7.0.v200903091627.jar > > org.w3c.dom.svg_1.1.0.v200806040011.jar > > Andrew pinged me, it seems that this issue is blocking upstream adoption > of Eclipse 3.7. Can we confirm? Yes, see bug 329382. e4 cannot move up to the latest 3.7 I-Build because e4 depend on batik and the batik bundles will not resolve on the framework in the latest 3.7 I-Builds of Equinox.
Created attachment 182414 [details] Patch for the Batik v1.7 bundles with the issue. Committed the fixes for the Batik v1.7 bundles with the issue and released as v201011041433.
(In reply to comment #11) > Created an attachment (id=182414) [details] > Patch for the Batik v1.7 bundles with the issue. > > Committed the fixes for the Batik v1.7 bundles with the issue and released as > v201011041433. Can we please also get this on the 1.6 bundles? The e4 css engine currently requires 1.6 and apparently needs some rewriting before moving to 1.7
Created attachment 182418 [details] Patch for the Batik v1.6 bundles with the issue. Committed the fixes for the Batik v1.6 bundles with the issue and released as v201011041432. Dave, I guess we can run a build?
(In reply to comment #13) > Created an attachment (id=182418) [details] > Patch for the Batik v1.6 bundles with the issue. > > Committed the fixes for the Batik v1.6 bundles with the issue and released as > v201011041432. > > Dave, I guess we can run a build? Its automatic. Running now. Just a few minutes left. The next question is do we need to promote a new S build for M3? Or is this all an M4 issue? I think this is all an M4 issue. If I've misunderstood, let me know. Assuming the later, I'll soon promote an I-build so builds towards M4 can use that I build.
(In reply to comment #14) > Its automatic. Running now. Just a few minutes left. > > The next question is do we need to promote a new S build for M3? Or is this all > an M4 issue? I think this is all an M4 issue. If I've misunderstood, let me > know. Assuming the later, I'll soon promote an I-build so builds towards M4 can > use that I build. Judging from the dashboard, this build seems to have been triggered by the change from comment 11 (?) The e4 build which we hoped to run tonight (~2am) would actually require the second change, which I presume will automatically start another build as soon as this one is complete. If we want to consume this 2nd build for e4, can we predict the map file entries once the second build starts without having to wait for it to finish?
(In reply to comment #14) > The next question is do we need to promote a new S build for M3? Or is this all > an M4 issue? I think this is all an M4 issue. If I've misunderstood, let me > know. Assuming the later, I'll soon promote an I-build so builds towards M4 can > use that I build. This is all an M4 issue. I released the change to the framework for the first I-Build after M3. Boy am I glad I did not put this change off until later in M4!
(In reply to comment #15) > Judging from the dashboard, this build seems to have been triggered by the > change from comment 11 (?) The e4 build which we hoped to run tonight (~2am) > would actually require the second change, which I presume will automatically > start another build as soon as this one is complete. > > If we want to consume this 2nd build for e4, can we predict the map file > entries once the second build starts without having to wait for it to finish? Looking at the actual build results, this build does appear to have what we need.
Thank you Anthony, the 4.1 SDK build was successful with these changes.
I think this counts as "fixed". Thanks all.
Actually, just to be explicit, I'm assuming there's no reason the "backport" these fixes to Helios SR2 ... right?
(In reply to comment #20) > Actually, just to be explicit, I'm assuming there's no reason the "backport" > these fixes to Helios SR2 ... right? I would like this to be fixed in SR2. I would like to avoid having bad bundles out in the field that may eventually be used by some product and later that product updates to using the core framework from 3.7. At that point they would be broken. The more bundles we fix in the wild the better.
> > I would like this to be fixed in SR2. I'm game. Procedurally, why don't you open a clone of this bug, and there we'll also track the work needed to produce a branch (of map files) and other releng setup to do a Helios SR2 build.
NO, NO, NO to Helios SR2. GMF and a couple of other projects have a hard dependency to these orbit versions and I do not want to see many projects do any work for this issue in SR2 when I do not see a need to. If "version" is broken in SR2 then this is a breaking API change. Teams will be willing to do in a new release, not in a maintenance release.
(In reply to comment #21) > (In reply to comment #20) > > Actually, just to be explicit, I'm assuming there's no reason the "backport" > > these fixes to Helios SR2 ... right? > > I would like this to be fixed in SR2. I would like to avoid having bad bundles > out in the field that may eventually be used by some product and later that > product updates to using the core framework from 3.7. At that point they would > be broken. The more bundles we fix in the wild the better. Has the tooling in Eclipse 3.6.2 been updated such that "version" is flagged as an error? With a quick fix to use "bundle-version"?
