ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Adam Murdoch" <adammurdoch...@yahoo.com>
Subject RE: TaskAdapter and execute()
Date Mon, 04 Mar 2002 03:41:52 GMT


> -----Original Message-----
> From: Peter Donald [mailto:peter@apache.org]
> Sent: Sunday, 3 March 2002 5:59 PM
> To: Ant Developers List
> Subject: Re: TaskAdapter and execute()
> 

> 
> > > I have already started a info descriptor system. Will commit 
> it sometime
> > > soonish when I start testing it out ;)
> >
> > Check it in.  Doesn't have to work; it will soon enough.
> 
> I just went and played with it some more and decided it sucked ;) 
> Will look 
> at it again on tuesday.
> 

What's the plan for meta-info?

I'm thinking a bunch of @ant tags, that get munged into the ant-descriptor.xml.  Or maybe
better option is to generate a separate descriptor, maybe one per class.  One per class makes
it easier to load the meta-info on demand.

Internally, I guess we add a meta-info repository component, that the deployer takes care
of populating.  Meta-info would be indexed by classname, or possibly by {role-name, type-name}.
 Maybe its worth extending TypeManager to act as the meta-info repository?

Once we have a bit of a framework in place, we need to get DefaultObjectConfigurer using the
meta-info.  Or maybe an ObjectConfigurer factory component, with an impl that uses the meta-info.

Some of the things it would be nice to have in the meta-info (these would all be optional,
of course):

* Max/min multiplicities for adder methods.

* 'required' flag for setter and addContent() methods.

* 'ignore' flag for methods.  This would be useful for convenience methods, so that the introspector
does not grizzle about there being multiple adder/setter methods.

* An alias for add() method, to be used when adding values by reference.  Right now, we map
the add method's type to a role, and use the shorthand name of that role.  Kinda clunky, and
not really guaranteed to be consistent.  Let's make it explicit.

* A flag for adder methods to indicate that the method can be used for attributes as well
(like the current configurer behaviour, which I kinda like).

* 'deprecated' and 'experimental' flags for classes and methods (maybe that one can wait for
a release or two :)

* etc


> BTW did you read over the docs I uploaded? 

I did.

> Like/dislike? 

Like.

> I am not sure they 
> are entirely accurate wrt Myrmidon but they mirror my original 
> intentions ;)
> 

Very close.  I think we're accidentally using the container classloader as the parent for
the antlibs.  Been meaning to fix that for a while...

On that topic, I wonder if we should move crimson.jar to the container classloader, and make
it available as an optional package, similar to how tools.jar is treated.


Adam


--
To unsubscribe, e-mail:   <mailto:ant-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:ant-dev-help@jakarta.apache.org>


Mime
View raw message