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
|