Return-Path: Delivered-To: apmail-jakarta-ant-dev-archive@apache.org Received: (qmail 66433 invoked from network); 10 Apr 2002 04:20:20 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 10 Apr 2002 04:20:20 -0000 Received: (qmail 6734 invoked by uid 97); 10 Apr 2002 04:20:27 -0000 Delivered-To: qmlist-jakarta-archive-ant-dev@jakarta.apache.org Received: (qmail 6611 invoked by uid 97); 10 Apr 2002 04:20:26 -0000 Mailing-List: contact ant-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Ant Developers List" Reply-To: "Ant Developers List" Delivered-To: mailing list ant-dev@jakarta.apache.org Received: (qmail 6502 invoked from network); 10 Apr 2002 04:20:26 -0000 Message-Id: <200204100420.g3A4KMf15894@mail012.syd.optusnet.com.au> Content-Type: text/plain; charset="utf-8" From: Peter Donald To: "Ant Developers List" Subject: Re: [myrmidon] moving to new module Date: Wed, 10 Apr 2002 14:16:16 +1000 X-Mailer: KMail [version 1.3.2] References: <200204081849.52691.adammurdoch@apache.org> <200204090203.g3923QJ32177@mail018.syd.optusnet.com.au> <200204101000.23815.adammurdoch@apache.org> In-Reply-To: <200204101000.23815.adammurdoch@apache.org> X-Wisdom-Cookie: . MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N On Wed, 10 Apr 2002 10:00, Adam Murdoch wrote: > On Tue, 9 Apr 2002 11:59, Peter Donald wrote: > > > * Keep the package names the same. Though, I wonder if we shouldn't > > > rename 'components' -> 'services'? > > > > I like it. > > > > Then we come across the problem - what do we call the service providers. > > We could keep the name "components.*" or could go to something like > > "providers.*" or go to an ant specific terminology (for example the > > providers in phoenix are cllaed blocks and we put them in the blocks.* > > hierarchy). > > Um, the service providers? Which bit are you referring to there? basically the objects that implement the interface. > > > There's a few other things we've overlooked: > > > > > > * myrmidon.Constants. Move to myrmidon.interfaces.Constants? Or maybe > > > we want one each for task API, container API and container impl? Or > > > axe altogether? > > > > Hmmm .. hadn't thought about it. Some tasks may use it I believe to > > generate constants to put in places like manifest files. Perhaps we could > > delte it entirely and place it in variables such as > > > > "myrmidon.version", > > "myrmidon.build.date", > > "myrmidon.build.descrption", > > "myrmidon.build.number", > > etc. > > > > Alternatively we could put it in manifests of jars and then access it via > > something like > > > > Package.getPackage("org.apache.myrmidon.api").getName() > > How about both? The info has to go in the manifest, anyway. We can grab > it out of there and populate the root property store with it (and make it > immutable while we're there). sounds good. > > > * myrmidon.aspects. Move to interfaces.aspects? > > > > > > * myrmidon.listeners. Split across task API and framework? > > > > technically both of them are part of the "API" part so we could keep them > > there. Well that is except for the concrete implementations that could be > > moved to somewhere like antlibs.core.* > > > > the APIs for these things should still be considered relatively fluid > > however because neither have had enough enough of a workout IMHO. > > They definitely need work. How about we axe the stuff in aspects > altogether? Doh! Took me ages to figure out how to code em like that - ohwell. I guess they really haven't provided bang for buck so yer remove them. > For listeners, how about we move the interfaces and AbstractProjectListener > -> o.a.myrmidon.api.listeners, and the remainder to antlibs.core. I don't like moving to api.listeners as I want to keep the api.* tree only tied to tasks - not to the workspace, project, target and other ant artefacts. If we could generalize then event infrastructure then +1 otherwise lets hold off for the time being. > > > Do we want to go with a directory layout a la excalibur, something > > > like: > > > > > > aut > > > /src > > > /java > > > /test > > > taskapi > > > /src > > > /java > > > container > > > /src > > > /java > > > /test > > > /manifest > > > ... > > > > > > With a single top level build.xml for the time being. > > > > works for me. So it will end up being something like > > > > aut > > taskapi > > framework > > container > > antlib > > > > Maybe in future we could also have a containerapi ? > > Yep. There's also an ant1compat in there somewhere. Okay. I can start moving this tonight. I want to keep CVS history for some sections of it (namely aut.* and myrmidon.*) so I will go and do some CVS hackery on the filesystem. Anything else you want to maintain history about ? -- Cheers, Pete ------------------------------ Kitsch never goes out of style ------------------------------ -- To unsubscribe, e-mail: For additional commands, e-mail: