ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Russell Gold <>
Subject Re: repository
Date Wed, 03 Nov 2004 21:00:33 GMT
On Wed, 3 Nov 2004 19:59:14 +0000, Steve Loughran
<> 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

> 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.


> 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

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message