re:import/export
I literally mean doing an
Import-Package: org.w3c.dom.svg;version="[1.1,
1.2)"
Export-Package:
org.w3c.dom.svg;version=1.1
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
this.
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
implementation detail.
-Simon
----- Original Message -----
Sent: Friday, January 12, 2007 10:30
AM
Subject: Re: [orbit-dev] Problems with
Batik Contribution
Hi, Simon,
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.
Thanks,
Christian
Christian W.
Damus Component Lead, Eclipse OCL and EMFT-QTV IBM
Rational Software
"Simon Kaegi"
<simon.kaegi@xxxxxxxxx> Sent by: orbit-dev-bounces@xxxxxxxxxxx
01/12/07 10:09 AM
Please respond
to Orbit Developer discussion
<orbit-dev@xxxxxxxxxxx> |
|
To
| "Orbit Developer discussion"
<orbit-dev@xxxxxxxxxxx>
|
cc
|
|
Subject
| 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 -----
From: Christian
Damus To: orbit-dev@xxxxxxxxxxx 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_______________________________________________ orbit-dev mailing
list orbit-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/orbit-dev
_______________________________________________ orbit-dev mailing
list orbit-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/orbit-dev
|