ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tim Dawson" <tdawso...@yahoo.com>
Subject RE: <antlib> (was RE: Ant 1.9 & Task Packaging)
Date Thu, 24 Jan 2002 06:12:49 GMT
Adam,

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

It depends on how you define backwards compatibility. If all we're concerned
about is that the same build.xml works, then I have a proposal. Why not
create an "experimental.jar" to go along with the "optional.jar" for new
tasks/typedefs, and by convention use a prefix "x-" for the element names.
If someone uses experimental types or tasks, then they are accepting the
work of fixing the build.xml file *when* (not if) it changes into the final
form.

For example, if we start with:
<x-antlib file="blah/blah.jar"/>

then another idea is added to the mix:
<x-antlib2 location="blah/blah.jar" useXML="true" useTools="true"/>

We throw this out in Ant 1.5 (for example) the community discusses,
thrashes, etc. and finally we merge the two, remove <x-antlib> and
<x-antlib2>, and release <antlib> in Ant 1.6 as:
<antlib file="blah/blah.jar" useXML="true"/>

We could do some of this actually right in Ant 1.x.

Again, this only works if the issue is the build.xml. When trying out deeper
changes to core, e.g. classloaders, introspection, roles (cool idea!), etc.
then yeah, those are issues that would probably require creating a few
branches, trying them out, and moving from there. The only problem with
branching a lot of different code-worded projects is when people form an
attachment to one way or another and you have problems merging them back in.

In general, I think there's a growing frustration about the lack of progress
over the last year. I seem to remember General Schwarzkopf on NPR a few
weeks ago saying that a wrong decision is better than no decision at all. I
happen to agree - at least you can learn from the wrong decision. The
situation we're in is nobody's fault; this is just one area where
open-source development frequently falls down... especially when, unlike
linux or tomcat or struts, there's no one clear leader, a benevolent
dictator with the creds to *make*a*decision* and have others be willing to
follow along.  But we do need to find a way out of it, and the approach you
suggest is as good as any I've heard.

Tim


> -----Original Message-----
> From: Adam Murdoch [mailto:adammurdoch_ml@yahoo.com]
> Sent: Wednesday, January 23, 2002 7:35 PM
> To: Ant Developers List
> Subject: RE: <antlib> (was RE: Ant 1.9 & Task Packaging)
>
>
>
>
> > -----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>


_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


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