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 17:32:52 GMT
On Wed, 10 Nov 2004 17:00:16 +0000, Steve Loughran <> wrote:
> 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 IMO,
> quite significant, and may change your opinion regardling the limits of
> <getlibraries>
> Essentially you will be able to define new updatepolicy datatypes that
> are called before and after uploads.
> the before callback lets you  manipulate the list of files, mark them
> for download or not, even cancel the update. the post-download callback
> lets you add extra security like JAR signature validation, file renaming
> 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 bond
> 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.

>  > b. The first approach provides no simple way to exclude dependencies
>  > for alternative testing scenarios without clearing and reloading the
>  > target directory
> doesnt the if and unless tags on the <library> do that?

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?

> What are the big issues? That I am using the wrong layout style client
> side (easily fixed), or is the lack of a single unified per-user cache
> 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 cache
- use the ibiblio repository for downloads

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.

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

View raw message