You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by Bill Burton <bi...@progress.com> on 2001/01/03 02:30:55 UTC
[PROPOSAL] Enhancement to available task
Hello,
In reading the ant-user and ant-dev lists for a few months now and seeing
some of the issues related to conditional support in Ant, I recently came
up with some ideas related to improving the conditional support in Ant
while trying to be consistent with the goals of the Ant maintainers of
keeping Ant's XML more declarative in nature.
It's common to use the <available> task to set a property based on the
availability of a class which is then used at the target level to execute
or not execute a target based on the if/unless attributes. The problem is
that often more than one class may need to be available before a target
should be executed. Currently, you have to use a convoluted means of
extra targets and property settings to support this. This non intuitive
scheme makes the build.xml more complicated and harder to maintain, etc.
So then, why not add support to the <available> task so it can check for
the availability of one _or more_ classes? The idea is to allow
specifying multiple class names separated by commas in the "classname"
attribute. When more than one class name is specified, they all must be
present for the property to be set. For instance, the following would set
the property javascript.present only if both BSF and Rhino were available:
<available property="javascript.present"
classname="com.ibm.bsf.BSFManager,
org.mozilla.javascript.Scriptable" />
...
<target name="run_script" if="javascript.present">
<script language="javascript">
...
</target>
<target name="no_javascript" depends="run_script"
unless="javascript.present">
<fail message="JavaScript is not available ..."/>
</target>
One issue is the "classname" attribute is singular. With this
enhancement, maybe a plural "classnames" attribute should be considered?
-Bill Burton
Re: [PROPOSAL] Enhancement to available task
Posted by Rob Oxspring <ro...@yahoo.com>.
----- Original Message -----
From: "Peter Donald" <do...@apache.org>
To: <an...@jakarta.apache.org>
Cc: <an...@jakarta.apache.org>
Sent: Saturday, January 06, 2001 3:30 AM
Subject: Re: [PROPOSAL] Enhancement to available task
> At 07:32 5/1/01 -0000, Rob Oxspring 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>
>
> Sorry I am ex-philosophy major so I guess I forgot to explain how it
> happens ;) Namely like
>
> <available property="case1">
> <unless ...test for A... />
> <unless ...test for B... />
> </available>
>
> <available property="case2">
> <unless property="case1" />
> </available>
>
> ie the equivelent of
> ~(~A & ~B) == A v B
> or
> !(!A && !B) == A || B
>
Doh! That was definitely Com101 stuff! All the same though, I would of
thought having the "operation" attribute would still be low cost and easier
to use for those that don't know / can't remember much boolean logic - After
all, performing an "exclusive or" becomes very convoluted:
<available property="AxorB" operation="xor">
<if property="A"/>
<if property="B"/>
</available>
As opposed to the current proposal:
<available property="AandB">
<if property="A">
<if property="B">
</available>
<available property="AnandB">
<unless property="AandB">
</available>
<available property="~Aand~B">
<unless property="A">
<unless property="B">
</available>
<available property="AorB">
<unless property="~Aand~B">
</available>
<available property="AxorB">
<if property="AnandB">
<if property="AorB">
</available>
It is possible that nobody will want to use an xor operation but, if someone
needs to, they have their work cut out. Alternatively you could use nested
boolean operations such as:
<available property="AxorB">
<and>
<not>
<and>
<if property="A"/>
<if property="B"/>
</and>
</not>
<or>
<if property="A"/>
<if property="B"/>
</or>
</and>
</available>
I'm not convinced by this - it's a bit too general purpose for my liking,
however it's probably a bit more usable than forcing the use of only "and"s
and "not"s AND naming all the intermediates.
Just a few thoughts,
Rob
>
> Cheers,
>
> Pete
>
> *-----------------------------------------------------*
> | "Faced with the choice between changing one's mind, |
> | and proving that there is no need to do so - almost |
> | everyone gets busy on the proof." |
> | - John Kenneth Galbraith |
> *-----------------------------------------------------*
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ant-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: ant-dev-help@jakarta.apache.org
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
Re: [PROPOSAL] Enhancement to available task
Posted by Peter Donald <do...@apache.org>.
At 07:32 5/1/01 -0000, Rob Oxspring 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>
Sorry I am ex-philosophy major so I guess I forgot to explain how it
happens ;) Namely like
<available property="case1">
<unless ...test for A... />
<unless ...test for B... />
</available>
<available property="case2">
<unless property="case1" />
</available>
ie the equivelent of
~(~A & ~B) == A v B
or
!(!A && !B) == A || B
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*
Re: [PROPOSAL] Enhancement to available task
Posted by James Duncan Davidson <du...@x180.net>.
On 1/8/01 4:01 PM, "Bill Burton" <bi...@progress.com> wrote:
>> *) 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.
I'm sure that there were differing opinions on this. It doesn't mean that I
won't continue to argue that if there is going to be an if check, it needs
to check the property for a meaningful value, not just the existence of a
value.
>
>> *) 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.
<property> shouldn't be a task... The only thing that <property> should do
in a build file is declare that there is a property of a certain name and
value.
Same with <available> -- see my posts on <execute-task> for a task way of
executing things based on conditionals.
.duncan
--
James Duncan Davidson duncan@x180.net
!try; do()
Re: [PROPOSAL] Enhancement to available task
Posted by Bill Burton <bi...@progress.com>.
See below ...
James Duncan Davidson wrote:
>
> On 1/5/01 11:32 AM, "Rob Oxspring" <ro...@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
Re: [PROPOSAL] Enhancement to available task
Posted by James Duncan Davidson <du...@x180.net>.
On 1/5/01 11:32 AM, "Rob Oxspring" <ro...@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
*) 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>
That way you can set up a Task for setting properties using some large
number of possibilities.
--
James Duncan Davidson duncan@x180.net
!try; do()
Re: [PROPOSAL] Enhancement to available task
Posted by Rob Oxspring <ro...@yahoo.com>.
----- Original Message -----
From: "Peter Donald" <do...@apache.org>
To: <an...@jakarta.apache.org>
Cc: <an...@jakarta.apache.org>
Sent: Friday, January 05, 2001 1:54 AM
Subject: Re: [PROPOSAL] Enhancement to available task
> At 10:51 2/1/01 -0500, Bill Burton wrote:
> > <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>
>
> I had a think about it and I like this best. It reduces/removes the need
> for complex target setups which was previously the way to do it and is
> clear and easy to understand. With multiple availables it is also possible
> to represent all logical relationships in normal logic (ie basically
> and/or/not+derivatives). What does everyone else think ?
>
> Cheers,
>
> Pete
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>
Rob
>
> *-----------------------------------------------------*
> | "Faced with the choice between changing one's mind, |
> | and proving that there is no need to do so - almost |
> | everyone gets busy on the proof." |
> | - John Kenneth Galbraith |
> *-----------------------------------------------------*
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ant-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: ant-dev-help@jakarta.apache.org
>
> .
> ant-dev-help@jakarta.apache.org
>
> .
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
Re: [PROPOSAL] Enhancement to available task
Posted by Peter Donald <do...@apache.org>.
At 10:51 2/1/01 -0500, Bill Burton wrote:
> <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>
I had a think about it and I like this best. It reduces/removes the need
for complex target setups which was previously the way to do it and is
clear and easy to understand. With multiple availables it is also possible
to represent all logical relationships in normal logic (ie basically
and/or/not+derivatives). What does everyone else think ?
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*
Re: [PROPOSAL] Enhancement to available task
Posted by Bill Burton <bi...@progress.com>.
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
Re: [PROPOSAL] Enhancement to available task
Posted by Peter Donald <do...@apache.org>.
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 ?
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 ;/
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*