[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
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