ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <Jan.Mate...@rzf.fin-nrw.de>
Subject AW: More on antcall versus macrodef
Date Thu, 04 Aug 2005 12:52:12 GMT
Just a note: I like the idea of using property-files

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

life.properties    
    tomcat-home=d:/tomcat5.0
test.properties
    tomcat-home=/usr/local/tomcat-testing
    port=8081
dev.properties
    tomcat-home=/usr/local/tomcat-dev
    port=8082
jprobe.properties
    tomcat-home=/usr/local/tomcat-jprobe
    port=8083
default.properties
    tomcat-home=/usr/local/tomcat
    port=8080


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

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



Jan


>-----Urspr√ľngliche Nachricht-----
>Von: Richard Gaywood [mailto:richardgaywood@gmail.com] 
>Gesendet: Donnerstag, 4. August 2005 14:31
>An: user@ant.apache.org
>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" 
>value="/usr/local/tomcat-dev">
>			<and> <equals arg1="${application}" 
>arg2="TESTSERVER" /> <equals arg1="${port-num}" arg2="8082" /> </and>
>		</condition>
>		<condition property="tomcat-home" 
>value="/usr/local/tomcat-jprobe">
>			<and> <equals arg1="${application}" 
>arg2="TESTSERVER" /> <equals arg1="${port-num}" arg2="8083" /> </and>
>		</condition>
>		<condition property="tomcat-home" 
>value="/usr/local/tomcat-testing">
>			<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: 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