Re: [orbit-dev] Problems with Batik Contribution

[Jeff McAffer <Jeff_McAffer@xxxxxxxxxx>]

I don't know all the details of Batik
etc but if it makes sense I'd encourage you to make individual bundles
as much as possible.  Where this makes sense.  To recap the general
guideline we discussed in Dec it was something like 
        "if
two bundles will never ship separately, combine them."
The converse is of course, if a lib
is useful on its own or in combination with a subset of the rest of the
libs, bundle it separately.

These are just guidelines.

In addition to Simon's comment re importing
and exporting needed/supplied packages, where you have an exported package
that uses another package in its signatures/API, you should include a "uses"
clause in the manifest.  Something like
        Export-Package:
org.eclipse.foo; uses:=org.eclipse.bar
This says that the package foo exposes
types from the package bar.  As such, users of foo should be wired
to the same bar as the bundle containing foo otherwise ClassCastExceptions
will occur.  We are looking to include tooling for this in PDE real
soon now (see the PDE Incubator's API tooling work area)

Jeff

Christian Damus/Ottawa/IBM@IBMCA
Sent by: orbit-dev-bounces@xxxxxxxxxxx

01/12/2007 10:30 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, 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