> From: Shackelford, John-Mason [mailto:john-mason.shackelford@pearson.com]
>
> I have tried to be a purist and avoid the antcontrib if task, but it
> doesn't
> appear to be possible to make effective use of macrodef without it. I was
> looking forward to using macrodef to help me solve the classic problem
> wherein one wants to reuse an ant snippet in two different targets, and in
> one target the snippet requires some action first, whereas in the second
> target the action isn't required at all.
>
> <target name="build" depends="init,clean">
> <!-- macrodef calls -->
> <build-jar-deps />
> <build-jar-no-deps />
> </target>
>
> <target name="build-no-deps" depends="init,clean">
> <!-- macrodef calls -->
> <build-jar-no-deps />
> </target>
How about:
<target name="build" depends="-build, build-no-deps" />
<target name="-build" depends="init,clean">
<build-jar-deps />
</target>
<target name="build-no-deps" depends="init,clean">
<build-jar-no-deps />
</target>
> As soon as a condition is required in one of the macrodefs, the whole
> thing
> falls apart. If I tear out the macrodefs and replace them with targets so
> that I can get the if/unless attributes, I have no alternative but to use
> antcall again, yuck!
>
> Have the committers have found a pattern which allows them to avoid this
> situation? If not, of the two evils which should I regard as the greater:
> the if task, or the antcall? Is there a solution for this catch-22 on the
> horizon?
<antcall> is evil I think. I use <if> a little, or rather I use its
equivalent built-in to my own tasks. I believe conditions in builds are
natural, and it's a shame Ant still refuses to admit it fully, allowing
conditions in some places but not others, but the greater evil is procedural
builds (as opposed to descriptive / functional ones), and a sure fire sign
of this is <antcall>. --DD
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
For additional commands, e-mail: user-help@ant.apache.org
|