See below ... James Duncan Davidson wrote: > > On 1/5/01 11:32 AM, "Rob Oxspring" <[EMAIL PROTECTED]> wrote: > > > I may be being daft, but I can't see how this could easily build up "or"s - > > assuming that these things are "and"ed together - > > however if the available task also took a "operation" attribute, the task > > could combine the conditions appropriately... Example steeling from Ceki > > Gulcu's "Conditional compilation" request: > > > > <available property="case1" operation="and"> > > <if ...test for JNDI... /> > > <if ...test for JMS... /> > > </available> > > > > <available property="case2" operation="or"> > > <if ...test for JAXP from Sun... /> > > <if ...test for Xerces... /> > > </available> > > I may being daft as well here as both of these examples are a bit > heavyweight. > > However, given the following thoughts: > > *) if/unless attributes check for true/false/1/0 values in a prop
This has been discussed before in relation to if/unless at the target level. If I recall, there were differing opinions this. > *) it should be possible to write a task that sets a prop to > whatever > > It should be possible to provide this logic as a task -- which might be > abstracted a bit more: > > <setproperty property="foo" value="true" combination="any|all|none"> > <classpresent class="javax.xml.parsers.DOMBuilder"/> > </setproperty> How would this functionality releate to that of the existing <property> and <available> tasks? Would it make more sense to just add to the <property> task instead and deprecate the <available> task? The <property> task could support the nested attributes classpresent, filepresent, propertypresent, etc. My proposal was for version 1.3. However, if something completely different would be done for 2.0, then whatever is added for 1.3 should move towards 2.0, not in a different direction. Maybe we need to discuss how this would look for 2.0 and then figure out what subset of that functionality (if any) makes sense for 1.3. -Bill Burton
