----- Original Message -----
From: "chris brown" <[EMAIL PROTECTED]>
> 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
to
> 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
clusmy.
Ah, but here is where folks miss the beauty of immutable properties:
<property file="build.properties"/>
<property name="build.number" value="0"/>
There is your condition right there! :) If build.number is defined in
build.properties, the task to set it to zero is ignored.
> An <if> task would be nice. It could contain a <tests> element,
containing
> (possibly recursive) <and>, <or>, and <not> elements, followed by a series
> 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
docs
> target. For the compile target, I'd like to apply "n+1"... however, even
if
> 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
the
> 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
property's
> 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:
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=1733
> 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
only
> 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>
in
> several places).
Sounds like you need to separate things into separate build files, one for
each component, and a master controlling one.
Erik
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
