Thanks Jeremias.

There are two different aspects I think:
- we used to provide JAXP for the convenience of Java 1.3 users. Now
 that we have moved to Java 1.4 there is no reason anymore to provide
 it. As Andreas said, buggy implementations bundled with early versions
 of Java 1.4 or 1.5 is not really our problem. I may be wrong, but
 I assume that “standalone” users (those running FOP on their own
 machine for private-like project) will always have a reasonably recent
 version of Java, and will be happy to be told to upgrade anyway if
 they have any problem. While power users setting up FOP in
 a server-like environment are already aware of those early JAXP issues
 and know how to handle them.
 Which means we forget any endorsed mechanism.
- for the rest I consider the following: FOP appears to have
 dependencies which are simply not in the Java 1.4 Standard Library.
 Just like any other dependency they will be put in the lib/ directory
 and added to the classpath. They won’t affect the JAXP implementation
 bundled with the JVM.
 It just appears that the classes in the org.w3c.dom.xpath package are
 available in later versions of JAXP, but we forget that and this will
 be transparent to the user: those using Java 1.4 and 1.5 will find
 those classes in the xml-apis.jar, those using later versions will get
 them through their JAXP implementations.
 Once we switch to Java 1.7 (or whichever includes them in the standard
 library) as a minimal requirement, we remove the xalan.jar and
 xml-apis.jar, and we switch the org.apache.xpath namespace to

Which means for today that we remove the no longer necessary
serializer.jar and xercesImpl.jar and we keep the other ones.
Solution 1, amended.

I hope I’m clear.


I like this idea best of the ideas to go by so far.

Here's my perspective on Clay's issue (why bother if it works as is?): I string together chains of tools that my customers use for document production. I'd like to have as much control as possible over which tools I use. So, removing Xalan from FOP gives me one more place to have some control of the process. That's a good thing, at least to me.

Also, as Vincent mentioned, it provides an opportunity to educate people (not just users but also the developers of other tools) about what exactly FOP does. That is, it makes FOP's boundaries clearer and cleaner. IMO, that's also a good thing.

If this were the proposed re-arrangement of the jars, I'd vote for it. However, I gather that some other ideas may still come rolling in (perhaps in response to this latest iteration of the core idea). Also, I understand that it's not an issue needing a vote (yet).

Jay Bryant
Bryant Communication Services

Reply via email to