Some quick answers without writing code;
Steve Loughran wrote:
just thought...who else thinks it would be handy to have a task that probed for a task being defined at that point in the build.
e.g.
<taskavailable property="nice.present" task="nice"/>
To date we can do the thing with the classname, but that requires knowing the full classname, an implementation detail that should not matter,
Assuming this is a good thing,
1. what is the trick for looking up a taskname?
Use def = ComponentHelper#getDefinition(componentname)
note that in ant1.6.0 tasks and datatypes are in the same map - so this would return the anttypedefinion
for "fileset" as well as "echo". Note that this will return sucessfully for optional tasks - like "script".
The available task would also need to check if the class of the anttypedefintion can be found:
i.e. if def.getExposedClass(getProject()) is present.
2. what should the task do? It could set the property to the name of the impl class.
In ant1.6.0 things are a little more compilicated - macrodefs, scriptdefs etc are also tasks - it would
make more sense to set the property to "yes".
3. what about namespaces?
Namespaces URIs + task name are mapped to a component name as URI + ":" + taskname
so ComponentHelper#getDefinition("antlib:net.sf.antcontrib:for") would work for:
<project xmlns:ac="antlib:net.sf.antcontrib">
<taskavailable property="for.present" task="antlib:net.sf.antcontrib:for"/>
</project>
Users may expect the following:
<project xmlns:ac="antlib:net.sf.antcontrib">
<taskavailable property="for.present" task="ac:for"/>
</project>
Peter
-steve
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
