ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Russell Gold <>
Subject Re: repository
Date Wed, 10 Nov 2004 16:18:09 GMT
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:
For additional commands, e-mail:

View raw message