> On Wed, 10 Nov 2004 20:32:12 +0000, Steve Loughran <[EMAIL PROTECTED]> wrote:
> >
> >
> > On Wed, 10 Nov 2004 12:32:52 -0500, Russell Gold <[EMAIL PROTECTED]>
> > > 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.
>
you dont have a work cruise control server building 5+ projects do you?
Saving files to the side of the main one is important in caching as
(a) the download could take some time over a slow link, so the window of the race is quite big
(b) if the download failed half-way, you'd break not only the build you were running, but every other build on the system.
I rest my case. Even if (a) isnt an issue for you, (b) could be.
> > will be the default policy > > > > > - use the ibiblio repository for downloads > > > > is if you say <mavenrepository> > > Why even require it?
no good reason either way, 'cept it makes it explicit where the stuff comes from.
> > > > 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.
Like I said, I will change default behaviour to only fetch missing stuff.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
