Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[orbit-dev] Problems with Batik Contribution


On a recent Orbit call (the last of 2006), we spent some time discussing the bundling of libraries that are provided as a multitude of JARs.  The particular example was Batik, which I am contributing under  With the help of my colleagues on the call, I came away convinced that the best approach to bundling Batik's 16 JARs would be to follow the same strategy as GMF had implemented already:  one bundle containing the individual OEM JARs within it, unpacked on installation, with the exception of the org.w3c.* packages from the batik-ext.jar which would be bundled separately.

Thus, I would have:

  - org.apache.batik bundle containing 15 nested JARs
  - org.w3c.css.sac bundle
  - org.w3c.dom.smil bundle
  - org.w3c.dom.svg bundle

(the latter three bundles not having nested JARs).

The problem now is, that the Java language bindings for the W3C standards that these latter three bundles would comprise are only available from as ZIPs of *.java files.  They aren't versioned, so I would have to assume that they only have one version (the specification's version, which is 1.1), and that Batik compiled these same source files for their distro.

So, I am inclined to just contribute GMF's org.apache.batik bundle to Orbit as is (basically, just copy the project from GMF's CVS module to the Orbit module).  For the purpose of package exports, most packages will have the "1.6" version number, and for the org.w3c packages I'll just have to use the current W3C specification number.

Does anyone have an objection to that?



Christian W. Damus
Component Lead, Eclipse
IBM Rational Software

Back to the top