Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[orbit-dev] Gack! I think Batik is my Nemesis

Hello, my fellow Orbiters.  

My Batik nightmare returns, with a vengeance.  Once again, we have severe configuration problems to untangle.  Or, at least, so I think.  I've been struggling with this for 14 hours, today, so I may be somewhat addled.

Any suggestions how to resolve, cope with, or accept in defeat the following issues are most welcome.  I have a few feeble suggestion of an approach that I might take for the first of my problems.

Thanks, in advance, for your patience in reading this.



1. Content from Apache XML Commons

Firstly, the W3C APIs (SVG DOM, SMIL, and SAC) that were bundled in batik-ext.jar in the 1.6 release are now re-distributed in the XML Commons project's xml-apis-ext.jar (included in the Batik distro but not of Batik).

However, there are (of course!) some wrinkles to this story.  You would think that this is all just the same code that was shipped with Batik 1.6 and already IP reviewed and contributed as org.w3c.* bundles in Orbit.  Oh, not so.

  * the org.w3c.dom.svg 1.1 API is identical to what we already
     have from Batik 1.6, except that Batik 1.6 *added* a class
     EventListenerInitializer to this package.  It is not fom W3C, but
     of Batik's devising.  So, this class was actually *removed* in
     Batik 1.7, an API breakage.
  * the org.w3c.dom.smil 1.0 API from Batik 1.6 omitted the
     W3C's TimeEvent class (this package only has two classes).
     This is rectified in the xml-apis-ext.jar
  * the org.w3c.css.sac 1.3 API from Batik 1.6 has numerous
     changes to the original W3C code, made by the Batik team.
     Some of these changes are functional changes (code removed
     fom the W3C original).  The xml-apis-ext.jar content is
     the original W3C source


How do we resolve these discrepancies against the org.w3c.* bundles already in Orbit that were modified by Batik 1.6?  Any attempt to use the same bundle names would result in API breakage for clients, but creating new bundles with the same package namespaces inside doesn't work for clients that use Import-Package because OSGi can't put the same package from two different bundles on one client bundle's classpath (I think).

In hindsight, I should have just created an org.apache.batik.ext bundle for Batik 1.6, but we would still have the problem of incompatible API changes in these dependencies between 1.6 and 1.7.  At least, though, we wouldn't have org.w3c.* bundles that aren't W3C code.  :-(

So, a couple of ideas:

  - create bundles with "w3c" in the version to indicate true-to-W3C
     code (e.g., org.w3c.css.sac_1.3.0.w3c_v200812102000).  Happily,
     'w' sorts after 'v'.  This resolves the problem of the org.w3c.*
     bundles being adulterated with non-W3C content
  - create one org.w3c.apache.xml.apis.ext bundle to contain
     all of these W3c-original APIs.  Unfortunately, they are something
     of a hodge-podge, which is why I include the reference to apache.
     This has the disadvantage of leaving the older org.w3c.* bundles
     masquerading as original W3C code
  - hide all of these packages in an org.apache.batik.ext bundle, that
     looks like what the Batik 1.6 batik-ext.jar was, and hope that
     nobody continues to use the older org.w3c.* bundles 

In all cases, I think it might be necessary to export the packages in the new Orbit bundles *without* version numbers.  As I understand it, this will avoid conflicts with clients that currently use Import-Package with version ranges to get the current definitions of these packages.

I have no idea whether any of this will actually work, or what trouble it may cause.

2.  Content from Java 1.4


So, you may ask now, "What does the 1.7 version of batik-ext.jar have in it if all of its 1.6 content is gone?"  Naturally, it has yet another W3C API, but this time one that is included in the Java core libraries since 1.4.  Oh, and of course, it is at DOM Level 3, whereas even Java 1.5 is still only at Level 2, so it has twice as many classes as in the JRE.  To top it off, Apache added another class of their own into the org.w3c.dom namespace in the 1.7 batik-ext.jar.

Batik 1.7 also has a new dependency on an additional XML Commons component, the xml-apis.jar.  This contains a bunch of org.w3c.dom.* packages not contained in the other JARS, of which many are also in JRE 1.4/1.5 (but fewer in JRE 1.3, which Batik supports).  However, the org.w3c.dom.xpath package is not in any level of the JRE, and it is required for even the simplest Batik operations.


I think may be similar to some of the head-aches that David had with the Xerces APIs?


Christian W. Damus
Senior Software Developer, Zeligsoft Inc.
Component Lead, Eclipse MDT OCL and EMF-QTV

Back to the top