ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Peter Reilly" <peter.kitt.rei...@gmail.com>
Subject Restricted types: Re: Location in non-Task tasks
Date Tue, 12 Sep 2006 21:03:16 GMT
On 9/11/06, Dominique Devienne <ddevienne@gmail.com> 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
add(FileSelector)
      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 antlib:org.apache.tools.ant 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"]
or
* @ant.task [name="whatever"]

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

And have a task that will generate the definitions - either as an antlib xml
file
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.


Peter



> 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: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>
>

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