ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jo Support <jo.supp...@gmail.com>
Subject Re: Weird "xslt" task behavior
Date Thu, 17 Nov 2011 12:19:37 GMT
Thanks a lot Stefan.

Exactly, I've trusted the Java API call code written by a coworker of
mine, but when I told him to check it twice he found he set the
basedir wrong. It happens in teamworking...

Thanks once again,
Jo

On Thu, Nov 17, 2011 at 12:45 PM, Stefan Bodewig <bodewig@apache.org> wrote:
> 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
> <http://svn.apache.org/repos/asf/ant/core/trunk/src/main/org/apache/tools/ant/taskdefs/XSLTProcess.java>
>
>            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.
>
> Stefan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
> For additional commands, e-mail: user-help@ant.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
For additional commands, e-mail: user-help@ant.apache.org


Mime
View raw message