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 22:36:25 GMT
On Wed, 10 Nov 2004 20:32:12 +0000, Steve Loughran <> wrote:
> On Wed, 10 Nov 2004 12:32:52 -0500, Russell Gold <>
> > That is why I like the maven-style cache. It
> > defines an unambiguous name for the cache and unambiguous names for
> > each of the files in it. Sharing is then automatic and guaranteed.
> yes, but you also have to worry about file locking.
> If we adopt a common cache then we need to change the update to download
> to a file with a .part extension, then rename on success.

Sounds like overkill to me (individual users rarely build two projects
so simultaneously that the scenario is ever likely to arise.

> but, I dont see why it is so wrong to say 'download for every project',
> really.

Build time is one issue. When you are working on a large project with
dozens of dependencies, it is really nice not have to download every
time you reset to just what is in the CM repository. It also lets you
do a total clean (wipe out all generated files) and build while
disconnected. I do that all the time.

> > - don't even try to download files unless they are missing from the
> cache
> will be the default policy
> > - use the ibiblio repository for downloads
> is if you say <mavenrepository>

Why even require it?

> > On the other hand, perhaps the special version "LATEST" should
> > override that behavior and say that the task should try to pick
> > whatever version is the latest, and compare its times. This is more
> > common in at least some styles of internal development, where version
> > numbers don't make as much sense.
> Exactly. With the changed policy timestamps wont be relevant unless you
> ask for them.
> I think its this use case why I'm worried about the cache too; LATEST
> there scares me, even though its a wonderful technique (right up to the
> moment you try and field a bugrep and all you know is they had LATEST
> versions).

I had assumed that this was your goal. I suspect I still don't
understand your use case. I never use LATEST myself, insisting on
actual named releases as dependencies. But if you are not interested
in LATEST - why do you ever care about timestamps? The code becomes
*much* simpler if you ignore them.

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

View raw message