I'm not gonna give up on this until everybody tells me to shut up. :-) Am I the only one that uses <fail>? Or is everybody just happy with the status quo of having to create a separate target for each possible use of <fail>?
Tim > -----Original Message----- > From: Tim Dawson [mailto:[EMAIL PROTECTED] > Sent: Friday, October 05, 2001 11:09 AM > To: '[EMAIL PROTECTED]' > Subject: RE: if/unless on fail?? > > > Picking up this thread which got dropped after the atrocity... > > > hmm true. I guess I can't see where fail tasks would not > > require if/unless. Is there any (supported) use case where > > this is so? I just went to use it for the first time today > > and found it somewhat cumbersome. Not cumbersome because > > of lacking features in ant but because the task is not useful > > as a standalone task but has to be munged into an ugly target > > construct. > > Now you see my pain! :-) I wholeheartedly agree. I'm > generally not in > favor of proposals that turn Ant into a scripting language, > but I have to > agree that <fail> as it is today, is VERY cumbersome. I sent > out a number of > notes requesting if/unless this several months ago, and got > shouted down as > being pro-scripting. > > Well, I had also asked for if/unless for the "echo" task, so > I suppose I was > at least partially guilty. :-) > > I'm glad that others have also discovered that <fail>, on its > own, is very > ugly and cumbersome becuase and every single time its used > (at least every > single time I've ever used it) you have to wrap it in an ugly > extra-target > construct. This isn't simply a matter of a shortcut or a > convenience, it is > a MAJOR usability issue - the extra targets make build file > maintainence > much harder. > > I'm not a committer, but I'd really like to see this brought > up again for a > vote. Hard and fast rules are very rarely a substitute for > good judgement, > and I would think that this is a case that screams out for an > exception. > > Thanks, > > Tim > > PS: I was glad to see that in 1.4, the <fail> task had been > extended to > allow a body in addition to the message attribute. That was > one of the > things I had asked for along with the if/unless > > > > > > -----Original Message----- > > From: Peter Donald [mailto:[EMAIL PROTECTED] > > Sent: Tuesday, September 11, 2001 10:03 AM > > To: [EMAIL PROTECTED] > > Subject: Re: if/unless on fail?? > > > > > > On Tue, 11 Sep 2001 22:36, Glenn McAllister wrote: > > > > On Tue, 11 Sep 2001, Peter Donald <[EMAIL PROTECTED]> wrote: > > > > > Couldn't spot the reason - can anyone enlighten me? > > > > > > > > "All tasks or no task" and "all tasks" has been rejected IIRC. > > > > ahh - yes - that sounds right ;) > > > > > That was pretty much my position. I agreed with the person who > > > was pushing for if/unless on fail that it would make life a lot > > > easier in the case of wanting to kill the build early if a > > > particular resource was missing. My concern, however, was > > > opening up that slippery slope, so my -1. > > > > hmm true. I guess I can't see where fail tasks would not > > require if/unless. > > Is there any (supported) use case where this is so? I just > > went to use it for > > the first time today and found it somewhat cumbersome. Not > > cumbersome because > > of lacking features in ant but because the task is not useful > > as a standalone > > task but has to be munged into an ugly target construct. > > > > > That being said, I'm willing to conceed that if we get a > > > concensus vote on changing fail to have if/unless, I'll go along > > > with it. Its an unusual enough situation that an exception can > > > be justified, and seeing as we "thought police" are vigorously on > > > the prowl, it shouldn't go any further. :-) > > > > ;) > > > > -- > > Cheers, > > > > Pete > > > > ------------------------------------------ > > I just hate 'yes' men, don't you Smithers? > > ------------------------------------------ > > >
