Le Mardi, 30 sep 2003, à 15:15 Europe/Zurich, Berin Loritsch a écrit :
...
...In projects where I'm working we do it slightly differently, we have a parallel CVS module for tools, shared between projects, with directory names including version numbers, and the build.sh script accesses the appropriate version of the tool with relative paths like
../cvs-tools-sandbox/ant/1.5.1
With avoids heavy duplication of tools yet allows each project to use the "right" version of a tool.
Still -1. While this can be a "special" issue, ANT 1.6 should be backwards
compatible with ANT 1.5.1. I know that 1.5.4 is. They have a number of
test cases to verify that....
In theory yes - in practice, it is very hard to get several project teams to agree on a common version quickly, and during the "transition period" until everyone agrees there can be problems.
But again, I understand your point of view, it is the "duplication of tools" vs. "safer distribution" debate.
Given the current need for a source code only distribution, I think the duplication is "less worse" than the risks of wrong ant versions of installations on the user's side.
"duplication" is percieved issue, nobody yet mentioned that in "real life" (tm) single installation of ant simply won't work. Remember, that ant picks up all the libraries in the $ANT_HOME/lib folder, and in order for build to work, lots of people add additional libraries there: junit, httpunit, xmluntil, anteater, etc, etc, etc. Now, imagine all the hurdles users will have to endure to make sure that they have all the necessary jars in all the necessary places.
Next step. Imagine that user uses more than one project on the same box with the same ant... And it requires some different version of some different third party ant add-on...
Vadim
