ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Reilly <peter.rei...@corvil.com>
Subject Re: Problem with <macrodef> + <script language="javascript"> on W indo ws
Date Fri, 12 Mar 2004 09:29:35 GMT
I think that Stefan is correct.

The macrodef

update-module-help
uses 
        <property name="@{name}.dest"
                  location="${helpzips}/com_lgc_@{name}_help.zip" />
and on windows this will generate:

c:\helpzips\com_lgc_name_help.zip

assuming ${helpzips} is c:/helpzips and @{name} is name.

in the javascript code, this string gets substituted into the code by the macrodef:
          file = project.resolveFile("c:\helpzips\com_lgc_name_help.zip");
This does not work of course.

One may use a property as you have done to work around this. - this would
be a valid use-case for local properties.

Alternativly you could use jython as the scripting language:

<script language="jython">
file = project.resolveFile(r"@{file}")
project.setNewProperty("@{property}", file.lastModified())
</script>

The r"" raw-string notation is quite powerfull.

Peter

 


Dominique Devienne wrote:

>>From: Stefan Bodewig [mailto:bodewig@apache.org]
>>
>>On Mon, 8 Mar 2004, Dominique Devienne <DDevienne@lgc.com> wrote:
>>
>>    
>>
>>>          file = project.resolveFile("@{file}");
>>>      
>>>
>>...
>>
>>    
>>
>>>In the <last-modified> macro, when called from the other macro,
>>>the file attribute has lost of its back-slashes '\'...
>>>      
>>>
>>Because it lives inside a JavaScript string and JavaScript uses
>>backslashes as escape characters.  <macrodef> is only doing a textual
>>replace.
>>    
>>
>
>What I don't understand is that the first macro I listed works
>when used directly (i.e. when that macro is not used within another
>macro). So I suspect it's the macro-within-macro has something to
>do with it.
>
>I haven't tried, but I'm pretty sure if I was to implement that
><last-modified> macro into a Java task, things would work as expected
>which is why again I suspect <macrodef> to have something to do with
>it... But of course I've been known to be wrong ;-)
>
>  
>
>>Turn
>>    
>>
>>>      <property name="@{name}.dest"
>>>                location="${helpzips}/com_lgc_@{name}_help.zip" />
>>>      
>>>
>>into
>>
>>      <property name="@{name}.dest"
>>                value="${helpzips}/com_lgc_@{name}_help.zip" />
>>
>>It won't hurt since you are using project.resolveFile anyway and you
>>don't have any backslashes in the string - unless the expanded
>>helpzips property contains some.
>>    
>>
>
>It doesn't, which is why I used location. @{name}.dest is not used
>only by the <last-modified> macro. --DD
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
>For additional commands, e-mail: dev-help@ant.apache.org
>
>
>
>  
>


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


Mime
View raw message