ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adam Murdoch <>
Subject Re: [myrmidon] moving to new module
Date Mon, 08 Apr 2002 13:11:06 GMT
On Mon, 8 Apr 2002 22:18, Peter Donald wrote:

> 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 

That'll be an <ant> or <antcall>.  We're not inheriting the listeners yet, so

everything reverts to default when you do an <ant> or <antcall>.

> and also our jars produce zip/tar archvies
> with files in different order. 

Now that's weird.  It's all ant1 code in <ant1.fileset> and <>,  
straight out of the ant1 tree.  Were you building the originals with ant 
1.4.1 by any chance?

> 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?

I don't think references are working properly yet.  Also, we're not inheriting 
typedefs across <ant> and <antcall>.  No doubt there's more issues.

> > 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.

I might do some research, and see what we can steal from 

> > 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.*
> +1
> > - 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.

I didn't mean combine API and framework.  I just meant that there are one or 
two classes in framework which might be better off in API.  No matter - we 
can juggle stuff around later if need be.

> > - Container API, o.a.myrmidon.interfaces.*
> +0.5
> 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?

Ok, that sounds fine.

> > - Container impl, o.a.myrmidon.components.*
> and .frontends.*/launcher.* etc

Yep.  Though, there's nothing in frontends or launcher which uses components 
directly, so it might be good to separate them out?  CLIMain doesn't need to 
be in the container classloader any more.

> > - Antlibs, o.a.antlib.*
> > - Framework, o.a.myrmidon.framework.*
> > - Ant1compat,*
> > - Todo,*
> >
> 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).



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

View raw message