Skip to main content

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

Hi Christian,
 
Do you know if org.w3c packages used in Batik are exposed in user API.
If not, one possibility might be to keep those packages private in the bundle. e.g. and not export them -- I agree the versioning is a bit of a guess.
If you really do need to export them and really don't want to do separate bundles, you should  consider both importing and exporting the packages.
 
-Simon
----- Original Message -----
Sent: Thursday, January 11, 2007 4:21 PM
Subject: [orbit-dev] Problems with Batik Contribution


Hi,

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 https://bugs.eclipse.org/bugs/show_bug.cgi?id=166207.  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 w3c.org 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?

Thanks,

Christian



Christian W. Damus
Component Lead, Eclipse
OCL and EMFT-QTV
IBM Rational Software


_______________________________________________
orbit-dev mailing list
orbit-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/orbit-dev

Back to the top