ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <pe...@apache.org>
Subject Re: [myrmidon] moving to new module
Date Wed, 10 Apr 2002 04:16:16 GMT
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:   <mailto:ant-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:ant-dev-help@jakarta.apache.org>


Mime
View raw message