ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Loughran <>
Subject Re: Maven and Ant collaboration on task codebase
Date Wed, 21 Sep 2005 09:49:30 GMT
Brett Porter wrote:
> On 9/21/05, Steve Loughran <> wrote:
>>yes, we can discuss it :)
>>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
>>-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).

thank you!

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

i see, a kind of automated boostrap process, requiring SVN, but only at 
the time you want to download and create the snapshot. then patching all 
the stuff to the new packages and inserting "dont edit this here" 
messages. yes, it might work. I've done worse.

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

I suppose with your approach, it opens up execution management to a 
broader committer base, which can only be a good thing. I'd probably 
steal it for smartfrog BTW; the execution stuff there is not as 
sophisticated, though it does fork the running JVM better (though not as 
well as if Java had a fork() command)

what do you suppose the base exec and package libraries would look like? 
That is, how well can we decouple them from Ant's datatypes and other 

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

View raw message