After some more thought, I would like to reopen the discussion on this work. I see that we are trying to solve roughly the same problem (projects obtaining dependencies from remote repositories) but with a very different outlook. I think the differences are significant enough to discuss both between us and more importantly with the ant committers as a group.
As I see it, the two main approaches are: 1. The "getLibraries" task. Fetches a set of libraries to be fetched from a repository and copied into a designated directory. Uses semantics analogous to "copy" to decide whether the libraries already present need to be replaced. The repository for a set of libraries is not inherently part of the task, and may be specified either within the task or on the command line. Optionally defines a classpath from the fetched libraries. 2. The "dependencies" task. Identifies a set of files in a repository by version and creates either a classpath or a fileset (or both) based on the definition. Maintains a local cache of the files which may be shared by multiple projects, loading it from the specified repository. The repository is an inherent part of the definition. May conditionally exclude entries from the set. The first is essentially a generalized "copy" task while the second is a generalized "fileset" or "path" task. I am not sure that it would be OK to have both, and I believe that the second approach is preferable for the following reasons: a. The first approach forces each project to download its files individually, and may require new downloads after a total-clean. The second permits multiple projects on the same box to share files, and only requires new downloads if a file is not found in the cache, thus facilitating detached development as long as the desired files were ever loaded on that computer. b. The first approach provides no simple way to exclude dependencies for alternative testing scenarios without clearing and reloading the target directory c. It is generally not meaningful to separate the specification of a remote file from its home repository except in the case of mirrors d. While ant should certainly not require anything from other projects such as maven, the maven model for managing dependencies is fairly well established and proven - the second approach imitates it, making it relative easy for developers used to one to use the other as well. Does this make sense to you? --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]