On Fri, 22 Mar 2002 17:46, Adam Murdoch wrote: > > -----Original Message----- > > From: Peter Donald [mailto:[EMAIL PROTECTED] > > 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. -- Cheers, Pete ----------------------------------------------------------- I don't suffer from insanity. I enjoy every minute of it. ----------------------------------------------------------- -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
