ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Wannheden, Knut" <knut.wannhe...@paranor.ch>
Subject RE: xml namespace support in ant2
Date Fri, 06 Sep 2002 07:27:16 GMT
> -----Original Message-----
> From: Peter Donald [mailto:peter@apache.org]
> Sent: Freitag, 6. September 2002 01:09
> To: Ant Developers List
> Subject: Re: xml namespace support in ant2
> 
> 
> On Thu, 5 Sep 2002 20:08, 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.
> 
> I don't think there is any plan for it at this stage. There 
> are too many 
> potential uses of namespaces and associated confusion. Do you 
> namespace;
> * property names
> * types (aka tasks, datatypes, condtions, etc)
> * property evaluation (ie "${javascript:performMagic()}"
> * target names (ie if you depend on foo:bar target will that 
> execute bar 
> target in foo project?)
> * aspects (ie add ant:fail-on-error="true" to all tasks)
> 

Most of these options don't have anything explicitly to do with XML
Namespaces [1], just namespaces as a general concept.  I was wondering about
the former.  Because as of now it isn't even allowed to have XML namespace
declarations in the buildfile, as has been requested before (e.g.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11870).  But my point is
that XML namespaces could actually be employed for something useful.

> > <project xmlns="http://jakarta.apache.org/Ant/v2"
> >          xmlns:my="urn:my-ant-tasks"
> >          default="test">
> >
> >  <taskdef qname="my:foo" classname="org.bar.FooTask"/>
> >  <taskdef name="baz" ns="urn:my-ant-tasks" 
> classname="org.bar.BazTask"/>
> >
> >  <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>.)
> 
> type aliasing is no problem but I think that is independent 
> of the main issue.
> 

I wouldn't say this use was mainly about aliasing, but more about
modularization.  If you write a set of custom tasks and types as part of a
library you define them in a separate XML namespace when used.  Aliasing
isn't a real problem in Ant anyway, because you can dynamically assign any
name you want to a custom task or type.  So there's no real need for XML
namespaces to avoid name clashes.

> However I think you will find it hard pressed to validate 
> anything without the 
> runtime context being present. It may be possible but I think 
> that it would 
> need to be seen to be believed ;)
> 

I'm not talking about validation at the semantic level here, it would just
be about lexical validation.  As I understand it, the Ant core performs most
of the semantic but only some lexical validation.  For instance does Ant
prevent you from specifying bogus attributes for a task, but it doesn't know
anything about what attributes and nested elements are allowed in
conjunction.  This validation has to be done by the task implementation, and
it's easy to go wrong here and bloats the code.  But worst of all, it can
result in unexpected behaviour.  Take these two uses of <fileset> for
example:

	<fileset defaultexcludes="true" refid="foo"/>
	<fileset refid="foo" defaultexcludes="true"/>

Assuming that there is a defined <fileset id="foo"/>.  Ant won't complain
about the first definition (assuming the setters are invoked in the same
order the attributes are listed), but the second one will raise a
BuildException.  A formal specification would really help here.

Possibly you could also generate consistent user documentation for the tasks
from an annotated version of this formal specification.

There are also context sensitive XML editors using grammars to implement
some kind of code assist.  I believe many users would find that useful as
well.

XML namespaces certainly wouldn't be a prerequisite for a grammar, but it
would certainly make it easier.

[1] Namespaces in XML http://www.w3.org/TR/REC-xml-names/

Cheers,

--
knut

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