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.


Jeremias Maerki 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:
> 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

Vincent Hennebert                            Anyware Technologies
Apache FOP Committer                         FOP Development/Consulting

Reply via email to