ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tim Dawson" <>
Subject RE: Time for an official Ant 2 tree? (was Ant 1.9 & Task Packaging)
Date Tue, 22 Jan 2002 06:55:35 GMT
> -----Original Message-----
> From: Adam Murdoch []
> Sent: Monday, January 21, 2002 7:26 PM
> To: Ant Developers List
> Subject: Time for an official Ant 2 tree? (was Ant 1.9 & Task
> Packaging)

> > -----Original Message-----
> > From: Tim Dawson []
> > Sent: Tuesday, 22 January 2002 7:38 AM
> > To:
> > Subject: Ant 1.9 & Task Packaging
> >
> >
> > I think we should consider Ant2 to be a brand new project,
> similar to what
> > Xerces, Xalan, and Cocoon have done. Trying to migrate the Ant1.x
> > code base,
> > IMHO, has really held Ant2 back. We've been talking about it for
> > over a year
> > now, it seems.
> >
> The thing that is *really* holding back Ant 2 is that there
> is no 'official'
> Ant 2 source tree.  It seems that there are plenty of people
> waiting around
> for Ant 2 to 'start'.  Creating an Ant 2 source tree - even if it is a
> straight-up copy of the Ant 1.x tree - will give people an obvious and
> focused place to start helping out.

I can agree with that... that's kind of what I was trying to get at but
you've certainly said it better. However I still submit that starting
"fresh" might not be a bad idea...

> Seems like we have at least 4 options:
> 1. Copy the Ant 1.5 tree and start refactoring.
> 2. Start from scratch.
> 3. Adopt Myrmidon as the official Ant 2 proposal.
> 4. Adopt Mutant as the official Ant 2 proposal.
> Option 1 isn't a bad one.  It's a familar code base for everyone.
> Option 2 is a non-starter - it is almost always quicker to
> refactor than
> rewrite.

I can't comment on option 3/4 yet, but I don't agree that option 2 is a
non-starter. Many times I've thrown out a bunch of code, started over, and
gotten there quicker (and with better results) than if I'd continued with
the existing stuff that was headed in the wrong direction.

But starting over doesn't necessarily mean rewriting everything from scratch
(thought sometimes it does).  If you start with a fresh tree, you can
establish and build the basics of the framework and copy over classes and
refactor them as needed. With a smaller starting set, each change you want
to make at the core doesn't require a mountain of changes across a large
number of classes just to validate that it even works. Plus, there are
probably a lot more people out there that are qualified to port tasks than
are qualified to make major changes to the core engine. Why not separate the

Case in point my suggestion for the selector API. After diving deeper into
the code tonight, I cound that just making the change away from the
basically final-class DirectoryScanner, to a more extensible model would
mean touching 53 classes.  That's a lot of work, and a lot of opportunities
for bugs. If we had a small core with only a few classes in place, it
wouldn't take much time at all to put a new selector api in place, validate
it with a few tasks, and leave the task porting (and testing) for later.


Do You Yahoo!?
Get your free address at

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

View raw message