| [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. Christian ----- 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 E-mail: cdamus@xxxxxxxxxxxxx |