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:52:40 GMT
wow! sounds complexe indeed:)
just a first tip: did you take a look at ant-contrib <variable> task to solve your immutable
properties issues?

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: Richard Gaywood []
Sent: Thu 8/4/2005 2:31 PM
Subject: 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"  />
		<!-- 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 property="tomcat-home" value="/usr/local/tomcat-jprobe">
			<and> <equals arg1="${application}" arg2="TESTSERVER" /> <equals
arg1="${port-num}" arg2="8083" /> </and>
		<condition property="tomcat-home" value="/usr/local/tomcat-testing">
			<and> <equals arg1="${application}" arg2="TESTSERVER" /> <equals
arg1="${port-num}" arg2="8081" /> </and>

		<!-- 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:

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:
For additional commands, e-mail:

View raw message