I keep on wanting something a little more general and elegant. This is going in the right direction. Explicitly model something called a <condition> (or <test>). Let them nest to provide for expressions.
Then allow preconditions for any task. <condition id="some.name"> <test ...> </condition> <empty id="if.no.files" fileset="file.set" /> <target name="compile" > <property name="property.x" value="2" if="some.name" /> <!-- Also allow embedded "if" element specifying the condition --> <javac ifset="property.x" > <!-- A convenience for a common condition --> <delete srcref="file.set" unless="if.no.files" /> </target> And then uptodate becomes a type of condition. Different tasks may have implicit conditions (like javac has default unless="uptodate"). But the infrastruture now lets other reuse some of these "conditions" without having to write new tasks. -----Original Message----- From: Bill Burton [mailto:[EMAIL PROTECTED] Sent: Tuesday, January 02, 2001 10:52 PM To: [EMAIL PROTECTED] Subject: Re: [PROPOSAL] Enhancement to available task See below ... Peter Donald wrote: > > At 08:30 2/1/01 -0500, Bill Burton wrote: > > <available property="javascript.present" > > classname="com.ibm.bsf.BSFManager, > >org.mozilla.javascript.Scriptable" /> > > ... > > good idea !!! I like. How about we go one step further and allow arbitrary > conjunction of tests. You could use nested sub-elements in this case such as > > <available property="javascript.present"> > <test classname="com.ibm.bsf.BSFManager"/> > <test classname="org.mozilla.javascript.Scriptable"/> > <test file="my/generated/javascript/file.js"/> > </available> > > thoughts ? Good idea! I like it! Leave the classname attribute alone and use nested tags for ANDing tests. But wait, there's more! Why not add a way to test for properties as well? <available property="all.defined"> <test property="prop1"/> <test property="prop2"/> <test property="prop3"/> </available> Another variation to this would be allow positive or negative tests: <available property="javascript.present"> <if classname="com.ibm.bsf.BSFManager"/> <if classname="org.mozilla.javascript.Scriptable"/> <if file="my/generated/javascript/file.js"/> <unless property="disable.javascript"/> </available> This would also AND all the tests as all previous examples. However, using if/unless in this context is a bit wierd because it looks like it's a test for equality. Maybe using <test> would be better with an optional found=[true]/false attribute? <available property="javascript.present"> <test classname="com.ibm.bsf.BSFManager"/> <test classname="org.mozilla.javascript.Scriptable"/> <test file="my/generated/javascript/file.js"/> <test found="false" property="disable.javascript"/> </available> Think this is less clear for the last test than using "unless." > We could go even more generic (thou not sure if this is wise) for Ant2.0 so > that the following or something like it works. > > <property name="javascript.present"> > <available> > <test classname="com.ibm.bsf.BSFManager"/> > <test classname="org.mozilla.javascript.Scriptable"/> > <test file="my/generated/javascript/file.js"/> > </available> > </property> > > On second thoughts that kinda looks ugly ;/ Just more verbose. If the <available> task is to be deprecated in Ant 2.0, then this would be the obvious way to handle it. -Bill Burton --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
