ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marvin Greenberg <MGreenb...@Eidea.com>
Subject RE: [PROPOSAL] Enhancement to available task
Date Wed, 03 Jan 2001 14:52:48 GMT
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:billb@progress.com]
Sent: Tuesday, January 02, 2001 10:52 PM
To: ant-dev@jakarta.apache.org
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: ant-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: ant-dev-help@jakarta.apache.org

Mime
View raw message