ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Adam Murdoch" <adammurdoch...@yahoo.com>
Subject RE: <antlib> (was RE: Ant 1.9 & Task Packaging)
Date Thu, 24 Jan 2002 01:34:53 GMT


> -----Original Message-----
> From: Jose Alberto Fernandez [mailto:j_a_fernandez@yahoo.com]
> Sent: Thursday, 24 January 2002 10:32 AM
> To: Ant Developers List
> Subject: Re: <antlib> (was RE: Ant 1.9 & Task Packaging)
>
>
> From: "Steve Loughran" <steve_l@iseran.com>
>
> > >
> > > So what's holding us back with implementing <antlib>? There were some
> > > proposals a while back but nothing ever really happened with them, it
> > seemed
> > > there was some concern about forward-compatibility with Ant2 - is that
> > still
> > > the concern?
> >
> >
> > Jose Alberto's implementation is in the sandbox; works with
> today's builds
> > and includes the descriptor generation task as well as the loading task.
> >
> > But to go into the main codebase there has to be widespread
> happiness about
> > the descriptor and the process for declaring it.
> >
>
> Let me just say, that I would had no problem on considering
> making changes or
> adding features to the descriptors, either from the begining or over time.
> But sadly, some in the committers team just plainly used the veto power
> and that was the end of that.
>

I think one of the reasons was backward compatibility.  Not between Ant 1.x
and Ant 2, but between the Ant 1.x release where antlibs are first
introduced, and later Ant 1.x releases.

As should be obvious from the discussions, there are a bucketload of issues
which need to be addressed by the Antlib solution.  Extracting a list
taskdefs from some descriptor in a Jar file is just the very start.  We
*will* get antlibs wrong in the first Ant 1.x release.  It's a certainty.
Of course, once we get it wrong, well, its too late because of backwards
compatibility.

A much better situation would be if we had somewhere to trial this stuff,
where it can be used by people, where we can evolve it, but where we are not
constrained by compatibility issues (at least, until it has stabilised).

This is the exact reason I'm so keen to get an Ant 2 tree happening.  Seems
to me that the antlib issue is deadlocked, because it is all mostly talk at
this stage.  And talk that goes around in circles.  We've *been* over the
issues - it's time to cut code, to see which of the issues are real, which
are solvable, which are not, and what new ones lurk in waiting.

However, there is nowhere for someone (not necessarily a developer) to
grab/build a binary that works more-or-less like Ant 1.x, but which includes
an experimental antlib feature.  We have a proposal ready to go in Jose
Alberto's implementation, but nowhere to plug it into, and say to people
"well, try it out".

Same for the selector API, or the VFS proposals.

Even if we did, then what?  Say we take Ant 1.x and add a feature to it, and
people try it out and say "beauty, it needs work, but let's start with
that", what then?  Where do we put proposals that have been provisionally
accepted?

A lot of the features are inter-dependent, and we need somewhere to evolve
them together.  For example, take the selector API - we've already
discovered that it would be far more powerful when used with 2 other planned
features (type substitution and a VFS).  That doesn't mean we should put off
doing a selector API until those features are "finished".  It means we
should do a simple proof-of-concept, check it into the Ant 2 tree, and then
grow it as the other features start to become available.  It's not
impossible do this with a bunch of separate ad hoc proposals spread all over
the place, but it is far better if they live in the same tree.

One of the options I suggested for the Ant 2 tree, was to take a straight-up
copy of Ant 1.x and go from there.  This would be an ideal place to try out
these proposals, to combine them, to see how they interact, and to evolve
them.  Also an ideal place to extract features from mutant and myrmidon
into.

We would start with something that works more-or-less like Ant 1.x, and
start adding features.  It would continue to look more-or-less like Ant 1.x.
We would do frequent milestone releases that people can grab and *use*.  We
wouldn't call it Ant 2 for a while - a code name would do the trick.  There
would also be large disclaimers saying 'experimental' (but useable).

What do people think about an approach like this?


Adam


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