ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <>
Subject Re: [myrmidon] moving to new module
Date Mon, 08 Apr 2002 12:18:33 GMT
On Mon, 8 Apr 2002 20:10, Adam Murdoch wrote:
> > I was going to do it as soon as possible after the excalibur CVS settles
> > down in build structure and chooses a build system (be it XSLT, maven,
> > forrest or whatever).
> I wonder if it's time to start building myrmidon using myrmidon? 


Which reminds me I went to try to get myrmidon to build via gump and kinda 
got stumped. I haven't even got to having a clean gump run using ant1 yet ;( 
So it going to have to wait a bit till I get that all going.

Good news is I manually tried to build a bunch of projects and they all built 
ok except for some occasional wierdness. For one our messages are not same 
vebosity level as ant1.x and also our jars produce zip/tar archvies with 
files in different order. So unfortunately it is going to be harder to 
automate testing. But other than that all was good. Do you know of any other 
faults with ant1.x layer?

> The
> project descriptor + transforming project builder approach would be
> interesting to try.  Definitely the way of the future.  The question is,
> which descriptor to use?

Go with something freeform. Which we apply some sort of stylesheet to (xsl or 
dvsl or whatever) which makes it much easier to evolve in future.

> Regardless, we don't really need to wait for excalibur to get sorted out. 
> For the time being we can go with the uber-script we have now.  We just
> have to schlurp over more directories.

okay. I was just being lazy and not wanting to do any more work than was 
absolutely necessary ;)

> > However if you want it to move faster then we can do
> > it now. Up to you.
> Let's get the structure sorted out, at the very least.  As I understand it,
> the current plan is to split the tree up into something like:
> - AUT, o.a.aut.*


> - Task API, o.a.myrmidon.api.* and probably a few bits and pieces from
> o.a.myrmidon.framework.*.

I would prefer to keep framework in a separate jar if at all possible. I will 
look at remaining dependencies from container side and remove them tomorrow 
sometime if you want.

> - Container API, o.a.myrmidon.interfaces.*

maybe a little premature atm and maybe we could keep it side-by side the 
container for time being and then fork it out when it settles down? Opinion?

> - Container impl, o.a.myrmidon.components.*

and .frontends.*/launcher.* etc

> - Antlibs, o.a.antlib.*
> - Framework, o.a.myrmidon.framework.*
> - Ant1compat,*
> - Todo,*
> These last 4 are all kinda the same.  Probably want to rearrange 'em into 3
> broad groups:
> - general stuff that ends up in the shared classloader (most of what's in
> framework and some of todo).
> - reusable stuff that ends up in non-final antlibs (ant1 compat, bits from
> the others).
> - private stuff that ends up in final antlibs (the rest).

Perhaps lets put it into two sections for the time being. 

* Framework stuff (anything that is shared including tasks for the time being)
* Final Antlibs (basically the antlib.* as it stands now + some tasks from 
the todod tree - ie archive should be simple to get operational I believe).

> The other question is package names.  Do we want to move the task API out
> of o.a.myrmidon? 

Keep it where it is until we put it to a vote so that no one gets narky about 
us using the ant "brand".



PROGRAM: n.  a magic spell cast over a computer allowing it to turn
one's input into error messages.  v.t.  to engage in a pastime similar
to banging one's head against a wall, but with fewer opportunities for 

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message