> -----Original Message----- > From: Jose Alberto Fernandez [mailto:[EMAIL PROTECTED] > Sent: Friday, 22 March 2002 6:09 PM > To: Ant Developers List > Subject: Re: suggestion for if/unless syntax change > > > From: "Adam Murdoch" <[EMAIL PROTECTED]> > > > > > > > > From: Jose Alberto Fernandez [mailto:[EMAIL PROTECTED] > > > > > > > > > So, is there a way to test if a property is set? Is this > coordinated with > > > other things like <condition>, <available>, etc? > > > > > > All this things need to play toguether, well. > > > > > > Absolutely. There's a bunch of condition implementations, and > you can use > > whichever one you like, or invent your own. The goal is to allow any > > condition to be use whereever the standard if/unless conditions > are. At the > > moment, conditions can only be used in a few places: > <condition>, <waitfor>, > > <fileset>, and (almost) <if>. More on the way ... > > > > BTW, <available> is just a condition now, rather than a task. > And it's been > > split up into <class-available>, <resource-available>, > <file-exists>, etc. > > > > > > Humm. I think we are mixing two different things: (1) "if" > attribute of <target>, <exclude>, etc; > and (2) <if> task. They are kind of different things, in my opinion. > > What I meant by coordinate, was that if the attribute now checks > for "false", then > <available> and such should set things to "false" when the > condition is false. > They work the way they do in ANT1.x because the "if" attribute > works the way it does. >
Ah, I understand now. Yes, <condition> probably should do something when the condition is false. This would be different to the way things work in ant 1, where <available> and <condition> do nothing when the condition is false. For example: ant -Dsome-prop=true <condition property="some-prop"> <some-false-condition/> </condition> => some-prop is 'true' or <condition property="some-prop"> <some-true-condition/> </condition> <condition property="some-prop"> <some-false-condition/> </condition> => some-prop is 'true' Different isn't necessarily bad, though. > > > > > > IMHO, a much more useful thing (instead of changing completely > > > the meaning of 'if') > > > is to actually let it check for a particular value. I guess I > > > wrote such a patch > > > in ANT 1.1 (or was it 1.0). > > > > > > <target .... if='prop=true'/> > > > > > > this is a fully backward compatible and more useful thing to > have, IMO. > > > > > > > Well, arguably more useful. This is why we want to get away > from forcing a > > particular test, and let the build file writer decide which is > more useful > > for them. on the other hand, we do want to come up with a reasonable > > default test, to use as shorthand. > > > > Notice I am talking about the "if" attribute, not the <if> task. > You cannot change > the implementation of it (I do not think). > Sure you can. You just need to come up with some way to describe which condition implementation to use. Something like: <target> <my-homemade-condition someprop="blah"/> <task/> <task/> </target> And make <target if="someprop"> ... </target> shorthand for <target> <is-set property="someprop"/> ... </target> In myrmidon, we have done away with the "if" and "unless" attributes for <target> altogether, now that we have an <if> task. So now the answer to the question 'do we test is-set/is-not-set or is-true/is-not-true?' is: It doesn't matter - let the build file writer tell us what they want. Adam -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
