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 Wed, 08 May 2002 04:27:19 GMT

I just committed some stuff - before I read this email. So it's lucky you 
didn't put forward any strenuous objections ;).

On Wed, 8 May 2002 13:01, Adam Murdoch wrote:
> On Mon, 6 May 2002 22:53, Darrell DeBoer wrote:

> > 4) The core antlibs (ant/lib/*) will be registered under an antlib name,
> > or maybe a default namespace.
> Antlib name, I reckon.  Keep the default namespace empty for the project to
> play with.

Currently, the DefaultEmbeddor puts them into a hard-coded "ant" namespace. 
But once Library.getName() gives us something useful, we can use that.

The container stuff is added under the "myrmidon" namespace. I'm not sure if 
this is necessary, or makes any difference.

> > 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.
> +1.  Have it search from most specific -> least specific.

Since the TypeManager doesn't yet have methods for adding a set of types as a 
whole, this is not yet done. (One step at a time). We'll need to add support 
to the NamespaceAwareTypeFactory for this, but it shouldn't be too hard.
(You'll see one commented-out method where I was playing with this idea, but 
it needs a bit more work).

> > 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.
> Have a look at how Converter/ConverterRegistry and RoleManager/RoleRegistry
> have been split up.  TypeManager should be consistent with them.

Will do.

> > Question:
> > Is it appropriate to use XML namespaces for ant type namespaces?
> Not if you don't declare it as an XML namespace.  Which is just extra crap
> that would have to be added to project files (and which is going to cause
> weirdness when projects move between validating and non-validating
> parsers).
> Let's go with the '.' separator. We'll need to do something about
> converters, since its class name is used as its type name.

That's what I did, and for converters I'm hacking the classname to remove the 
'.' characters within the ConverterTypeDeployer. (or ConverterDefinition? - I 
can't remember exactly).

> > (And if not, are we planning to utilise XML namespaces for anything?).
> Maybe.  A good candidate would be the aspecty stuff that has been talked
> about.  But that would involve using a single ant: namespace, rather than a
> bunch of different namespaces.

Fair enough.

Have a play with it and let me know what you reckon. 

One thing I'm thinking about is the ability to add a library under a 
namespace, but not have it intrude on the default namespace. So that you 
could import the Ant1Compat antlib under the "ant1" namespace, but <javac> 
etc would still refer to the core tasks. The only way to access the imported 
types would be with a qualified name (<ant1.javac>).


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

View raw message