ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Darrell DeBoer <>
Subject Re: [myrmidon] Type Librarys
Date Mon, 06 May 2002 12:53:29 GMT
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"/>)

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

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.

4) The core antlibs (ant/lib/*) will be registered under an antlib name, or 
maybe a default namespace. But other versions of these antlibs could be 
imported under a different namespace. A build file could then mix-and-match 
tasks from different versions of libraries, by using FQ names.
Example: The Ant1compat antlib will be in ant/ext, and will be explicitly 
imported by the Ant1Compat project builder. But the task names will not need 
to be munged, because they will simply override the core ones with the same 
name. Then, a build file could mix core and ant1compat tasks, 
- <if>: comes from "core" antlib, since ant1compat has no such task.
- <core.javac>: use the myrmidon version of javac
- <ant1.javadoc>: use the ant1compat version of javadoc
- <javadoc>: resolve to the ant1compat version (same as <ant1.javadoc> because

it's imported in the project, and thus has higher precedence - this is the 
current behaviour with imported typelibs).

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

5) I'm also thinking about separating the TypeManager interface into a 
superinterface (TypeRegistry?) with just the lookup methods, together with 
the full TypeManger, which will include the registration methods. Then, the 
actual TypeManager could allow registration of an entire TypeRegistry (rather 
than registering each type separately) under a particular namespace. One 
implementation of TypeRegistry would provide all types for a type library, 
and would be provided by the TypeLibraryDeployer. Then, the TypeRegistry 
would be reused, rather than all types needing re-registration every time a 
type library is deployed/imported.

Is it appropriate to use XML namespaces for ant type namespaces? If so, we can 
use the <namespace:typename> syntax in our build files. Otherwise, should we 
use '.', and disallow this in regular type names? We can't really use a 
character that's permitted in type names, as there's no was to distinguish 
between "namespace.typename" and "".
(And if not, are we planning to utilise XML namespaces for anything?).


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

View raw message