ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jose Alberto Fernandez" <>
Subject RE: [PATCH] adds 'if'/'unless' to <antcall> (
Date Tue, 26 Nov 2002 10:58:40 GMT
If people really need to do contitional things they should just use
the <if/> task that comes as part of ant-contrib.

The if/unless on any task should be deprecated. The only places it makes sense
is in 1) targets (although you could put an <if/> inside the target itself) and
2) conditional subelements of tasks/datatypes like <exclude name="" unless="abc"/>.
For the later there is really no other way to do it.

An interesting issue to think about is whether it makes sense to generalize
if/unless to control whether an XML subtree is sent to a task or not.

Jose Alberto

> -----Original Message-----
> From: Stefan Bodewig []
> Sent: 26 November 2002 08:28
> To:
> Subject: Re: [PATCH] adds 'if'/'unless' to <antcall> (
> On Mon, 25 Nov 2002, Thierry Lach <>
> wrote:
> > Is there any problem with adding the 'if' and 'unless' handling to
> > thereby giving the capability to every
> > single task rather than continuing to add it to each task
> > individually?
> A little bit of Ant history:
> People have been proposing to add if/unless to some tasks every now
> and then.  My take has been "either all tasks or no tasks" - so most
> of the time I have been against adding these attributes (and am
> against adding them to <antcall> for just that reason).  Some Ant
> committers have been against "all tasks" and so we kept the "no tasks"
> policy.
> I changed my mind for <fail> as this task looked so much more useful
> with these attributes - people convinced me, this is possible 8-)
> In the case of <antcall> I pretty much doubt it would be too useful as
> you could always add the if/unless attributes to the target you intend
> to call.  Granted, you'd save the memory hit of reparsing the build
> file when you could know that it won't do anything, but that's pretty
> much all, no?
> The main reason against "all tasks" is that people would immediately
> start to overuse it and create incredibly complex build files that
> most of the time could have been written cleaner without those
> attributes.
> Most newby Ant users need to grasp some of Ant's concepts before they
> can write good build files.  They start using Ant with a mind full of
> make concepts or scripting languages, which inevitably will lead to
> scripty solutions in Ant.  They will never ever start to learn the
> "better" approach Ant offers in many situations because they'll stick
> to the if/unless way they've discovered first.
> Can you imagine a build file like this:
> <target name="compile-it">
>   <uptodate property="compile-not-necessary"
>             srcfile="${srcdir}/${filebase}.java"
>             targetfile="${destdir}/${filebase}.class"/>
>   <javac srcdir="${srcdir}"
>          destdir="${destdir}"
>          includes="${filebase}.java"
>          unless="compile-not-necessary"/>
> </target>
> <target name="ALL">
>   <antcall target="compile-it">
>     <param name="srcdir" value="src"/>
>     <param name="destdir" value="classes"/>
>     <param name="filebase" value="foo/bar/A"/>
>   </antcall>
>   <antcall target="compile-it">
>     <param name="srcdir" value="src"/>
>     <param name="destdir" value="classes"/>
>     <param name="filebase" value="foo/bar/B"/>
>   </antcall>
>   <antcall target="compile-it">
>     <param name="srcdir" value="src"/>
>     <param name="destdir" value="classes"/>
>     <param name="filebase" value="foo/bar/C"/>
>   </antcall>
> </target>
> Judging from some posts to ant-user, I'm sure this would happen if we
> added if/unless to <javac>.
> Stefan
> --
> To unsubscribe, e-mail:   
For additional commands, e-mail: <>

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

View raw message