ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <>
Subject RE: More on antcall versus macrodef
Date Thu, 04 Aug 2005 13:55:54 GMT
yes indeed.
I was going to provide the same advice, as i am using prefixed properties files to get rid
of the if-then-else idiom.

Hind Lwahhabi.
Accenture Belgium - Financial Services & Insurance
Koningstraat 145 Rue Royale, B-1000 Brussels, Belgium
mobile: +32 499567544
phone: + 32 2 226 75 44

-----Original Message-----
From: []
Sent: Thu 8/4/2005 2:52 PM
Subject: AW: More on antcall versus macrodef
Just a note: I like the idea of using property-files

<property file="${server}.properties"/>
<property file=""/>    

When using (only) in a macrodef you could prefix them.

    <attribute name="prefix"/>
        <property file="..." prefix="@{prefix}."/>
        <copy todir="@{prefix}.tomcat-home"> ...


>-----Urspr√ľngliche Nachricht-----
>Von: Richard Gaywood [] 
>Gesendet: Donnerstag, 4. August 2005 14:31
>Betreff: More on antcall versus macrodef
>Hi all. Short time lurker, first time poster but I did search 
>the archives! I'm pretty sure I can hear list regulars 
>groaning at my subject line but here goes.
>I'm build manager for a fairly chunky Java webapp with an 
>overly complex Ant 1.5 build script that I am refining using 
>the new features in 1.6. Just splitting it into a couple of 
>separate files with <import> declarations has helped, but I've 
>run into a problem with parameterising the build.
>Without wanting to bog anyone down in the details, the build 
>script outputs WARs for several different environments -- 
>different servers, different OSs, and so on. Currently, the 
>build process, at the top level, invokes a number of <antcall> 
>tasks, each setting some basic
>properties: the name of the destination server and WAR file 
>name for this build. From these basic properties, other 
>properties are calculated; for example, if destination machine 
>is Linux, use /usr/local/tomcat and if it's Windows, use 
>d:/tomcat. To make matters worse, one of our Linux test 
>servers has four (!) Tomcat installs, with different port 
>numbers and directories to configure.
>About a dozen of these parameters are calculated and 
>eventually end up written into some text files via a <replace> 
>call. Basically, they are used all over the place, in various targets.
>For example, this is my define-tomcat-home target:
>	        <!-- set tomcat home directory for windows machines -->
>		<condition property="tomcat-home" value="d:/tomcat5.0">
>			<equals arg1="${application}" arg2="WINDOWS"  />
>		</condition>
>		<!-- now handle the development environments -->
>		<condition property="tomcat-home" 
>			<and> <equals arg1="${application}" 
>arg2="TESTSERVER" /> <equals arg1="${port-num}" arg2="8082" /> </and>
>		</condition>
>		<condition property="tomcat-home" 
>			<and> <equals arg1="${application}" 
>arg2="TESTSERVER" /> <equals arg1="${port-num}" arg2="8083" /> </and>
>		</condition>
>		<condition property="tomcat-home" 
>			<and> <equals arg1="${application}" 
>arg2="TESTSERVER" /> <equals arg1="${port-num}" arg2="8081" /> </and>
>		</condition>
>		<!-- all other applications, including live 
>builds, default to Linux pathnames -->
>		<!-- note that as Ant properties are immutable, 
>the line below cannot
>		     override a setting made above (or on the 
>command line) -->
>		<property name="tomcat-home" 
>value="/usr/local/tomcat" />
>There is quite a bit more like this. 
>Am I right in thinking that there is essentially no easy way 
>to port this over to MacroDefs? It's these local vs immutable 
>properties that scupper me. I need to loop through build tasks 
>like the above snippet lots of times with different values, 
>and that's not going to work with globally immutable properties.
>Does anyone have any tips I've missed on getting around this, 
>or should I stick to AntCall for now?
>And before anyone points out this is rather overly complex: I 
>know, but it's a complicated, already written app and I can't 
>change it now.
>So I'm stuck with it.
>To unsubscribe, e-mail: For 
>additional commands, e-mail:

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

This message is for the designated recipient only and may contain privileged, proprietary,
or otherwise private information.  If you have received it in error, please notify the sender
immediately and delete the original.  Any other use of the email by you is prohibited.

View raw message