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.
-steve
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
