Bugzilla – Full Text Bug Listing
| Summary: | org.apache.batik.pdf export package org.apache.commons.io and should not | ||
|---|---|---|---|
| Product: | [Tools] Orbit | Reporter: | Aurelien Pupier <apupier> |
| Component: | bundles | Assignee: | David Williams <david_williams> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | major | ||
| Priority: | P3 | CC: | ahunter.eclipse, david_williams, paul.signer, steffen.pingel, tjwatson |
| Version: | unspecified | ||
| Target Milestone: | Indigo RC1 | ||
| Hardware: | PC | ||
| OS: | Windows Vista | ||
| Whiteboard: | |||
|
Description
Aurelien Pupier
I doubt they can remove the exports altogether since others may depend on them. One possibility would be to add a mandatory directive on the exports so that casual importers will not get wired to them. For example: Export-Package: org.apache.commons.io; batik="split; mandatory:="batik", org.apache.commons.io.output; batik="split; mandatory:="batik" So normal importers using Import-Package org.apache.commons.io will not get wired to these exports because they do not specify the batik=split matching attribute. Bundles which use Require-Bundle on the batik bundles will continue to get the org.apache.commons.io packages from the batik bundle as before. (In reply to comment #1) > Export-Package: > org.apache.commons.io; batik="split; mandatory:="batik", > org.apache.commons.io.output; batik="split; mandatory:="batik" > Sorry, I was missing some necessary quotes: Export-Package: org.apache.commons.io; batik="split"; mandatory:="batik", org.apache.commons.io.output; batik="split"; mandatory:="batik" I don't know about this feature of mandatory directive. As I understand with your explanation, it should work but it seems quite complicated from my POV. But it might break the compatibility as well as removing them, isn't it? (In reply to comment #3) > I don't know about this feature of mandatory directive. > As I understand with your explanation, it should work but it seems quite > complicated from my POV. > But it might break the compatibility as well as removing them, isn't it? It will break compatibility for an bundles that are using simple Import-Package for the org.apache.commons.io packages and expecting to get wired to the exports provided by the batik bundle: Import-Package: org.apache.commons.io, org.apache.commons.io.output But it will preserve backwards compatibility for an bundles using Require-Bundle on the batik bundles. *** Bug 309075 has been marked as a duplicate of this bug. *** *** Bug 336137 has been marked as a duplicate of this bug. *** There's been so many reports of this, I think we should fix for RC1. Anthony, assigning to you, as I think you technically "own" these bundles in Orbit ... but, if you can't fix this soon (in next few days?) then we should find someone else to, right? As I said in another Bugzilla: As far as I can recall, the Batik SVG toolkit as it comes from apache includes some "other" apache common code. In Batik 1.7 in orbit we tried to not repackage these common libraries, but that does not help you with Batik 1.6. Unfortunately, I am not sure what the answer is. These batik 1.6 bundles have worked well for 5 years and modifying them is not going to work. What we should be doing is moving to Batik 1.7, but that effort has been a failure thus far since Batik 1.7 has API breakages. There are no plans to adopt Batik 1.7 in Indigo by Eclipse Modeling (GMF Runtime). We need to stick on Batik 1.6. I am not sure what the answer is, suggestions welcome. > > I am not sure what the answer is, suggestions welcome. I think Tom's suggestion will work (in comment #2). The "risk" of breaking anyone that was using "import package" and specifically expecting those to come automatically from batik.pdf seems a small risk, since even if someone was doing that, then it would be working for them sort of by chance (i.e. very fragil, and potentially broken by simply installing something else that also used/provided a commons.io package). So I add: Export-Package: org.apache.commons.io; batik="split"; mandatory:="batik", org.apache.commons.io.output; batik="split"; mandatory:="batik" To the MANIFEST.MF in org.apache.batik.pdf version 1.6. (In reply to comment #10) > So I add: > > Export-Package: > org.apache.commons.io; batik="split"; mandatory:="batik", > org.apache.commons.io.output; batik="split"; mandatory:="batik" > > To the MANIFEST.MF in org.apache.batik.pdf version 1.6. Yes. I just loaded up all all the batik 1.6 bundles, and didn't see any of them that imported/required "commons.io" so that would have been the only complication (that is, deciding what to do in those cases) but since there are none (that I could see) then there should be no other issues. IMHO, while there is some risk, is seems small enough, and rare enough that there is no need for wide spread notification, such as to cross-project, but if others disagree, please say so, so we can post appropriate notes. Thanks, I was went to go fix this tonight, for our Orbit RC1 deadline (due 5/7) and noticed there's not only "commons.io" exported in there, but also "commons.logging". Specifically: org.apache.commons.io, org.apache.commons.io.output, org.apache.commons.logging, org.apache.commons.logging.impl, That can't be good? Would we have same/similar problem with commons.logging, once commons.io is fixed? I wonder if if we should proactively do the same thing, for those? All the other exported packages are either "avalon" for "fop", so I think it is only these four. I'm guessing these packages should not have been exported in the first place? As a general rule, I'd say, if an Orbit bundle has packages from other namespaces, we should not re-export them, and assume they are using them entirely internal to themselves. Unless there is a known reason that requires them to exported. I've released the change, for our Orbit RC1 Indigo contribution, that will tweak all 4 extraneous exports: org.apache.commons.io; batik="split"; mandatory:="batik", org.apache.commons.io.output; batik="split"; mandatory:="batik", org.apache.commons.logging; batik="split"; mandatory:="batik", org.apache.commons.logging.impl; batik="split"; mandatory:="batik", I've also added a note element to the batik.pdf xml file, that says, See <![CDATA[<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=344560">bug 344560</a>]]> for a fix that might, in rare cases, cause behavior change when moving from Helios to Indigo.</note> I also added some guidelines to one of our "adding bundles to Orbit" wiki pages ... I'm sure others can improve them, but its a start, at least gives some hints ... see http://wiki.eclipse.org/Orbit/Adding_Bundles_to_Orbit#Export-Package_guidelines Built fine, download page fine (with batik.pdf pointer back here). So anyone that can test the RC1 version (builds >= I20110507152510) that'd be great, just to confirm works as expected ... no unexpected breakages. Note to consumers: see comment #4 for the possible compatibility issue, but its expected to be rare that someone would _need_ the specific packages from batik, and it'd be recommended to use the "standard" packages from their own bundles. If anyone knows or finds any reason this isn't true, do please let us know ... possibly re-opening this bug if something is (still) not right. Thanks to all for reporting this issue, and Tom for proposing a solution. (In reply to comment #14) > Thanks to all for reporting this issue, and Tom for proposing a solution. And Thanks to Dave for fixing the issue. |