[orbit-dev] More Batik Fun: Need to split the org.w3c.dom package. Pleas

["Christian W. Damus" <give.a.damus@xxxxxxxxx>]

Hi, fellow Orbiters,

This is another plea for help from the Orbiters that know OSGi better than I do (which, I think, is probably all of you).

I have a new "situation" in the Batik 1.7 bundles with which I have been struggling.  Batik 1.7 defines an interface ElementTraversal, of Apache's invention, not W3C's, in the org.w3c.dom package.

So, I need to deliver this class in the org.apache.batik.dom bundle in which it is used (exclusively as an interface implemented by an abstract Batik element class).

The problem is, that this package is already provided not only by the JDK (system.bundle) but also by the javax.xml_1.3.4 bundle also in Orbit.  So, as I understand it, trying to provide this one interface from my Batik bundle would result in it being a "split package."  This is where I need help.  I don't know how split packages work, so I have some questions:

• will splitting this package require a change to the javax.xml bundle, to make it play nicely with the split?
• will I have to export this package from my bundle at the same version as the javax.xml bundle?
• what are the mechanics of splitting a package?  From some documentation that I have read (OSGi spec), it seems to require (a) some façade bundle that exports the package and has Require-Bundle dependencies on the providers of the package, and (b) a convention of specifying required matching attributes so that bundles do not accidentally import only a part of the package, but get all of it from the bundle that combines the parts.

It is the second part (b) of the last bullet above that particularly concerns me.  This is why it seems to require cooperative changes in the javax.xml bundle, which wouldn't make sense because XML Commons (from which javax.xml is derived) and Batik are independent projects.  The splitting of this package is entirely accidental and, IMHO, erroneous (as Batik shouldn't have used the org.w3c.dom package for its own interface).

I think, though, that what might work is to have org.apache.batik.dom bundle exports org.w3c.dom with a mandatory matching attribute and makes a Require-Bundle dependency to javax.xml to get its contributions to this package.  This will ensure (I think) that any bundle that uses Import-Package to get org.w3c.dom will get only the javax.xml version without the foreign (Apache) content, but requires Batik clients to use Require-Bundle for its Batik dependencies (I think all of Eclipse's Batik clients already do this).  I will also, for the same reason, have to update the other Batik bundles to get org.w3c.dom by Require-Bundle on org.apache.batik.dom instead of Import-Package, as currently.

Comments?  Advice?

Thanks in advance!

Christian