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 08:48:31 GMT
Kev Jackson wrote:
> Here's my non-committer 2pennies worth...
> I think it would be beneficial to refactor Ant for some of the 
> commons-libs (commons-exec for example), I also think it'd be useful for 
> Ant 1.7 to splitoff as many tasks as possible into antlibs.  The Antlib 
> idea seems to me to be the best way of refactoring Ant into a component 
> based system where individual tasks can be released without having to 
> release a new version of Ant (the main purpose of Antlibs was this as 
> far as I'm aware).

I think the main goal of antlibs was to
(a) permit stuff to be completely decoupled (eg dotnet)
(b) make it easier for 3rd party stuff to integrate withant without all 
the typedefs

As someone who does do third party tasks to work with both ant1.6 and 
1.7, I am also well aware of the price: versioning against Ant JARS. 
Even If we fix something in Ant SVN HEAD, anything released on its own 
schedule still has to work with the older stuff. I have real problems 
with things like java and the spawn options, and something in file utils 
warns me it is deprecated whenever I build, just because I want to 
retain compatibility with Ant1.6

> With the Antlibs in place (assume all SCM related tasks and some others 
> converted to antlibs instead of core/optional), the process of 
> refactoring out commons-XXX libraries I would think would be simpler, 
> not least in tracking and fixing bugs.
> You're right when you mention the Jar hell problem, I can imagine that 
> would be a major pain to deal with if ant required commons-xyz and 
> commons-xyz required ant to compile.

yes, ant has the bootstrap problem. Core ant cannot depend upon anything 
under than the JDK and an XML parser. And that includes execution.

> Anyway, from me, I think it'd be worthwhile to at least discuss 
> refactoring out common components.

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.

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.

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
-release a separate ant-execution library, at exactly the same frequency 
as ant point releases.

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.


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

View raw message