> -----Original Message-----
> From: Peter Donald [mailto:[EMAIL PROTECTED]
> 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:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
