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
javax.xml.xpath.
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.
WDYT?
Vincent
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
http://www.bryantcs.com/
