> -----Original Message----- > From: Peter Donald [mailto:[EMAIL PROTECTED] > Sent: Wednesday, 6 February 2002 10:10 PM > To: [EMAIL PROTECTED] > Subject: Re: FW: cvs commit: > jakarta-ant/proposal/myrmidon/src/testcases/org/apache/myrmidon/componen > ts/deployer DefaultDeployerTest.java TestConverter1.java TestType1.java > > > I diagree ;) Think of > > Roles == interface > Type == implementation of an interface > Service == instance of a type >
Ah. I was using Service == A Role. With Service == instance, it all makes sense. > Service has per-instance configuration data which none of the other > categories of object do. As the number of services deployed in any ant > instance is going to be extremely low (unlikely that anyone who is not > modifying the container will even need to create new services) - > thus I would > prefer to keep this separate - at least for now. If we find it is not the > case in the future we can always change it. > Ok, sounds good. Happy with the deployer being responsible for deploying services (though most likely just delegating to something else)? > > > I'd like to clean this up a little by either: > > > > * Moving all 'type' definitions in the <types> element, so that > converters > > would go there, as would any new 'types' that we add later > (e.g. services). > > If we did this we might rename the element <content> or <manifest> or > > whatever. > > > > * Replacing the <types> element with a top-level element for > each role, so > > we would have <data-type>, <task>, <service>, etc elements, with the > > definitions inside. Something like: > > > > <antlib> > > > > <task> > > <property classname="..."/> > > <fail classname="..."/> > > </task> > > > > <type> > > <fileset classname="..."/> > > </type> > > > > <projectbuilder> > > <ant classname="..."/> > > </projectbuilder> > > > > </antlib> > > Both good ideas - I think I would prefer the first over the > second but we can > try both and see which works out better ? It is all automagically > generated > by XDoclet now anyways so change should n't be too hard if we have to ;) > First one it is then. Adam -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
