ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <>
Subject Re: [myrmidon] Type Librarys
Date Wed, 08 May 2002 09:43:59 GMT
On Mon, 6 May 2002 22:53, Darrell DeBoer wrote:
> On Mon, 6 May 2002 20:30, Peter Donald wrote:
> > Hi,
> >
> > I just went and updated some of my older tasks to latest stuff you are
> > doing with Librarys. Anyways before I got too far with that I was
> > wondering where exactly you are going with the library stuff. Have you
> > got a grand unified plan and if so want to xml-ize it and add it to our
> > xdocs :)
> Hi Pete,
> Not exactly what you're asking, but I've been playing around with something
> related, which I think will prove quite powerful.


> The idea is to provide a namespace mechanism for type names, so that
> multiple types with the same name can coexist. The idea runs as follows:


> 1) Types/TypeLibs can be registered under a namespace, which *may* be taken
> from the AntlibDescriptor (say, an AntLib name attribute), but can also be
> specified in other ways (eg <typelib library="ant1compat"
> namespace="ant1"/>)

I would prefer it to be based on the name of the antlib (ie internal name 
specified in manifest). I suppose we could support aliasing but I would like 
the importing to be very obvious that it is aliasing that is occuring. Maybe 
something like

<typelib library="ant1compat" namespace-alias="ant1"/>

> 2) As works currently, Type name resolution occurs by first looking in the
> local context, and then up through the parent contexts.


Same as propertys, and resources and anything else we add?

> 3) When a TypeFactory is requested from the TypeManager, the name used can
> be fully qualified (has a namespace), or not. A fully-qualified name
> requests a named type registered under a particular namespace, whereas an
> unqualified name involves searching all namespaces for the type name. If
> the name cannot be resolved unambiguously within the context, an error
> occurs.

Sounds good. Basically this is the same way as imports are handled in java 

> 4) The core antlibs (ant/lib/*) will be registered under an antlib name, 


> 4a) Perhaps types explicitly type-def'd (not an entire library, a single
> type), would be considered higher precedence again, above <import>ed
> library types.


> 5) I'm also thinking about separating the TypeManager interface into a
> superinterface (TypeRegistry?) with just the lookup methods, together with

+1 (Matches how Converter evolved).

> Question:
> Is it appropriate to use XML namespaces for ant type namespaces? 

It has been -1'ed before due to complexity and extra cruft that it adds. We 
could still use ":" as separator but type resolution should follow the java 
import tules which I believe what you propose does ;) However I would prefer 

> (And if not, are we planning to utilise XML namespaces for anything?).

At one stage I played with idea of basing "aspects" on namespaces but that 
turned out to be too complex an idea and most of its benefits can be got by 
simpler/better mechanisms (ie use ContainerTasks rather than aspects). 
Considering aspects are largely axed atm I am not sure I can see it be using 
at all ... 


Peter Donald

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

View raw message