ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Peter Reilly" <>
Subject Restricted types: Re: Location in non-Task tasks
Date Tue, 12 Sep 2006 21:03:16 GMT
On 9/11/06, Dominique Devienne <> wrote:
> > > > 2) Introduce a <tagdef> or <roledef> for the purpose
> > > > of locating extension points as nested elements.
> > but I looked at the code and realized that the type
> > handling in ant would become too complicated - there
> I see your point. Increased complexity is not good. But is it really
> that complex? This new mechanism would only kick in when IH would
> overwise have rejected a nested element, and only add lookup into a
> new mapping when the current type has an add(Type) extension point.
> True, their can be tricky cases when a type has both an add(Condition)
> and a add(FileSelector), but that should be pretty rare, and could be
> thrown out as ambiguous. It could even be resolved using the
> undocumented ant:type attribute.

Ok, I dug out my old code and after digging out some of the bugs
and misunderstanding, I have modded IH, CH (componenthelper),
and <typedef> to allow "restricted" types.

These are like normal types except:
  1) they are only allowed in add[Configured](Class) contexts, they
      cannot be used at the top level or task containers.
  2) One can have a multiple number of definitions with
      the same name. IH will pick the one that matches the
      add() methods in the container class. If there are multiple
      matches, - for example class that has add(Condition) and
      presented with "and", IH will throw a buildexception for ambigeous.

I am not too sure this should be user visible but it can be implemented
by an extra attribute to the typedef task - restrict=yes/no default is no.

One problem is that the antlib.xml for would
be long and tedious when all the conditions, selectors, mappers, resources
are added.
Being long means that startup time for ant would suffer a little (the file
needs to
be parsed) and being tedious means that it would be difficult to maintain.

To solve the startup problem, I propose that we use an AntLibDefinitions
class associated
with a name-space which would contain the definitions.

To solve problem two, I propose that we use annotation like syntax:

* @ant.type [restrict="yes"/"no"] [name="whatever"]
* @ant.task [name="whatever"]

Where the defaults are restrict=no, name={classname in lower case without

And have a task that will generate the definitions - either as an antlib xml
or as a AntLibDefinitions java.

I will create a bugzilla issue where I will place the diffs and task.
This will not of course be for ant 1.7!,
however we can add the @ant.type tags now for documentation?,
@ant.task is already in place for the ant doc project.
@ant.datatype is used as well - but ant types do not need to be
datatypes and not all datatypes are ant types.


> It would however be nice to get something that
> > allows add(Condition) or add(FileSelector) to work
> > without having to extend BaseCondition or whatever
> > is done for FileSelector .
> Precisely. Unless I'm mistaken, this can already be achieved now by
> using namespaces, and the condition antlib. So AssertTask could be
> made ConditionBase independent now, no?
> --DD
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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