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="xyz.java" 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 [mailto:[EMAIL PROTECTED] > Sent: 26 November 2002 08:28 > To: [EMAIL PROTECTED] > Subject: Re: [PATCH] adds 'if'/'unless' to <antcall> (CallTarget.java) > > > On Mon, 25 Nov 2002, Thierry Lach <[EMAIL PROTECTED]> > wrote: > > > Is there any problem with adding the 'if' and 'unless' handling to > > org.apache.tools.ant.Task 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: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
