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 E-mail:[EMAIL PROTECTED] -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Thu 8/4/2005 2:52 PM To: user@ant.apache.org; [EMAIL PROTECTED] Subject: AW: More on antcall versus macrodef 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:[EMAIL PROTECTED] >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: [EMAIL PROTECTED] For >additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] 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.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
