ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Burton" <bi...@progress.com>
Subject Re: [PROPOSAL] Enhancement to available task
Date Tue, 09 Jan 2001 00:01:10 GMT
See below ...

James Duncan Davidson wrote:
> 
> On 1/5/01 11:32 AM, "Rob Oxspring" <roxspring@yahoo.com> 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

Mime
View raw message