I literally mean doing an
in your Batik bundle's manifest.
This puts the onis on the OSGi resolver to
decide which org.w3c.dom.svg to wire-up.
The main reason you do this is so that if
another bundle also exports the packages you can work with it without creating
an inconsistent class space.
For example, if you had another bundle that used
Batik but also happened to export org.w3c.dom.svg you might hit
Of course it works a whole lot better if our
versioning is solid, so if possible I'd see if it can be a private
----- Original Message -----
Sent: Friday, January 12, 2007 10:30
Subject: Re: [orbit-dev] Problems with
Thanks for the tip. I'll have a
look to see whether these packages are in the other Batik API. I expect
that the SVG DOM types would be, but I'll have to see.
What do you mean by importing and exporting these
packages? Why would a bundle import a package that it already has on
hand to export? Would I import and export the same package versions?
Or no versions? I think the main issue is that I'm not sure that
I can create a "definitive" bundle for these packages.
Component Lead, Eclipse OCL and EMFT-QTV
Sent by: orbit-dev-bounces@xxxxxxxxxxx
01/12/07 10:09 AM
Orbit Developer discussion
|"Orbit Developer discussion"
|Re: [orbit-dev] Problems with
Do you know if org.w3c packages used in Batik are exposed in
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
----- Original Message -----
Sent: Thursday, January 11, 2007 4:21 PM
Subject: [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 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
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
anyone have an objection to that?
Christian W. Damus
Component Lead, Eclipse
IBM Rational Software