ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Loughran <>
Subject Re: repository
Date Wed, 10 Nov 2004 20:32:12 GMT

On Wed, 10 Nov 2004 12:32:52 -0500, Russell Gold <>
> On Wed, 10 Nov 2004 17:00:16 +0000, Steve Loughran <>
> > I should note that I have been busy changing things, but havent
> > committed anything yet as there are no new tests. The new change is
> > quite significant, and may change your opinion regardling the limits
> > <getlibraries>
> > Essentially you will be able to define new updatepolicy datatypes
> > are called before and after uploads.
> >
> > the before callback lets you  manipulate the list of files, mark
> > for download or not, even cancel the update. the post-download
> > lets you add extra security like JAR signature validation, file
> > using mappers, etc.
> I guess my feeling is that it is too complex for what should be a very
> simple concept. I see the most important issue as a concise definition
> of what dependencies are to be used. The more processing options you
> have, the harder it is to see them, and I don't understand what use
> cases you have in mind for all of this flexibility. But I will have to
> see your changes to be certain.
> > Anyone is free to implement their own repository type, so you can
> > to different kinds of repository altogether.
> Yes, and that is a very good thing which I have stolen for my own task
> >
> > If all build files declare a common cache in <getlibraries>, you get
> > sharing.
> That is extremely unlikely for all projects developed by different
> individuals. You cannot rely on ant, nekohtml, jtidy, and many other
> projects all to pick the same cache if it is not built in to the task.
> And if each task renames its libraries, you cannot count on them
> picking the same name. 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. 

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

> If you call the task to load the directory with one set of files and
> then call the task again with different properties, won't the excluded
> files still be in the directory?

yes. The path will be different. And if you d/l to build/lib then a
clean does erase them.

> > What are the big issues? That I am using the wrong layout style
> > side (easily fixed), or is the lack of a single unified per-user
> > the real problem.
> I am not sure what you mean by "layour style client side." The latter
> is probably more important. Of course, once you have a single unified
> per-user cache, you also need a fileset in order to select files to be
> copied to a distribution. The default behavior should also be the most
> common :
> - don't even try to download files unless they are missing from the

will be the default policy

> - use the ibiblio repository for downloads

is if you say <mavenrepository>

> I suspect that you and I are thinking of different use cases in order
> to come up with these different approaches. For example, I see no need
> to compare remote file times since the name and version should
> uniquely specify a remote file. This is the usual way to deal with
> released dependencies.
> 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

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

View raw message