Well, that's what Ant is, a "convenience". I wouldn't be using it if it wasn't more convenient than shell scripts and make files. I've recently started using <if> and I think it's made my build.xml easier to follow and maintain. The problem with conditional targets is that even if the condition evaluates to false the dependent targets are still exececuted, so you have to add the same if/unless to them as well. But perhaps these dependent targets are also dependencies for other targets that have different if/unless conditions. So I'd need to add these to my dependent targets as well, but wait, I can't have multiple conditions to my targets (or can I?) There's a minor bug with <if> in that if a nested task sets a property, that property won't available to the rest of the nested tasks because their attributes/elements have already been "configured". I believe this is because these "tasks" were not created by Project.createTask() but are rather created by IntrospectionHelper.createElement(). I've tried to fix it but have been unsuccessful so far. And I haven't tried it but <switch> probably suffers from the same problem. I'd like to see <if> fixed and added to the regular Ant build, perhaps as one of the optional tasks. Brian DeWeese Matt Benson wrote:Even though "It makes build files clearer, easier to understand, and remove the need for having so many (private) targets with dependencies between them as a direct consequence of the current only built-in scheme to do conditional execution.", do these benefits not amount to a convenience? Like electric lights... I could wait until morning and go outside to be able to see things, or I could turn on the light if only it is provided to me. The light is much more convenient, but other ways exist to see things! Similarly, does not provide anything from a functional perspective that cannot be accomplished some other way in Ant (I don't think).
-Matt --- Dominique Devienne wrote: > I disagree. It's not only a convenience! It makes > build files clearer, > easier to understand, and remove the need for having > so many (private) > targets with dependencies between them as a direct > consequence of the > current only built-in scheme to do conditional > execution. Conditions in real > project building happen all the time, and the > current mechanism supports it > in a very ugly fashion. Many people use Ant proper > only, and thus not > providing built-in is in effect stopping it's > use. > > Conor's proposal allowing to do: > > > > > if="do-something-set-property"/> > > > would are removed much of the need for and > avoided the current > multiplication effect on target number, but we ain't > gonna have that ever > from the looks of it!!! > > So NO, is not just a convenience! --DD > > -----Original Message----- > From: Matt Benson [mailto:[EMAIL PROTECTED]] > Sent: Thursday, August 22, 2002 9:20 AM > To: Ant Users List > Subject: Re: conditional copy > > I completely agree that the functionality is the > same; > the task only adds a minor convenience. > > -Matt > > --- Erik Hatcher > wrote: > > Its only fair to also add that the task > doesn't > > really add anything > > to what can be done with conditional targets - an > if > > and an unless > > target could be used to handle both if/else types > of > > conditions. > > > > So you aren't really using a "conditional task", > > you're using a task > > container that switches which sets of tasks it > > executes based on some > > property. > > > > 6 of one.... > > > > Erik > > -- > To unsubscribe, e-mail: > > For additional commands, e-mail: > > __________________________________________________ Do You Yahoo!? HotJobs - Search Thousands of New Jobs http://www.hotjobs.com -- To unsubscribe, e-mail: For additional commands, e-mail: --------------------------------- Do You Yahoo!? HotJobs, a Yahoo! service - Search Thousands of New Jobs
