I guess I don't completely understand why it's better to move away
from the status quo (if it's not broken don't 'fix' it) and increase
(IMHO) complexity.

IMO it's not enough to say 'it'll make better, more knowledgeable FOP
users' (to paraphrase ;-). I'd need measurable--or at least--obvious
benefits.

If Java experts can't easily override our versions, that may be enough
impetus. But if they can, then my 'vote' would be a fat -0... Tnot a
veto)...

I would think it'd be better to wait for a separation of Batik
dependencies, or some compelling reason.

Web Maestro Clay



On 1/31/08, Jeremias Maerki <[EMAIL PROTECTED]> wrote:
>
> On 31.01.2008 12:49:57 Vincent Hennebert wrote:
> > Hi Jeremias,
> >
> > Jeremias Maerki wrote:
> > > Vincent's feedback reminded me about something else we probably should
> > > look at. Vincent proposed to add a dependency on the Xerces/Xalan XML
> > > serializer. As noted, I'd prefer to stick to plain JAXP. But yes, with
> > > Java 1.4 JAXP is built in so the 4 XML JARs are actually not necessary
> > > anymore (would one think). There are several things we can do:
> >
> > I guess you're talking of the following ones:
> > - serializer-2.7.0.jar
> > - xalan-2.7.0.jar
> > - xercesImpl-2.7.1.jar
> > - xml-apis-1.3.02.jar
>
> Yes.
>
> > Then what does the xml-apis-ext.jar actually stand for? Obviously it's
> > needed but I'm not clear what it corresponds to. I guess it has nothing
> > to do with JAXP?
>
> DOM interfaces for SVG, SMIL etc.. They're not part of JAXP like other
> DOM interfaces.
>
> BTW, xml-apis-1.3.02.jar contains the the DOM Level 3 APIs (including
> XPath support) which represents a superset of JAXP 1.4.
>
> >
> > > 1. Just remove them.
> > >
> > > Good:
> > > - Makes the distribution a lot smaller.
> > >
> > > Problems:
> > > - Early Java 1.4 and 1.5 JVMs contain (very) old and buggy JAXP
> > > implementations. It's a good idea to always replace them (this gets me
> > > to solution 2).
> > > - Our test code has a (useful) dependency on Xalan's XPath API. Java 1.4
> > > provides an old JAXP version without XPath support (javax.xml.xpath,
> > > available with Java 1.5). So we've got a problem here for the time
> being.
> >
> > Note that by removing the 4 aforementioned jars and using a 1.5 jdk
> > I have unresolved import errors in the
> > org.apache.fop.layoutengine.EvalCheck class. And an "Organize imports"
> > in Eclipse gives me com.sun classes. Is that to be expected? The missing
> > classes are in the xalan jar. If I add this jar to the build path I then
> > have the following error in
> > org.apache.fop.image.loader.batik.PreloaderSVG:
> > "The type org.w3c.dom.xpath.XPathEvaluator cannot be resolved. It is
> > indirectly referenced from required .class files"
> > I have to add the xml-apis.jar to the build path to solve that error.
> > With a 1.6 jdk I don't have this problem.
> > Have I missed anything?
>
> No, I have. Batik 1.7 works with a Level 3 DOM which is not even in Java
> 6 (only javax.xml.xpath is in JAXP 1.4 and therefore in Java 6). Batik's
> AbstractDocument implements the Level 3 XPathEvaluator and provides the
> functionality through Xalan-J. I think this is used for SVG 1.2
> functionality.
>
> See also:
> http://svn.apache.org/viewvc?view=rev&revision=201418
> http://wiki.apache.org/xmlgraphics-batik/UsingDOM3
>
> That means that as long as we have Batik as a mandatory dependency [1]
> on our core we also have a dependency on DOM Level 3 and Xalan-J which
> means we cannot remove any of the 4 JARs, except xerces.jar probably
> which doesn't really have a big effect in itself. Hehe. We're back to my
> solution 2 (or the status quo). And it would mean we can simply use
> javax.xml.xpath as we like.
>
> Note that it's probably not necessary to always put those JARs in the
> bootclasspath (or lib/endorsed) just to make FOP/Batik work. Otherwise,
> we'd already have many more questions about failing XML processing.
>
> [1] Making Batik an optional dependency on FOP has been the wish of some
> users in the past (but not recently). It's something I'd like to see if
> only to enforce a cleaner design in FOP. But since I know many here
> prefer a single source tree for all sources rather than splitting FOP
> into more modules, I haven't pushed this. I'm not sure what this would
> mean for user with limited knowledge of Java if they have to deal with
> different classpath requirements depending on whether they use SVG or
> not. And for building the plug-ins all the JARs will need to be there
> anyway (or downloaded via Apache Ivy).
>
>
> > > 2. Move the 4 JARs to a lib/endorsed directory and adjust our scripts to
> > > insert them into the bootclasspath which has the effect of overriding
> > > the JAXP implementation of the JVM.
> >
> > I thought the only way to override the JAXP implementation bundled with
> > the JVM was to put the jars in the lib/endorsed/ directory of the JVM
> > installation?
>
> Nono, -Xbootclasspath/p:<myjars> is another.
>
> >
> > > Good:
> > > - This also makes it much clearer that these JARs are not a dependency
> > > like every other.
> > >
> > > Problems:
> > > - User might wonder why the JARs are suddenly in a different place.
> > >
> > > Open Question:
> > > - Should we start programming against JAXP 1.3 (because of the XPath
> API)?
> > > But that requires that all users install JAXP 1.3 implementations in
> > > their environments which can be problematic for older application
> > > servers (like an old WebSphere which is used in many bigger companies).
> > > I'd say we should stick to JAXP 1.2 until we can move to Java 1.5.
> > >
> > > 3. Remove the implementations but not the xml-apis.jar with the JAXP 1.3
> > > API.
> > >
> > > Good:
> > > - Allows us to use the XPath and Validation facilities.
> > >
> > > Problems:
> > > - Pre-programmed user problems because old JAXP implementations are
> > > present and people don't know how to replace them or are not allowed to
> > > replace them or it's a stability danger to the whole application server
> > > when replacing it once you figure out how to do it.
> >
> > I would also go with 1., if there is a suitable answer to my question
> > above. When releasing the 1.4 versions of FOP we can always add the
> > xml-apis.jar ourselves in the lib/ directory to be able to run the
> > tests.
>
> 1 does not seem to be possible at the moment due what you uncovered.
>
>
> Jeremias Maerki
>
>

-- 
Sent from Gmail for mobile | mobile.google.com

Regards,

The Web Maestro
-- 
<[EMAIL PROTECTED]> - <http://homepage.mac.com/webmaestro/>
My religion is simple. My religion is kindness.
- HH The 14th Dalai Lama of Tibet

Reply via email to