For antlib components the namespace of the tasks and elements are decided by a xmlns:prefix="uri.." attribute. This is quite nice and it is the proper way to have different namespaces for different tasks with the same localname. For example one could have a "deploy" task in an antlib without worrying about another antlib that the same build file may use also contain a "deploy" task.
In the 1.6 beta discussion, it was decided that the nested elements of these tasks should also have the same xml ns as the tasks themselves. The reason for this was consistency.
I believe that this makes build scripts more complicated than they need to be.
Reason 1: look of build file.
For example, a number of build use the <for> task from ant-contrib. When the <for> task is in the same xml namespace as ant tasks, it does not look too bad:
<for item="dir">
<path>
<dirset dir="."/>
</path>
<sequential>
<echo>The dir is ${dir}</echo>
</sequential>
</for>
However with xml ns, this looks like:
<ac:for item="dir">
<ac:path>
<ac:dirset dir="."/>
</ac:path>
<ac:sequential>
<echo>The dir is ${dir}</echo>
</ac:sequential>
</ac:for>Which in my book looks wrong (why is "path" in the ant-contrib namespace) and
from the eye is more difficult to parse (perl-like, xml-angleness + xml noize).
Some people say that one can avoid some that the problems by changing the default namespace:
<for item="dir" xmlns="antlib:net.sf.antcontrib">
<path>
<dirset dir="."/>
</path>
<ac:sequential xmlns="antlib:org.apache.tools.ant">
<echo>The dir is ${dir}</echo>
</ac:sequential>
</for>Using default namespace in this way is not good xml style, and it is in my opinion confusing.
Reason 2: Conversion of build files that use <taskdef resource=""/>
A (large) number of build scripts use ant-contrib and other antlibable thirdparty sets of tasks. It is painful to convert these to using xml namespace versions of the antlibs. This is especially true for nested element heavy tasks like the cpptasks.
Reason 3: Use of <macrodef>
<macrodef> allows nested elements to be passed to the macro definition.
forexample: a macro that passes a fileset to a namespaceed task and to an build-in ant task:
<macrodef name="example">
<element name="files" implicit="yes"/>
<sequential>
<x:task>
<files/>
<x:task>
<copy todir="z">
<files/>
</copy>
</sequential>
</macrodef><example> <fileset dir="." includes="*.xml"/> </example>
Reason 4: Use of <preset> in an antlib definition file.
Currently one needs to do something like this:
<presetdef name="javac.preset">
<javac>
<current:src path="${extra.src.path}"/>
</javac>
</presetdef>which is a bit unintuative.
I propose to allow nested elements discovered by reflection to be in the tasks namespace and in the ant default namespace.
This change is, as far as I can see, backward compatible, and relatively easy to use.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
