On Thursday 24 April 2003 11:47, Jose Alberto Fernandez wrote:
> Obviously (b) is much better. So they define their antlib as follows:
>
> <antlib>
> <condition name="cpuusage"
> classname="com.amazing.queries.CpuUsage"
> adaptor="com.amazing.ant.ConditionAdaptor"/>
> <condition name="latency"
> classname="com.amazing.queries.NetLatency"
> adaptor="com.amazing.ant.ConditionAdaptor"/>
> <condition name="diskfull"
> classname="com.amazing.queries.DiskFull"
> adaptor="com.amazing.ant.ConditionAdaptor"/>
> </antlib>
>
This is not the way antlib works at the moment. The adapator class is
associated with the role and not a role instance. One could however
make an amazing.condition :-
<role name="amazing.condition"
class="o.a.t.a.taskdefs.condition.Condition"
proxy="com.amazing.ant.ConditionAdaptor"/>
and then
<amazing.condition name="cpuusage"
classname="com.amazing.queries.CpuUsage"/>
etc..
and then use them (with dynamicElement in ConditionBase)
public void dynamicElement(o.a.t.a.types.Condition c) {}
No need to add code to "if" or pollute the namespace with cpuusage
(i.e. a task of the name cpuusage could be defined using a different class
or the same class with a different adaptor).
As regards the XML language usage, I feel that Costin is correct, we should
not invent a new xml languge, the xml file should be ant tasks and types -
like the contents of a <target/>.
<role/> should be an ant task that can be used in the antlib xml file or in
a normal build.xml. <typedef/> and <taskdef/> should be used to define
tasks and types, and a <define role="x"/> should be used to define role
instances (can replace typedef/taskdef) - so the above example becomes
<define role="amazing.condition" name="cpuusage"
classname="com.amazing.queries.CpuUsage"/>
<define role="task" name="copy" classname="o.,/"/> (same as taskdef)
<define name=",,," classname=",,,"/> (same as typedef)
Peter
