How to execute XSLT 2.0 with ant? - xslt

I'm trying to run an XSLT transformation from an ant file.
I'm using a XSLT 2.0 stylesheet with a saxon 9 parser (supporting XSLT 2.0).
The problem is that it seems that ant is always calling an XSLT 1.0 parser.
Here's my ant file :
<xslt style="stylesheet.xslt"
basedir="core/"
extension=".xml"
destdir="core/"
classpath="D:\\DevTools\\saxon\\bin\\saxon9.jar">
</xslt>
If I call it directly (without ant), it's working.
Any idea ?

The problem is that while Saxon is added to the classpath, the default JAXP mechanism to determine which TransformerFactory is used and it will use the default that is Xalan. You either need to:
Set javax.xml.transform.TransformerFactory system variable to net.sf.saxon.TransformerFactoryImpl,
Add saxon9.jar to the CLASSPATH system variable, or
Use <factory name="net.sf.saxon.TransformerFactoryImpl"/> inside the xslt element

If you are having this problem, check that you are not using Ant 1.8.1, because there is a bug in Ant 1.8.1 that prevents this from working. (Though this is not the problem in the original post, because that was before Ant 1.8.1 was released).
Your options are:
Use a version of Ant that does not have the bug (e.g. Ant 1.7.1).
Explicitly specify saxon9.jar in the CLASSPATH to Ant before it starts, by either:
Setting the system CLASSPATH environment variable, or
Use the -lib command line option to ant
Define your own task using SAXON Ant (as described by another answer on this thread).
Workaround by adding processor="org.apache.tools.ant.taskdefs.optional.TraXLiaison" as an attribute of the xslt task element.
I would suggestion using option 1, followed by option 4.
Option 2 will work, but it places the responsibility on the person running ant to set up their environment and run ant properly. I assume you don't want that, which is why you are trying to get the classpath attribute on the xslt task to work.
Option 3 has limitations, because SAXON Ant requires downloading and installing its JAR file. Also SAXON Ant does not work with SAXON 9.2 or later (and SAXON Ant has not been updated since it was created in June 2008).
In theory, specifying a factory subelement makes the XSLT processor that you want to use explicit -- to prevent the class loader from finding a different XSLT processor earlier in its search, and using it instead of your XSLT processor which is further down in the CLASSPATH. In practice (at least in ant 1.7.0, 1.7.1 and 1.8.0) if the factory subelement is specified the xslt task ignores the classpath attribute -- which means you have to resort to explicitly specifying the CLASSPATH (option 2). So it doesn't help solve the original problem. However, this seems to have been fixed in the Ant source code, so could work in releases after 1.8.1.

This tutorial seems to give step by step instructions on how to do what you are asking:
http://www.abbeyworkshop.com/howto/xslt/ant-saxon/index.html
From that it appears you are doing the correct thing. Are you sure you need the double back slashes?
Update: The xslt Ant documentation mentions the 'factory' property which may help you get closer:
http://ant.apache.org/manual/Tasks/style.html

EDIT: Dr. Michael Kay has pointed out that the AntTransform is no longer supported, nor recommended.
Create a taskdef from the Saxon AntTransform class:
<taskdef name="saxon-xslt" classname="net.sf.saxon.ant.AntTransform" classpath="${basedir}/lib/saxon/saxon9.jar;${basedir}/lib/saxon/saxon9-ant.jar"/>
<saxon-xslt
in="${source.xml}"
out="${out.dir}/${output.xml}"
style="${basedir}/${stylesheet.xsl}"
force="true">
</saxon-xslt>
I have begun using the standard <xslt> task with the saxon jar specified in a <classpath>, but had been running into performance issues. It seemed to "hang" for a bit when the task was called. I have found that adding processor="trax" and specifying <factory name="net.sf.saxon.TransformerFactoryImpl"/> helps it run much faster.
<xslt in="${source.xml}"
out="${out.dir}/${output.xml}"
style="${basedir}/${stylesheet.xsl}"
processor="trax">
<factory name="net.sf.saxon.TransformerFactoryImpl"/>
<classpath refid="saxon-classpath" />
</xslt>

Rather than waiting for this to be fixed in 1.8.2 and then waiting for everyone to eventually upgrade to 1.8.2, you can roll your own XSLT macro (for situations where you explicitly want to use Saxon, rather than a user selected XSLT engine)
<macrodef name="xslt" uri="com.mycompany.mydepartment">
<attribute name="in" />
<attribute name="out" />
<attribute name="style" />
<attribute name="classpath" default="${saxon.jar.path}" />
<attribute name="taskname" default="mydep:xslt" />
<element name="params" optional="true" implicit="true" />
<sequential>
<java classname="net.sf.saxon.Transform"
classpath="#{classpath}"
taskname="#{taskname}">
<classpath path="${saxon.jar.path}" />
<arg value="-s:#{in}" />
<arg value="-xsl:#{style}" />
<arg value="-o:#{out}" />
<params />
</java>
</sequential>
</macrodef>
you can then invoke it like (assuming xmlns:mydep="com.mycompany.mydepartment" is set on the project element)
<mydep:xslt in="${myinput}"
out="${myoutput}"
style="${myxslt}">
<arg value="param1=value1" />
<arg value="param2=value2" />
<arg value="+param3=somefile.xml" />
</mydep:xslt>
You can find the docs for passing parameters to Saxon at http://www.saxonica.com/documentation/using-xsl/commandline.xml

At least in ant 1.8.0, the xslt task with a specified classpath is very slow.
The problem seems to be classpath loading. I ran ant under JDB and it spent all of the extra time in org.apache.tools.ant.AntClassLoader.loadClass reading zip files.
I tried this before running ant it it went a lot faster:
ant -lib /path/to/saxon/saxon9.jar
The macrodef from Tom Howard works better, and although it has an odd syntax for XSLT params, at least it's possible.

Related

Running eXist-db XQuery in Saxon

What is the recommended way in Saxon to load in an XML document from eXist-db via XQuery GET/POST within an XSL stylesheet? I want to run an XQL query in eXist-db, which should be simple enough to do as a GET with <xsl:variable name="test" select="doc('xmldb:exist:///db/test.xql')"/> or <xsl:variable name="test" select="doc('http://localhost:8080/exist/rest/db/test.xql')"/>. But the former doesn't exectute the query and tries to return the XQL source as XML, and the latter doesn't have the basic authentication to execute. Also, I really want to send an XML fragment using POST, and have the XQL use that posted XML fragment.
I can't find anything in the Saxon documentation about this. I did find an old EXPath article at http://expath.org/modules/http-client/samples, but the downloads there are 7 years old, and may not work with modern Saxon. So looking for the best known method to do this.
The first thing that comes to mind is the EXPath HTTP Client module. There's no way to persuade the doc() or document() functions to do POST instead of GET, AFAIK.

Controlling JRebel package scope

I am trying to speed up execution of code being debugged with JRebel. In particular, I notice that framework code is slow. I am wondering whether I can tell JRebel to ignore certain packages, in much the same way that we can setup JProfiler to ignore certain packages and patterns.
You most definitely can.
Use a system property (or add to jrebel.properties) meant just for that purpose. More information at JRebel agent properties.
-Drebel.exclude_packages=PACKAGE1,PACKAGE2,...
Specify the excluded packages in rebel.xml using Ant-styled patterns. More information at rebel.xml configuration.
<?xml version="1.0" encoding="UTF-8"?>
<application xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://www.zeroturnaround.com" xsi:schemaLocation="http://www.zeroturnaround.com http://update.zeroturnaround.com/jrebel/rebel-2_1.xsd">
<classpath>
<dir name="/path/to/module/build/directory/root">
<exclude name="com/yourapp/package1/internal/**"/>
</dir>
</classpath>
</application>
Both ways work similarly but since the second one enables to customize each module inividually it is generally preferred.

Using saxon:line-number() with the Ant XSLT task

I am using the saxonb9-1-0-8j processor.
I am running my transformation using the <xslt> task in Ant.
I would like to use Saxon's extension functions such as saxon:line-number().
I have found that the -I option allows line numbering for the current document (reference).
My question is: How to allow line numbering via the <xslt> task?
The Ant documentation for <xslt> says there should be a nested attribute element to pass processor specific settings. However, I wasn't able to find the correct syntax.
How can I use Saxon extension functions like saxon:line-number() with Ant?
Try
<factory name="net.sf.saxon.TransformerFactoryImpl">
<attribute name="http://saxon.sf.net/feature/linenumbering" value="true"/>
</factory>
The suggestion is based on the 9.5 documentation http://saxonica.com/documentation9.5/using-xsl/xsltfromant.html, I would guess it is not different in 9.1, check its documentation yourself at http://saxon.sourceforge.net/ if needed.

Multiple XSLT files in a single pipeline with ant

I have multiple XSLT files that I'm using to process my source XML in a pipeline. I know about the trick with exsl:node-set but after having some issues with this workflow, I took the decision to split the various passes into separate XSL files. I'm much happier with the structure of the files now and the workflow works fine in Eclipse. Our release system works with ant. I can process the files like this:
<xslt basedir="src-xml" style="src-xml/preprocess_1.xsl" in="src-xml/original.xml" out="src-xml/temp_1.xml" />
<xslt basedir="src-xml" style="src-xml/preprocess_2.xsl" in="src-xml/temp_1.xml" out="src-xml/temp_2.xml" />
<xslt basedir="src-xml" style="src-xml/preprocess_3.xsl" in="src-xml/temp_2.xml" out="src-xml/temp_3.xml" />
<xslt basedir="src-xml" style="src-xml/finaloutput.xsl" in="src-xml/temp_3.xml" out="${finaloutput}" />
But this method, going via multiple files on disk, seems inefficient. Is there a better way of doing this with ant?
Update following Dimitre's suggestion
I've created myself a wrapper around the various other XSLs, as follows:
<xsl:stylesheet version='1.0' xmlns:xsl='http://www.w3.org/1999/XSL/Transform' xmlns:fn='http://www.w3.org/2005/xpath-functions' xmlns:exslt="http://exslt.org/common">
<xsl:import href="preprocess_1.xsl"/>
<xsl:import href="preprocess_2.xsl"/>
<xsl:import href="preprocess_3.xsl"/>
<xsl:import href="finaloutput.xsl"/>
<xsl:output method="text" />
<xsl:template match="/">
<xsl:apply-imports />
</xsl:template>
</xsl:stylesheet>
This has... not worked well. It looks like the document had not been preprocessed before the final output XSL ran. I should perhaps have been clearer here: the preprocess XSL files are modifying the document, adding attributes and the like. preprocess_3 is based on the output of ..._2 is based on ..._1. Is this import solution still appropriate? If so, what am I missing?
The more efficient method is to perform a single, multipass transformation.
The files can remain as they are -- they will be imported using xsl:import instructions.
The savings are obvious:
Just one initiation (loading of the XSLT processor).
Just one termination.
Eliminates the two intermediate files and their creation, writing into, closing and deleting.
Hmm, you say I know about the trick with exsl:node-set, but you don't use it in your attempt ("Update following Dimitre's suggestion"). In case you don't know it, or for the others (like me) who don't know how to perform multipass transformation, here is a nice article: Multipass processing.
The drawback of this approach is that it requires engine specific xsl code. So if you know the engine, you could try this. If you don't know the engine, you could try with solutions from result tree fragment to node-set: generic approach for all xsl engines.
Looking at these sources one conclusion is sure: your current solution is more readable. But you are seeking efficiency, so some readability may be sacrificed.

XSLT Unit testing

Does anyone know of a way to write unit tests for the XSLT transformation?
I've a lot of XSLT files and it's getting harder to test them manually. We have an example XML and can compare it to the resulting output XML from the XSL transormation. However, I'm looking for a better test method.
I am currently looking for some good options to do this as well. As a result, I came across this question, and a few other potential candidate solutions. Admittedly, I haven't tried any of them yet, so I can't speak to their quality, but at least they are some other avenues potentially worthy of researching.
Jenni Tennison's Unit Testing Package
UTF-X Unit Testing Framework
Juxy
XTC
Additionally, I found the following article to be informative in terms of a general methodology for unit testing XSLT.
Unit test XSL transformations
Try XSpec, a testing framework for XSLT. It allows you to write tests declaratively, and test templates and functions.
Looks like Oxygen editor has Unit Testing available as well. It "provides XSLT Unit Test support based on XSpec".
I haven't tried it myself, but will soon.
Here are a few simple solutions:
Use xsltproc with a mock XML file:
xsltproc test.xsl mock.xml
XSLT Cookbook - Chapter 13
Create a document() placeholder variable and comment/uncomment it manually:
<xsl:variable name="Data" select="descendant-or-self::node()"/>
<!--
<xsl:variable name="Data" select="document('foo.xml')" />
-->
<xsl:if test="$Data/pagename='foo'">
<p>hi</p>
</xsl:if>
Create a condition to swap the comment programmatically:
<xsl:variable name="Data">
<xsl:choose>
<!-- If source XML is inline -->
<xsl:when test="descendant-or-self::node()/pageName='foo'"/>
<xsl:value-of select="descendant-or-self::node()"/>
</xsl:when>
<!-- If source XML is external -->
<xsl:otherwise>
<xsl:value-of select="document('foo.xml')" />
</xsl:otherwise>
</xsl:choose>
</xsl:variable>
Use a shell script to inline the data programmatically in the build to automate the tests completely.
References
Transformiix Test Cases
Running XSLT at the Department: Command Line XSLT Processing
Building TransforMiiX standalone - Archive of obsolete content | MDN
OASIS XSLT Conformance TC Public Documents
Using XSLT to Assist Regression Testing
MicroHowTo: Process an XML document using an XSLT stylesheet
Tip: Debug stylesheets with xsl:message
Batch XSLT Processing
Embedded Stylesheet Modules: XSL Transformations (XSLT) Version 3.0
Multi layer conditional wrap HTML with XSLT
XPath 1.0: Axes
CentOS 7.0 - man page for xsltproc
XMLStarlet command line XML toolkit download | SourceForge.net
We have been using Java based unit test cases, in which we provide expected xml string after transformation and input xml string which needs to be transformed using some XSL.
Refer to following package if you want to explore more.
org.custommonkey.xmlunit.Transform
org.custommonkey.xmlunit.Diff
org.custommonkey.xmlunit.DetailedDiff
I´m using this tool: jxsltunit.
The test is defined by an XML file which is then passed to the tool. This is an example of the test configuration:
<xsltTestsuite xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="jxsltunit jxslttestsuite.xsd" xmlns="jxsltunit"
description="Testsuite Test"
xml="min-test.xml"
xslt="min-test.xslt"
path="pa > ch">
<xsltTestcase match_number="0">
<![CDATA[<ch>child 1</ch>]]>
</xsltTestcase>
<xsltTestcase match_number="1">
<![CDATA[<ch>child 2</ch>]]>
</xsltTestcase>
</xsltTestsuite>
It takes the XML, the XSL and a path in the transformed XML which gets tested. The path can contain a list which elements are identified by their index.
One benefit of this tool is that it can output the results as a junit XML file. This file can be picked up by your Jenkins to show the XLST-tests in your test results. Just add the call to the tool as a build step.
Try Jenni Tennison's Unit Testing Package (XSpec), which is a unit test and behaviour-driven development (BDD) framework for XSLT, XQuery, and Schematron. It is based on the Spec framework of RSpec, which is a BDD framework for Ruby.
With XSpec you can test XLT template wise or XPath wise per your need.
For an overview on how to use/handle/write (installation|execution) click https://github.com/xspec/xspec/wiki/What-is-XSpec