Generalization of available (setif and setunless)

[Stefan Bodewig <bo...@bost.de>]

Hi,

I'm subscribed to this group a very short time. As I don't know if
these things have been discussed before I won't submit code right
know - maybe somebody else has already done something similar (which
would have happened to my own version of a JUnit task).

What I'm thinking about is a more general form of the Available task,
something like

<setif property="NAME" value="VALUE" conditiontester="CLASSNAME"
        condition="CONDITION" />

Where conditiontester would implement something like 

interface ConditionTester {
    public void setCondition(String condition);
    public boolean testCondition() throws BuildException;
}

This would set the property named NAME to VALUE if CONDITION has been
evaluated to true (false in the case of setunless) by an instance of
CLASSNAME.

Furthermore setif/unless should allow for some built-in conditions (for a
proposal how to add new built-ins without changing too much code see my 
other mail):

* fileavailable, resourceavailable and classavailable 

  can quite easily be implemented by minor modifications to Available
  to implement ConditionTester

* isset

  checks whether another property is set

* istrue

  checks whether another property is set and evaluates to true

* equals

  compares to Strings with a Syntax similar to KeySubst. The separator
  char could be the first char. Something like

  <setunless equals="*${jdbc.version}*1.0" property="files.to.ignore" 
        value="*1_0*" />
  <setunless equals="*${jdbc.version}*2.0" property="files.to.ignore" 
        value="*2_0*" />

  would make it easy to conditionally phase out files from
  compilation.

* javaversion

  some way to check the JVM version at (ant-) runtime. Maybe make this 
  three built-ins javaversionequals, javaversiongreater,
  javaversionless.

* isexecutable

  checks whether a given command can be executed. 

  I can't think of a portable way to implement this without actually
  running the command.

I have already implemented such Tasks and most of the proposed
built-ins but the code would need some brush up before I submit it. My
primary goal is to get feedback on this first.

Stefan

Re: Generalization of available (setif and setunless)

[Stefan Bodewig <bo...@bost.de>]

>>>>> "TH" == Thomas Haas <th...@softwired-inc.com> writes:

 TH> Stefan Bodewig wrote:
 >> (which would have happened to my own version of a JUnit task).

 TH> Maybe we could merge our JUnit taks implementation or at least
 TH> coordinate development.

Yes that would be nice. I've only seen mention of your implementation
in quoted texts I didn't get the original mail from you. So I wanted to 
wait 'till it was commited before I jumped in.

But if you could send me your source (by private mail) I'd love to
look into it.

Stefan

Re: Generalization of available (setif and setunless)

[Thomas Haas <th...@softwired-inc.com>]

Stefan Bodewig wrote:

> Hi,
>
> I'm subscribed to this group a very short time. As I don't know if
> these things have been discussed before I won't submit code right
> know - maybe somebody else has already done something similar (which
> would have happened to my own version of a JUnit task).

Maybe we could merge our JUnit taks implementation or at least coordinate
development. I would be happy, if Iget some feedback, ideas or help on this.
I do not plan to work on that task until maybe next wednesday.


- tom

--
* Thomas Haas                    <ma...@softwired-inc.com>
* SoftWired AG                   <http://www.softwired-inc.com/>
* Technoparkstr. 1  ***  CH-8005 Zurich  ***  +41-1-4452370

Re: Generalization of available (setif and setunless)

[Stefan Bodewig <bo...@bost.de>]

Sorry to reply to myself,

I've been playing around some more and finally found that property
expansion in the build file takes place before any Tasks have been
run. You knew that for sure 8^).

The tests I had done before involved running ant with -verbose and see
Project reporting properties being set.

This takes away the usefulness of the "value" attribute and reduces
the things you could do with it - I cannot see anything apart from
using the if-attributes in targets and of MatchingTask.NameEntry.

So what now:

1. drop my proposal altogether?

2. drop the value attribute and keep setif, setunless as a slightly
   more flexible available?

3. defer set... calls on tasks together with the expansion of
   properties to the point the task is actually run?

Kind of embarrassing to introduce myself with a not too well informed
proposal, sorry.

Stefan