Resolving classpath with ant <xslt> task

igraham · September 24th, 2007, 01:37 PM

I'm trying to write an ant script which invokes both XSLT 1.0 and XSLT 2.0, but so far haven't been successful.

In my build environment, the invocation of XSLT 1.0 is deep down in other ant scripts over which I have no control, and for it to work my classpath is set up upon invocation of the ant script to include xalan.jar.

My own stylesheets are XSLT 2, so I've been using Saxon 8.9.0.4j which I had been invoking by specifying saxon8.jar in the classpath attribute of the <xslt> ant task. Unfortunately, if I try to use Saxon this way in the same ant script for which the classpath already includes xalan.jar, it doesn't work - it just uses Xalan. I'm confused, because I would have thought the <xslt> classpath attribute should have completely overridden the classpath used by the ant script, or at the very least placed saxon8.jar ahead of any pre-existing classpath.

Can anyone suggest a suitable way for me to get my own <xslt> invocations to use Saxon(Saxon-B) in this case?

mhkay · September 24th, 2007, 01:47 PM

Try using the saxon-xslt Ant task

http://www.saxonica.com/documentatio...ltfromant.html

Michael Kay
http://www.saxonica.com/
Author, XSLT Programmer's Reference and XPath 2.0 Programmer's Reference

igraham · September 24th, 2007, 03:28 PM

Thanks Micheal. However, I've tried that, but I'm using Saxon-B and I get the following error message:

taskdef A class needed by class net.sf.saxon.ant.AntTransform cannot be found: com/saxonica/SchemaAwareTransformerFactory

Is it possible that there is an accidental dependency on Saxon-SA?

Ian

samjudson · September 24th, 2007, 03:32 PM

I take it you are setting schemaaware="false" and validation="skip"?

/- Sam Judson : Wrox Technical Editor -/

igraham · September 24th, 2007, 03:54 PM

No, I hadn't even got that far(but thanks for pointing out that they may not be the defaults!). It's the <taskdef> that fails because of the missing SchemaAwareTransformerFactory.

mhkay · September 25th, 2007, 03:54 PM

Yes you're right; it seems the saxon-xslt task requires Saxon-SA to be present even when it isn't used. It took me a while to reproduce it because ant's class loading is rather specialized. Sorry about that: get yourself an evaluation copy.

Michael Kay
http://www.saxonica.com/
Author, XSLT Programmer's Reference and XPath 2.0 Programmer's Reference

mhkay · September 25th, 2007, 03:59 PM

Oh, the other thing I discovered when investigating this is the -noclasspath option on the ant command line. If you use this, then I think you have a reasonable chance that the classpath option on the xslt task will take precedence over anything else.

Also, the xslt task has a nested factory element where you should be able to specify

<factory name="net.sf.saxon.TransformerFactoryImpl"/>

but I haven't tried this...

Michael Kay
http://www.saxonica.com/
Author, XSLT Programmer's Reference and XPath 2.0 Programmer's Reference

igraham · September 25th, 2007, 07:14 PM

I was about to try using that <factory> element, but then realized it doesn't help solve the problem with the ant <taskdef>. The -noclasspath option for the ant command doesn't allow me to run a single build script, because the other scripts mine invoke require an XSLT 1.0 processor already in the classpath.

I just took a look at the AntTransform code, and I think the code could work well in more environments, including my own situation, if Saxon used reflection instead. So instead of the lines

Code:

// remove this line to compile the code for use under Saxon-B only
factory = new com.saxonica.SchemaAwareTransformerFactory();

insert code something like the following:

Code:

try {
    factory = ((Class<TransformerFactoryImpl>) Class<TransformerFactoryImpl>
        .forName("com.saxonica.SchemaAwareTransformerFactory")).newInstance();
} catch (Exception e) {
    // most likely ClassNotFoundException
    // somehow report need for Saxon-SA to get schema awareness
    factory = new TransformerFactoryImpl();
}

Any chance you could do that for 8.9.0.5j?

I still think there must be something wrong with the way ant implements the <xslt>'s use of the classpath attribute, but I don't understand how trax resolves the choice of xalan vs. Saxon. It's possible it tries to find xalan first and doesn't even look for an alternative processor unless xalan is missing. I should probably go after the ant team first to see what they say.

Would having Saxon-SA eliminate the troubles I'm having entirely? Would it simply work transparently with both the 1.0 and the 2.0 transforms/stylesheets? I'm not likely to be able to convince my current client to spend the extra bit of money, but it would be nice to know that an easy solution exists for clients that use XSLT as a matter of general practice. Really I'm thinking Sun should give Saxonica a pile of money to embed Saxon for XSLT 1.0/2.0 processing within their own JRE and JDK distributions :).

Thanks again for your help!
Ian

mhkay · September 26th, 2007, 03:55 AM

Thanks. My current code has advanced quite a bit beyond the 8.9 version (which was very hastily put together, to be honest) and does indeed use reflection here (though this can cause its own problems in environments that customize the class loading). I haven't made a decision on whether to produce a patch for the 8.9 branch.

I must admit I was a bit surprised to find that the classpath in the <xslt> task doesn't completely replace the external classpath - but that discussion really belongs on an Ant forum.

The suggestion to use <factory> was on the basis that you could get the standard <xslt> task to use Saxon this way. I introduced <saxon-xslt> primarily not to help people load Saxon instead of Xalan, but to provide the extra parameters needed to control schema-aware processing.

Michael Kay
http://www.saxonica.com/
Author, XSLT Programmer's Reference and XPath 2.0 Programmer's Reference

igraham · September 26th, 2007, 03:37 PM

I'm embarrassed. After your suggestion about <factory> I skimmed the ant doc too quickly and entirely missed it, so I assumed you were referring to a feature of <saxon-xslt>. Then I did find out that I could set the factory using the javax.xml.transform.TransformerFactory system property for a java invocation, but I didn't have much luck invoking ant successfully using the <java> task which supports setting the system property. In the end I gave up.

However, after your last post I checked the ant <xslt> doc again, found the description of <factory> and tried it. The weird thing is that having specified the saxon8.jar in the classpath attribute of <xslt> and the net.sf.saxon.TransformerFactoryImpl in the <factory> element, the <xslt> task failed to find the factory class. I had to add saxon8.jar to the classpath of my invocation of ant, and then everything worked beautifully - thank-you!

I think ant's implementation for the <xslt> classpath attribute has got to be something really weird, because it certainly doesn't behave in any way that makes sense to me.

So here's the answer for anyone who wants to mix XSLT 1.0 and XSLT 2.0 invocations in the same ant script:

Make sure that the classpath passed into Ant has the necessary jars for both XSLT 1.0(either Xalan with Xerces or Saxon 6) and XSLT 2.0(Saxon 8). Then don't bother with the classpath attribute of <xslt>. Instead use something like the following:

Code:

    
    <xslt
            style="myXSLT_1_Transform.xslt"
            basedir="${source.dir}"
            destdir="${dest.dir}">
    </xslt>


    <xslt
            style="myXSLT_1_Transform.xslt"
            basedir="${source.dir}"
            destdir="${dest.dir}">
        <factory name="com.icl.saxon.TransformerFactoryImpl"/>
    </xslt>


    <xslt
            style="myXSLT_2_Transform.xslt"
            basedir="${source.dir}"
            destdir="${dest.dir}">
        <factory name="net.sf.saxon.TransformerFactoryImpl"/>
    </xslt>

Thanks again for all your help!
Ian