Re: repository

[Russell Gold <ru...@gmail.com>]

On Wed, 3 Nov 2004 17:10:46 +0000, Steve Loughran
<st...@gmail.com> wrote:
> On Wed, 3 Nov 2004 10:24:45 -0500, Russell Gold <ru...@gmail.com> wrote:
> 
> 
> > On Tue, 2 Nov 2004 21:40:00 +0000, Steve Loughran
> Check out ant, rebuild it, use <getlibrary> ; or look in
> src/..../tasks/repository
> 
> no docs; look at the test stuff in getlibrary.xml
> 
> I will rename the task shortly; dependencies is better.

After looking over the code, I would actually prefer that you NOT use
the name "dependencies" since I think the intent and philosophy of the
getlibraries task is completely different from my dependencies task.

My intent was to be declarative - defining a fileset or classpath by
specifying artifacts which would usually by found in a local cache,
and BTW also being able to populate that cache from one or more
repositories. It was also specifically intended to use the vocabulary
and concepts already established by maven, rather than inventing new
ones.

Your task appears to be more procedural, intending to download files,
but willing to bypass the downloading if they are locally available. 
The two don't appear to be really compatible, and anybody who used my
task would find their scripts broken if you take over the name to mean
something very different. For your task, the name getlibraries is
probably a better name.

Now if I could persuade you to use my task in preference, and simply
add the extensible repository model...

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org

Re: repository

[Russell Gold <ru...@gmail.com>]

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: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org

Re: repository

[Russell Gold <ru...@gmail.com>]

On Wed, 3 Nov 2004 19:59:14 +0000, Steve Loughran
<st...@gmail.com> wrote:
> script breaking is always an issue; ant core cannot not break stuff,
> especially as we are so very ignorant of so many uses. Note that you
> can declare tasks and types into a namespace, though I usually just
> declare stuff with a hyphen 'sf-deploy', 'axis-wsdl2java' to namespace
> stuff.  No clashes yet.
> 
> If not <dependencies>, then <libraries>, perhaps. Easier to spell.

Fine. Then I can still agitate for my approach via other means :)

> I did add the ability to set the classpath, so it is more declarative.
> I left off fileset as it is a more troublesome beast.

The uses which I have found for this task include the ability to copy
the selected dependencies into a single directory (while optionally
removing the version suffixes). This is very useful for binary
releases, which tend to ship their dependencies. You sort of need the
fileset for that. Otherwise, it is simpler to run from the cached
files.

> I chose not to explicitly use a central repository, because of the
> extra complexity of cross-project implications, such as race
> conditions and versions. I like my isolation. On a big project you can
> and should declare a central home for stuff.

I agree that it is a problem, and that declaring a central home is a
good idea. And having the ability to redefine the layout of the
repository is very good - I happen to have a case where that is
important for internal dependencies. I would like to understand better
how your approach helps with cross-project issues.

> Now, you can add support for the repository stuff in your task, just
> add the relevant setter. Once I add security it will be useful.

Yup.

> I had a look at the depot stuff in the apache incubator incidentally;
> if you haven't you should. Its a very ambitious project as it actually
> wanted to solve the versioning problem properly.

I did look at it after submitting my task to that group. Their
approach seemed to be essentially the same as mine, although slightly
less well developed. Of course, I might have missed something - the
project was never very active in the time I was subscribed to the
list.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org