ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <>
Subject Re: [myrmidon] api.metadata.Model*
Date Fri, 22 Mar 2002 07:06:49 GMT
On Fri, 22 Mar 2002 17:46, Adam Murdoch wrote:
> > -----Original Message-----
> > From: Peter Donald []
> > Sent: Friday, 22 March 2002 3:09 PM
> > To: Ant Developers List
> > Subject: [myrmidon] api.metadata.Model*
> >
> >
> > Hi,
> >
> > I was thinking about replacing Configuration/Configurable with
> > ModelElement/Modeller and have just prototyped a little of it and
> > reading it
> > from xml files etc.
> >
> > My Main aim is to push avalon-framework out of the common classloader and
> > into the container classloader. Add the above change and if I rework some
> > Enums and I think that should be possible.
> >
> > Thoughts?
> Yep, good idea.  Some random comments:
> * Can we add some kind of location information to ModelElement?  It's so
> handy for error reporting.

will do.

> * I wonder if getAttribute() shouldn't return an Object, rather than a
> String?  The reason is this allows a model to be built programmatically,
> that contains pre-configured Objects for some of the attributes.  Also, it
> would allow a configuration pipeline, where things like property
> resolution, reference handling, conversion, and so forth would be handled
> as pluggable stages in the pipeline (just a vague idea).

Interesting idea - hadn't thought about it. 

> * What are we going to use for logging in aut?  Certainly can't use
> TaskContext, and if Logger is moved to the container classloader, we won't
> be able to use that either.

bugger. I didn't think that far ahead ;)

> * A few of the framework interfaces are used in myrmidon.interfaces.
> (Logger, Parameters, ServiceManager, Parameterizable, etc).  Nothing major,
> I don't think.

okay - I guess framework will have to stay in common classloader - ohwell. I 
knew it couldn't be this easy.

Not sure - is it still worth going to Model* rather than Config* ? The only 
advantage I see is that it is a smaller interface. The disadvantage I see is 
code duplication and you lose all the getAttributeAs* getContentAs* helper 
methods - but then again they will only be used by handwritten 
self-configuring tasks.

I will look at it all again see if I can think of anything else interesting 
to do wrt all these dependencies. 

> * framework.factories needs to use framework classes, so we should probably
> move them to the container classloader too.  Maybe we should unify the
> services and components.  Certainly things like the Configurer, Executor
> and PropertyResolver could be loaded from an ant-services.xml descriptor.

okay. Though as a service is workspace wide, that would mean there could only 
have one instance of each service. I guess that is fine. 



 I don't suffer from insanity. I enjoy every minute of it.

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

View raw message