Mailing-List: contact dev-help@ant.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Ant Developers List" <dev@ant.apache.org>
Received-SPF: pass (asf.osuosl.org: domain of brett.porter@gmail.com
 designates 66.249.82.204 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=b0bOc8xkci5C+vg4B2TLndf5cDCiRIE5x34QHP2zcl45vXxwKDxG8+qgKJso9sn2DWnqm1driVZSRWOKyHDqZG3dJ0o+Xm0yF6fBxTf4SSNjA5MOd8VB13i6CTF0RTKkYdQP2o1g2ESejPOixhZhWf2yNVXp9nOh7mIe3AgCJjk=
Message-ID: <9e3862d80509210212110d1905@mail.gmail.com>
Date: Wed, 21 Sep 2005 19:12:57 +1000
From: Brett Porter <brett.porter@gmail.com>
Reply-To: brett.porter@gmail.com
To: Ant Developers List <dev@ant.apache.org>
Subject: Re: Maven and Ant collaboration on task codebase
In-Reply-To: <43311E5F.3060108@apache.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
References: <9e3862d805092021196b667485@mail.gmail.com>
	 <4330E4A2.4070800@it.fts-vn.com> <43311E5F.3060108@apache.org>

On 9/21/05, Steve Loughran <stevel@apache.org> wrote:
> yes, we can discuss it :)
>=20
> I do actually agree that execution and JAR files ought to be structured
> so that they can be reused. The code in there is some of the best
> debugged stuff out there in Java for doing both.

Ok - good that we agree on the fundamental point :)

> But I dont want to break ant or make Ant1.7 slip in the process; and we
> cannot change the public interfaces for all the existing classes.

Right. That was the first point I listed about backwards compat, and
your facade plan would allow that. This in a beyond-Ant-1.7 timeframe
sounds fine by me too - I would expect the time taken to get the
refactoring happening, tests done, library documented would exceed
that anyway. And hopefully there will be people outside of Ant willing
to contribute to the effort.

> which leaves a design like
>=20
> -move execution, Jar support self contained packages in the ant codebase
> -provide self contained API with unit tests for that functionality.
> -retain the existing stuff as facades

yep.

> -release a separate ant-execution library, at exactly the same frequency
> as ant point releases.

I'm not sure that this is required. Surely an Ant release can just use
the last release of that library, whenever and whatever that was. If
there is a real need to get a certain fix or feature in, then driving
the release of that library before Ant needs to happen. This isn't
cumbersome if the development of the library is set up to allow
frequent releases (ie, a stable branch all the reliable fixes and
improvements go onto).

> The latter is going to be problematic, and here's why. If there is one
> thing that always causes grief in Ant, its JAR files sticking other Jars
> inside. Groovy, jython, maven-artifact-ant-2.0-beta-1-dep; all
> incorporate other things like regexp, jsch, whatever into their JAR,
> creating lots of classpath conflict. If we integrate execution into ant,
> either within ant.jar or as an associated JAR, we cannot make it
> possible for someone to stick an inconsistent version in, -or at least
> we cannot make it possible for someone like me to ship a 3rd party ant
> task that also includes an updated version of the libraries.

Ok, I did fix your main gripes in the artifact ant tasks for b1 :) No
libraries other than Maven ones and plexus (these need to change too
eventually, but they don't have many 3rd party users right now, and
none that are writing ant tasks).

Anyway, this was my 3rd point in the original email. It is an issue,
but it can be resolved by incorporating that code in a different
package structure. This should be a relatively simple task:
- get release being used from svn (externals?)
- copy sources into ant source tree/temp source directory, mapping
paths from o/a/commons/exec -> o/a/tools/ant/exec
- replace package statement in source files

It is a bit gruesome, but it does work.

What are the alternatives to this? You can keep the source in the Ant
tree, but you still need to do the package munging in reverse:
- keep the above layout, but build "ant-exec" library from the source
tree after copying and adjusting the packages to something different
from what Ant uses
- build the "ant-exec" library separately, after ant is built, based
on those sources. This would tie the exec library release to the Ant
release.

To me, moving the code to commons (or similar subspace of the ant SVN
tree), with its own release cycle and incorporating it back into the
Ant bootstrap rather than the other seems the more natural option.
We're faced with a similar problem in Maven 2 and that is the approach
we plan to take. In fact, since this will be a standalone Java app, we
could probably share it.

Is this feasible, or am I missing something?

Cheers,
Brett

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org