ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Adam Murdoch" <>
Subject RE: [VOTE] Ant2 codebase adoption process
Date Sat, 26 Jan 2002 03:30:50 GMT


I think one of the main motivations for Ant 2 is to address the
architectural shortcomings of Ant 1.  The Ant 1 code base has gone far
beyond the brittle stage.  It's rock solid.  Too much of the engine is
exposed, and there are too many inter-dependencies.  Which means that while,
yes, it is possible to think up new features that are backwards-compatible
at the build file POV, it is very difficult to *implement* those behaviours
without affecting something else.

This is the crux of the matter.  We can't, in general, add new stuff to the
Ant 1 codebase without affecting some existing API or build file behaviour.

Nor can we refactor.  And so we miss out on one of the most powerful tools
for product development.

So, to my mind, we're stuck.

An major goal for Ant 2, then, should be to do some serious refactoring of
the engine, so that we end up with a platform where features are better
abstracted and isolated, so we can add and remove features without affecting
others.  At runtime, and under the user's explicit control.  Then, we can
experiment with features to our heart's content, while maintaining various
levels of backwards (and forwards) compatibility, for those that depend on

As you point out, backwards compatibility is an important issue.  Important
enough that we should build it into the plan for Ant 2.

Would something like this be acceptable?

* Start a separate source tree for the Ant 2 proposal.  Ignore what goes in
it for now.  Nothing, say.

* The Ant 1.x tree remains active, with regular(-ish) releases continuing
from it while Ant 2 work is in progress.  And quite a bit beyond an Ant 2
release, most likely.

* Define a number of milestones, which the proposal must meet.  Some of
these milestones would be feature-based, such as handling typelibs.  Other
milestones would be compatibility milestones.  Maybe something like this
(ignoring the feature milestones):

  Milestone 1: Handle a tiny set of core tasks, say <property> and
  Milestone 2: Be able to self-build, using a native build file.
  Milestone 3: Be able to self-build, and be built by Ant 1.x, from the same
build file.
  Milestone 4: Be able to build a set of projects on Gump, that do not use
custom tasks.
  Milestone 5: Be able to use a set of the Ant 1.x tasks, from ant.jar,
  Milestone 6: Be able to build all (or almost all) of the Gump projects.

Of course, the set of milestones would be fairly fluid, and we wouldn't need
to decide on what they should be, more than one or two in the future.

The point here is that, from early on, we have something that is usable, and
looks more-or-less like Ant 1.x.  Which means we have a useable platform for
experimentation.  If an experiment suceeds, we can tidy it up, and look at
porting it back to Ant 1.x.

* Don't call the proposal "Ant 2" until it has met certain requirements.
One of which would be a well defined set of compatibility criteria.  A
comptability test suite would be really useful here (Gump would be the
obvious candidate).  Again, the set of requirements would be fairly fluid,
and don't need to be locked down until much closer to a potential alpha


> -----Original Message-----
> From: []
> Sent: Saturday, 26 January 2002 3:42 AM
> To: Ant Developers List
> Subject: Re: [VOTE] Ant2 codebase adoption process
> On Fri, 25 Jan 2002, Peter Donald wrote:
> > > Are you kiding ??? Ant internals have changed between each
> 1.x release - I
> > > can hardly recognize things.
> >
> > Change is not the problem. Incompatible change is a problem.
> And we had enough of that too.
> > > Could you explain this ? Except for adding a task that has
> the same name
> > > with a user-defined task, there's little else that can happen.
> >
> > hmmmm - you think? When Connor added the ability for
> addConfiguredX to behave
> > like addX except where component was "configured" prior to
> being added. This
> > would break any task that had an element named <configuredX/> -
> unlikely to
> > happen but possible. Any addition of a non-private method can also
> > potentially cause conflicts because a lot of people subclass
> ant tasks and
> > types. For instance when an extra method was added to the zip
> task it caused
> > some tasks in AValon project to break because the avalon tasks used same
> > attribute name. We also dropped support for certain XSLT
> Liasons because they
> > were based on dropped unsupported products. So on and so forth.
> Than add namespace support first !
> I'm not asking for 'perfect' backward compatibility - it's a difference
> between removing an xslt liaison for a product that is no longer supported
> and changing the default behavior on undefined properties.
> It's a difference between breaking user tasks because they have the same
> name with an ant task ( which will be a non issue with namespace support),
> and removing or renaming attributes in chmod or jar or some frequently
> used task because the old name is not on our taste.
> > > Ant1 works very well - I haven't had almost any 'itch' with
> it in almost a
> > > year. If some functionality requires breaking build.xml and basic task
> > > patterns - I don't think adding it is the right thing to do.
> >
> > thats been made abundently clear. There are however people
> asking for things
> > all the time. You can see the same sorts of things being asked
> for over and
> > over and over again. Most of these are symptoms of problems in
> initial design.
> And most of those things can still be implemented with a minimal impact on
> what currently work. If someone asks for 'modifiable properties' - that
> can be done adding a new type of properties with a different syntax, and
> even recommending and making it the 'official' syntax, or it can be done
> by just changing the behavior of existing properties to something else.
> If people ask for exceptions on undefined properties - that can be
> implemented by using a flag ( or even better, an property ), or by
> changing the default behavior and screwing all existing projects.
> Costin
> --
> To unsubscribe, e-mail:   <>
> For additional commands, e-mail: <>

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

View raw message