ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Reilly <>
Subject 1.6.2: Namespace uri of nested elements
Date Wed, 09 Jun 2004 07:43:40 GMT
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">
      <dirset dir="."/>
      <echo>The dir is ${dir}</echo>

However with xml ns, this looks like:

<ac:for item="dir">
      <ac:dirset dir="."/>
      <echo>The dir is ${dir}</echo>

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 

Some people say that one can avoid some that the problems by changing the
default namespace:

<for item="dir" xmlns="antlib:net.sf.antcontrib">
      <dirset dir="."/>
   <ac:sequential xmlns="">
      <echo>The dir is ${dir}</echo>

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"/>
      <copy todir="z">

   <fileset dir="." includes="*.xml"/>

Reason 4: Use of <preset> in an antlib definition file.

Currently one needs to do something like this:
<presetdef name="javac.preset">
     <current:src path="${extra.src.path}"/>

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:
For additional commands, e-mail:

View raw message