Brett Porter wrote:
On 9/21/05, Steve Loughran <[EMAIL PROTECTED]> 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
features.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
