You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@ant.apache.org by "Shackelford, John-Mason" <jo...@pearson.com> on 2004/06/02 19:25:44 UTC
patterns conditionals/macrodef
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>
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?
John-Mason Shackelford
Software Developer
Pearson Educational Measurement - eMeasurement Group
2510 North Dodge St.
Iowa City, IA 52245
ph. 319-354-9200x6214
john-mason.shackelford@pearson.com
http://etest.ncspearson.com
****************************************************************************
This email may contain confidential material.
If you were not an intended recipient,
Please notify the sender and delete all copies.
We may monitor email to and from our network.
****************************************************************************
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
For additional commands, e-mail: user-help@ant.apache.org
Re: patterns conditionals/macrodef
Posted by "Alexey N. Solofnenko" <A....@mdl.com>.
<if> is good and it is wrong that it is not in a standard ANT. We are
using it without any problems. I also submitted a patch for "-only"
option ( http://issues.apache.org/bugzilla/show_bug.cgi?id=22901 ) to
execute any target without dependencies that can be useful too. Please
vote for that if you like.
- Alexey.
Shackelford, John-Mason wrote:
>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>
>
>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?
>
>
>John-Mason Shackelford
>
>Software Developer
>Pearson Educational Measurement - eMeasurement Group
>
>2510 North Dodge St.
>Iowa City, IA 52245
>ph. 319-354-9200x6214
>john-mason.shackelford@pearson.com
>http://etest.ncspearson.com
>
>****************************************************************************
>This email may contain confidential material.
>If you were not an intended recipient,
>Please notify the sender and delete all copies.
>We may monitor email to and from our network.
>****************************************************************************
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
>For additional commands, e-mail: user-help@ant.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
For additional commands, e-mail: user-help@ant.apache.org
Re: patterns conditionals/macrodef
Posted by Stefan Bodewig <bo...@apache.org>.
On Wed, 2 Jun 2004, John-Mason Shackelford
<jo...@pearson.com> wrote:
> As soon as a condition is required in one of the macrodefs, the
> whole thing falls apart.
I don't think I've understood your build problem, but I can confirm
the general statement that there are certain kinds of
macro-candidates that are impossible to write without an <if> task.
> If not, of the two evils which should I regard as the greater: the
> if task, or the antcall?
Ask yourself why you consider each of the two to be evil. <antcall>
is a resource hog and most of the time does things as a side effect
that you really don't want to do (re-run dependencies) - I'd avoid
it. <if>, well, <if> is not a core Ant task. <if> is not blessed
by the Ant committers. <if> used in the wrong way will lead to bad
build files, but you seem to know when to use and when to avoid it.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
For additional commands, e-mail: user-help@ant.apache.org
Re: patterns conditionals/macrodef
Posted by Stefan Bodewig <bo...@apache.org>.
On Thu, 03 Jun 2004, Jack J. Woehr <ja...@purematrix.com> wrote:
> Stefan Bodewig wrote:
>
>> On Wed, 02 Jun 2004, Jack J. Woehr <ja...@purematrix.com> wrote:
>>
>> > Not to say I want Ant necessarily to adopt If task.
>>
>> I pretty much fail to understand why people insist that the
>> ant-contrib tasks should be part of the Ant distribution.
>
> Well, I'm not saying that!
No you didn't, sorry. It's just a re-occuring theme.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
For additional commands, e-mail: user-help@ant.apache.org
Re: patterns conditionals/macrodef
Posted by "Jack J. Woehr" <ja...@purematrix.com>.
Stefan Bodewig wrote:
> On Wed, 02 Jun 2004, Jack J. Woehr <ja...@purematrix.com> wrote:
>
> > Not to say I want Ant necessarily to adopt If task.
>
> I pretty much fail to understand why people insist that the
> ant-contrib tasks should be part of the Ant distribution.
Well, I'm not saying that!
> What is the
> problem with using a third-party task library?
ONE MORE OPEN SOURCE PROJECT TO KEEP UP WITH
ONE MORE JAR TO BUILD AND INSTALL
ONE MORE DETAIL TO KEEP TRACK OF
--
Jack J. Woehr # We have gone from the horse and buggy
Senior Consultant # to the moon rocket in one lifetime, but
Purematrix, Inc. # there has not been a corresponding moral
www.purematrix.com # growth in mankind. - Dwight D. Eisenhower
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
For additional commands, e-mail: user-help@ant.apache.org
Re: patterns conditionals/macrodef
Posted by Stefan Bodewig <bo...@apache.org>.
On Wed, 02 Jun 2004, Jack J. Woehr <ja...@purematrix.com> wrote:
> Not to say I want Ant necessarily to adopt If task.
I pretty much fail to understand why people insist that the
ant-contrib tasks should be part of the Ant distribution. What is the
problem with using a third-party task library? Ant-Contrib ships
under the same license as Ant. And some of its tasks are maintained
by the same people you seem to trust for Ant.
> The last thing I want to see is dueling incompatible If tasks
> between Ant and AntContrib.
That wouldn't happen, I'm sure. If we (the Ant committers) really
wanted to add some of the Ant-Contrib tasks to Ant itself, I'm sure
the Ant-Contrib project leads wouldn't stand in our way.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
For additional commands, e-mail: user-help@ant.apache.org
Re: patterns conditionals/macrodef
Posted by "Jack J. Woehr" <ja...@purematrix.com>.
"Shackelford, John-Mason" wrote:
> 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?
As I pointed out on this list two and a half years ago, the Prolog world found
it impossible to continue without some procedural syntax. Lacking a native If
task, and dreading supplementary .jar files, I tried as long as possible to avoid
AntContrib If task. Eventually I had to face it: Some very reasonable execution
paths are simply unreadable and nearly unmaintainable without If - Then - Else.
Not to say I want Ant necessarily to adopt If task. The last thing I want to
see is dueling incompatible If tasks between Ant and AntContrib.
--
Jack J. Woehr # We have gone from the horse and buggy
Senior Consultant # to the moon rocket in one lifetime, but
Purematrix, Inc. # there has not been a corresponding moral
www.purematrix.com # growth in mankind. - Dwight D. Eisenhower
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
For additional commands, e-mail: user-help@ant.apache.org
RE: patterns conditionals/macrodef
Posted by Pawanraj Sadhwani <pa...@elitecore.com>.
Hi,
I remember suggesting an if="property.set" in the macrodef just like we have
in the target.. it would help people not wanting to rely on antcontrib.
if u are using antcontrib.. and want to avoid if, you might want to take a
look at the <runtarget> target that calls a target without creating a new
project.
Pawan
-----Original Message-----
From: Shackelford, John-Mason
[mailto:john-mason.shackelford@pearson.com]
Sent: Wednesday, June 02, 2004 10:56 PM
To: 'user@ant.apache.org '
Subject: patterns conditionals/macrodef
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>
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?
John-Mason Shackelford
Software Developer
Pearson Educational Measurement - eMeasurement Group
2510 North Dodge St.
Iowa City, IA 52245
ph. 319-354-9200x6214
john-mason.shackelford@pearson.com
http://etest.ncspearson.com
****************************************************************************
This email may contain confidential material.
If you were not an intended recipient,
Please notify the sender and delete all copies.
We may monitor email to and from our network.
****************************************************************************
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
For additional commands, e-mail: user-help@ant.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
For additional commands, e-mail: user-help@ant.apache.org