ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Bodewig <>
Subject Re: antlib descriptor
Date Wed, 20 Feb 2002 15:02:14 GMT
On Wed, 20 Feb 2002, Conor MacNeill <>

> Let's agree on the concept of roles firstly then :-)

OK, I agree on it 8-)

> What are the goals of defining and using roles? As far as I can see
> this is to allow extensibility, primarily the ability to define new
> nested elements for a task without changing the task.

In the very first place, I'm with Adam here, roles just reflect that
there will be more pluggable things than just tasks and data types in
later version of the descriptor.  A way to define shortcuts, and to
avoid hard coded names in the parser.

I'm also more on the Myrmidon side of things as I understand from
Adam's description, i.e. in the case of

> <foo>
>    <bar>

first look for addFoo.  If you don't find anything, look for an
add(SomeInterface) method and look up an element bar in the role of

I really would tie the role to the type of the thing to add - and
therefore on the method signature when it comes to configuring - and
not on an interface the parent element had to implement.  I wouldn't
even restrict it to interfaces.

This is not compatible with Ant 1.x, I know, which also means that we
cannot use that generalized mechanism to implement TaskContainer.

But this is not the goal here, the goal is to start with a descriptor
that replaces the property files - and do it in a way that allows us
to keep the general format of the descriptor in the future.  Putting
in roles now wouldn't do much in the context of Ant 1.x, but may make
it easier to extend the descriptor in the future.

> To give an example using real Ant types.
> <foo>
>    <fileset ant:type="zipfileset">

The example could be 

<role name="fileset" class="org.apache.ant.types.FileSet" />
<fileset name="zipfileset" class="org.apache.ant.types.ZipFileSet" />

in the descriptor and 

  <zipfileset ...>

where the task simply only had add(FileSet).

Less typing for the build file writer 8-) and to me it seems to be as
explicit as it needs to be.

We may even be able to implement it that way in 1.x - just not to make
TaskContainer use it that way.

> The build file writer asks explicitly for the type they want, rather
> than the background plumbing figuring it out.

Humm, I'd expect that user'd be told in the documentation of the
library, which contained ZipFileSet, that you can use it everywhere
where the task documentation - any task documentation - says you can
use a fileset.


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

View raw message