ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Bodewig <>
Subject Re: Weird "xslt" task behavior
Date Thu, 17 Nov 2011 11:45:29 GMT
On 2011-11-17, Jo Support wrote:

> Hello everybody,

> I've noticed a weird behavior from "xslt" task relating to relative
> paths. It seems that "xslt" task set the context for the "style"
> attribute relative path in two different ways, depending on the way
> Ant has been executed (via command line, or via Java API).

> Scenario:

> Ant version: 1.8.0/1.8.2 (both act the same way)
> OS: Windows XP

> Directory tree:

> /
> 	antscript/
> 	stylesheet/
> 	project/
> 		filestobetransformed/
> 			somesubdirswithfilestobetransformedtoo/
> 			xslttarget/

> I assumed that the attribute "basedir" of "xslt" ant task should be
> the working dir containing files to be transformed, and the path
> written in "style" attribute should be indipendent from the "basedir",
> so I wrote:

> 		<xslt basedir="/project/filestobetransformed/" extension=".xml"
> destdir="xslttarget/" style="./../stylesheet/setThisAndThat.xsl">
> 			<include name="**/pom.xml"/>
> 		</xslt>

This is how it is supposed to work.  To make this work the XSLTProcess
instance needs a Project instance set via setProject as it uses
Project#resolveFile on the value of the attribute (which makes it
relative to the project's basedir).

> All works fine when I execute the Ant script via command line, but
> when Ant is executed via Java API, it seems that the "./" heading the
> relative path in "style" attrubute, leads to the "basedir" attribute
> value,

For historical reasons <xslt> contains some fallback logic that makes it
resolve the stylesheet relative to the task's basedir, see line 357ff in

            if (xslFile != null) {
                // If we enter here, it means that the stylesheet is supplied
                // via style attribute
                File stylesheet = getProject().resolveFile(xslFile);
                if (!stylesheet.exists()) {
                    stylesheet = FILE_UTILS.resolveFile(baseDir, xslFile);

I guess what happens in your case is that when you use the task via the
Java API your project instance's basedir isn't set properly and thus
getProject().resolveFile(xslFile) resolves to a non-existant file.

In a few minutes I'll modify Ant's trunk to revert the file name back to
the one resolved by the project instance when reporting the file
wouldn't exist.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message