On Sun, 3 Feb 2002 08:59, Adam Murdoch wrote: > > -----Original Message----- > > From: Peter Donald [mailto:[EMAIL PROTECTED] > > Sent: Sunday, 3 February 2002 12:17 AM > > To: Ant Developers List > > Subject: Re: cvs commit: > > jakarta-ant/proposal/myrmidon/src/testcases/org/apache/myrmidon/componen > > ts/deployer DefaultDeployerTest.java TestConverter1.java TestType1.java > > > > On Sat, 2 Feb 2002 23:51, [EMAIL PROTECTED] wrote: > > > /** > > > * A general-purpose type definition. > > > * > > > * @author <a href="mailto:[EMAIL PROTECTED]">Adam Murdoch</a> > > > */ > > > public class GeneralTypeDefinition > > > extends TypeDefinition > > > { > > > private String m_name; > > > > vs > > > > > public abstract class TypeDefinition > > > { > > > > Is there any need to separate out the above two classes? From the > > looks of > > things - no - but is there something else you have in mind? > > Not particularly - I added GeneralTypeDefinition so that I could move > setType() and setName() out of TypeDefinition, where they were being > inherited by ConverterDefinition (and so visible as attributes in > <converter-def>). Maybe we could rename TypeDefinition -> > AbstractTypeDefinition and GeneralTypeDefinition -> TypeDefinition.
Oh right - now it is clearer. However what I have gone and done is made the TypeDefinition immutable. I would personally like to see that all types passed to a service (which includes passing stuff to deployer from tasks etc) is either made up of primitive types or immutable. The reason for this is that a lot of problems in ant1.x is that there was no distinction between responsibilities of task and responsibilities of the "service" and as such methods kept getting added on and causing issues. Also names/ideas/concepts and things kept getting out of sync between the service part and the task part. So instead of directly exposing the insides of service you instead expose an adaptor. And then the tasks can change the adaptor to their hearts content for every user request without effecting the core service. So in a way it is making it possible to decouple the service from the task so that they can evolve independently as needed. Thoughts? Do you like this or is it too many layers? ;) > * Add a ServiceDefinition sub-class, and deploy services from the typelib > descriptor. Maybe add a <service-def> task as well. Need to think a > little more about what "deploy services" means. Any problems with putting > the service definitions in ant-descriptor.xml, rather than > ant-services.xml? I would prefer to keep them separate for now. Deploying services is a fairly different concept to registering types. When you deploy a service you have things like lifecycle management, configuration and so forth to worry about. And services are controlled by the container which is different from types which can be controlled by anyone. > * I'd like to axe the <converters> element in ant-descriptor.xml, and move > the converters to the <types> element. How do you plan to integrate them exactly ? > > > /** > > > * A base class for tests for the default components. > > > * > > > * @author <a href="mailto:[EMAIL PROTECTED]">Adam Murdoch</a> > > > */ > > > public class ComponentTestBase extends TestCase > > > > Do you want to rename this to AbstractComponentTest because that > > fits in with > > the naming patterns of swing (which is consistent with the rest of the > > myrmidon codebase). > > Sure, I guess. Does it matter that it isn't abstract? eek - prolly ;) Okay I went and renamed it and made it an Abstract test. I also excluded AbstractTests from the build. -- Cheers, Pete --------------------------------------- Be nice to your friends. If it weren't for them, you'd be a complete stranger. --------------------------------------- -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
