On Wed, 10 Nov 2004 11:18:09 -0500, Russell Gold <[EMAIL PROTECTED]> wrote: > 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.
I should note that I have been busy changing things, but havent committed anything yet as there are no new tests. The new change is IMO, quite significant, and may change your opinion regardling the limits of <getlibraries>
Essentially you will be able to define new updatepolicy datatypes that are called before and after uploads.
the before callback lets you manipulate the list of files, mark them for download or not, even cancel the update. the post-download callback lets you add extra security like JAR signature validation, file renaming using mappers, etc.
> > 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.
not the command line, but as a datatype within the build file, or something else you import.
Anyone is free to implement their own repository type, so you can bond to different kinds of repository altogether.
> > 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.
If all build files declare a common cache in <getlibraries>, you get sharing.
> b. The first approach provides no simple way to exclude dependencies > for alternative testing scenarios without clearing and reloading the > target directory
doesnt the if and unless tags on the <library> do that?
> 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?
What are the big issues? That I am using the wrong layout style client side (easily fixed), or is the lack of a single unified per-user cache the real problem.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
