ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Wannheden, Knut" <>
Subject RE: xml namespace support in ant2
Date Thu, 05 Sep 2002 13:18:20 GMT
So, if I understand you correctly, you're talking about two different uses
for namespaces: one for property resolution and the other for defining tasks
and types in an external library.

When used for property resolution it doesn't have anything directly to do
with XML namespaces it just uses a similar syntax to disambiguate different
"functions".  But I suppose you could use "real" XML namespaces if you'd
restrict the property string to XPath expressions.  So for example:

 - instead of "dom:some-id:/my/subelement" (is that the intended usage?)
you'd maybe write "ant:resolve('some-id')/my/subelement" (where
ant:resolve() is a function returning the nodeset corresponding to some-id)
 - and instead of "toString:some-id" you'd write "ant:toString('some-id')"
(where ant:toString() is an XPath function returning a string)

(Just as an example the "ant" namespace prefix could be bound to
"" or completely ommited if it were the

Or is this namespace feature in embed doing something completely different
than I thought?

The other usage of namespaces OTOH would then be the same thing I was
talking about, just at the library level instead of at the individual tasks
and types level.  The purpose would be to avoid name clashes and allow tasks
to have any name (with a namespace) in the buildfile.

The other benefit I see is the validation of a buildfile.  You could easily
define a grammar (e.g. RELAX NG) for all tasks and types of the Ant
namespace and verify a buildfile against it.  Most elements would have a
"definite" grammar not allowing any "alien" subelements.  Just elements as
<project>, <target>, and TaskContainer elements would also need to allow
nested elements from other namespaces than the Ant namespace.

Preferrably you could even plug in new grammars for external tasks in other
namespaces.  The grammar could be part of the imported library for instance.


> -----Original Message-----
> From: Nicola Ken Barozzi []
> Sent: Donnerstag, 5. September 2002 13:30
> To: Ant Developers List
> Subject: Re: xml namespace support in ant2
> Wannheden, Knut wrote:
> > I know this topic has been brought up before (e.g. in 
> "Optional tasks"
> > thread of last december [1]), but I still wonder what is 
> the actual plan for
> > the accepted requirement for Ant2.
> > 
> > At one point it was argued that using namespaces would 
> yield to verbose
> > buildfiles.  But this all depends on what the namespaces 
> would be used for.
> > In [1] it was suggested that there should be a defined 
> namespace for Ant
> > (including <project>, <target>, core and optional tasks and 
> datatypes) and
> > external tasks and datatypes would have to be declared in a separate
> > namespace.  With a namespace enabled <taskdef> a buildfile 
> could look
> > something like this:
> > 
> > <project xmlns=""
> >          xmlns:my="urn:my-ant-tasks"
> >          default="test">
> > 
> >  <taskdef qname="my:foo" classname=""/>
> >  <taskdef name="baz" ns="urn:my-ant-tasks" 
> classname=""/>
> > 
> >  <target name="test">
> >   <echo message="test"/>
> >   <my:foo/>
> >   <whatever:baz xmlns:whatever="urn:my-ant-tasks"/>
> >  </target>
> > 
> > </project>
> > 
> > (Note the two different uses of <taskdef>.)
> There is a "namespace" feature working on properties in 
> /proposal/embed, 
> and also a SAX2 ProjectHelper.
> What needs to be still defined is just how to use namespaces; 
> good you 
> brought the point to the attention :-)
> > So for all those people not using custom tasks and 
> datatypes the only
> > difference would be the default namespace declaration (or a 
> prefixed one if
> > preferred).
> > 
> > I was just thinking that if there were a namespace for all 
> core Ant XML
> > elements it shouldn't be very hard to write up a RELAX NG grammar to
> > validate buildfiles, even with custom tasks and datatypes 
> in it.  And the
> > gain of that in turn is probably quite obvious (although 
> the RNG grammar
> > would require maintainance):
> >  - the task implementation would be guarded against wrong 
> usage (validation)
> >  - the user wouldn't be surprised by different behaviour of 
> tasks with just
> > swapped attribute order
> >  - and maybe a consistent documentation could be generated out of an
> > annotated grammar
> > 
> > Are namespaces intended for this kind of purpose in Ant2?
> Can be, I'm personally still musing about the best purpose.
> > [1]

the same afromentioned proposal code has support for overriding the lib 
dir of Ant; an antlib support (ie automatic taskdefs) is planned, making 
use of Commons discovery.

In this case, the namespace would be applied to the tasks, so that 
taskdeffing a jar will yield the tasks with the specified namespace, to 
prevent clashing.

Also, we could define a namespace to be used for every "import", so that 
   targets imported there do not have problems with name clashes. (see 
the embed proposal for this tag)

Is this what you advocate?

Other ideas?

Nicola Ken Barozzi         
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message