On Thu, 05 May 2005, Steve Loughran <[EMAIL PROTECTED]> wrote:
I am thinking of stopping all work on <libraries>, embracing the maven2 stuff instead.
Sounds reasonable if you can make it do everything you intended to do with <libraries>.
I am having mixed fun here. With a new <copypath> task I can extract the path and copy it into any directory (with flattening). But what is hurting me here is the tasks' belief that I need the dependencies that jars were built against.
Example: fetching commons-logging 1.04
[artifact:dependencies] Downloading: commons-logging/commons-logging/1.0.4/commons-logging-1.0.4.pom
[artifact:dependencies] Transferring 7K
[artifact:dependencies] Downloading: commons-logging/commons-logging/1.0.4/commons-logging-1.0.4.pom.md5
[artifact:dependencies] Transferring 0K
[artifact:dependencies] Downloading: avalon-framework/avalon-framework/4.1.3/avalon-framework-4.1.3.pom
[artifact:dependencies] Transferring 0K
[artifact:dependencies] Downloading: avalon-framework/avalon-framework/4.1.3/avalon-framework-4.1.3.pom.md5
[artifact:dependencies] Transferring 0K
[artifact:dependencies] Downloading: junit/junit/3.7/junit-3.7.pom
[artifact:dependencies] Transferring 0K
[artifact:dependencies] Downloading: junit/junit/3.7/junit-3.7.pom.md5
[artifact:dependencies] Transferring 0K
[artifact:dependencies] Downloading: log4j/log4j/1.2.6/log4j-1.2.6.pom
[artifact:dependencies] Transferring 0K
[artifact:dependencies] Downloading: log4j/log4j/1.2.6/log4j-1.2.6.pom.md5
[artifact:dependencies] Transferring 0K
[artifact:dependencies] Downloading: logkit/logkit/1.0.1/logkit-1.0.1.pom
[artifact:dependencies] Transferring 0K
[artifact:dependencies] Downloading: logkit/logkit/1.0.1/logkit-1.0.1.pom.md5
[artifact:dependencies] Transferring 0K
[artifact:dependencies] Downloading: logkit/logkit/1.0.1/logkit-1.0.1.jar
[artifact:dependencies] Transferring 70K
[artifact:dependencies] Downloading: logkit/logkit/1.0.1/logkit-1.0.1.jar.md5
[artifact:dependencies] Transferring 0K
[artifact:dependencies] Downloading: log4j/log4j/1.2.6/log4j-1.2.6.jar
[artifact:dependencies] Transferring 342K
[artifact:dependencies] Downloading: log4j/log4j/1.2.6/log4j-1.2.6.jar.md5
[artifact:dependencies] Transferring 0K
[artifact:dependencies] Downloading: junit/junit/3.7/junit-3.7.jar
[artifact:dependencies] Transferring 114K
[artifact:dependencies] Downloading: junit/junit/3.7/junit-3.7.jar.md5
[artifact:dependencies] Transferring 0K
[artifact:dependencies] Downloading: avalon-framework/avalon-framework/4.1.3/avalon-framework-4.1.3.jar
[artifact:dependencies] Transferring 62K
[artifact:dependencies] Downloading: avalon-framework/avalon-framework/4.1.3/avalon-framework-4.1.3.jar.md5
[artifact:dependencies] Transferring 0K
At the end of this, I end up with log41.2.6 and junit.3.7. Which, when I copy into ant_home/lib, (as they are on the path), means that older versions of all the libraries come in. This is not what I want, and will lead to much more pain.
I think what is happening is that the maven dependency model does work if you live only in maven-land (that is, provide your own poms, only set up classpaths via the dependency declarations). In this world, dependency logic should be a lot better than the classic whatever-is-in-the-filesys classpath setup we know and use. But trying to merge the two hurts.
There is some mention in the docs of a "scope" switch, which seems to control some of this, but doesn't have a "no-transitive-fetching" option, which is what we need. Without that, it is unusable in ant itself, which does not bode well for other projects. Indeed, I cant seem to use it any of the three I've tried as eventually this transitiveness hits a brick wall somewhere in the dependency chain of the various XML tools.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
