ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <>
Subject Re: TaskAdapter and execute()
Date Wed, 06 Mar 2002 07:48:38 GMT
On Mon, 4 Mar 2002 14:41, Adam Murdoch wrote:
> > -----Original Message-----
> > From: Peter Donald []
> > 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?

mainly information useful for those building frontends and manipulating the 
task representations in some fashion (ie documentation, GUI builders etc).

> 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.

+1 for one per class.

I was thinking that for every type 


there would be a descriptor like


> 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?

That was the initial plan but I am not so sure thats a good idea anymore. 
Theres two types of meta-info. Stuff required by the runtime and stuff 
reqiured by external tools. I would like to keep runtime required meta-info 
in the ant-types descriptor while external tools can use descriptor in XML 
file as described above.

For instance the source class and destination class of converter is meta-info 
required by runtime and thus is defined in the descriptor. I already have 
experimented with stuff but need time to finish it ;)

> 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.

I would prefer not to do this just yet. It would add considerable bulk to the 
runtime with minmal benefit. If it later becomes obvious that it is really 
*needed* then we can add it in then. Adding it in now may be overkill. 

The many things you list are similar to what was possible with BeanInfo 
objects. However it was so rare that anyone broke the Bean idioms and naming 
patterns and still wanted their object to be a bean. I can only think of one 
occasion where I have ever used it (and that was a hack to hide the 
start()/stop() methods of a bean that was a thread - should have been a 
runnable instead).

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

This I think we can just list in documentation and perhaps use from an 
antlint program.

> > 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...

hmmm... probably. I remember one hack was needed because target had 
conditions but if we make that go away we can make the ClassLoader hierarchy 
"clean" again.

> 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.


Just need to update the manifest of any antlibs that use it.



Kitsch never goes out of style

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

View raw message