ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Erik Hatcher" <>
Subject Re: Build numbers - always available (all targets), sometimes incremented (compile target only)
Date Mon, 11 Feb 2002 11:58:38 GMT

----- Original Message -----
From: "chris brown" <>

> I'm trying to create a build file that includes a build number.

> 1./
> I can't seem to conditionally set a property.  If ${build.number} is
> available from a properties file, that's fine.  If it isn't, I'd like it
> be set to 0.  But the only way to conditionally use the <property> task
> (AFAIK) is to put it into a conditional target, which seems somewhat

Ah, but here is where folks miss the beauty of immutable properties:

<property file=""/>
<property name="build.number" value="0"/>

There is your condition right there!  :)  If build.number is defined in, the task to set it to zero is ignored.

> An <if> task would be nice.  It could contain a <tests> element,
> (possibly recursive) <and>, <or>, and <not> elements, followed by a
> of task elements to execute if the conditions evaluate to true.  Then, by
> using a <propertytest property="myproperty" defined="true"/> element, I
> could conditionally set my variable in the correct scope.

Don't make life any more complicated with such constructs.  <condition>
exists in Ant 1.4.1, but its really a last resort construct for when the
other features don't apply.

> 2./
> I can't seem to modify a property's value if it has already been set.  For
> example, I'd like to load in the property (here, ${build.number}) using
> <property file="..."> to get a current value.  I'd like to do this in the
> "init" task for two reasons: avoid duplication, and avoid problems when
> executing multiple targets (e.g.: "ant compile docs" from command line).

Properties are immutable.  This is a feature, and a *very* important one.

> For build "n", I'd like to apply (with filtering) the number "n" to the
> target.  For the compile target, I'd like to apply "n+1"... however, even
> I increment this using the <propertyfile> task, then reload it using the
> <property> task (with the "file" attribute), the value of the build number
> property remains the same during the execution of the build script (even
> although the property file is correctly updated on disk), meaning that in
> the build script, filtering applies the number of the previous build to
> code...

You ought to look into using <antcall> for these kinds of things - where you
can control the property values for every invocation of a target.

> 3./
> There's no way to define one property's value relative to another
> value...  I can't say for example:
> <property name="prop1" based-on="prop2" type="int" operation="+"/>

Two options: <propertyfile> has increment capability and you could use a
property value in the 'value' attribute, or check out the selector stuff
provided in the middle of this request:

> In the real project I'm working on, it's made more complicated by the fact
> that it builds a system containing three subcomponents.  Sometimes I'll
> build one, sometimes two, sometimes all.  Each component needs a separate
> build number, which should only be incremented when each
> "compile-component-1/2/3" target is run (so I need to use <propertyfile>
> several places).

Sounds like you need to separate things into separate build files, one for
each component, and a master controlling one.


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

View raw message