On Wed, 10 Nov 2004 12:32:52 -0500, Russell Gold <[EMAIL PROTECTED]>
wrote:
> On Wed, 10 Nov 2004 17:00:16 +0000, Steve Loughran <[EMAIL PROTECTED]>
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.
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',
really.
> 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
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
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
versions).
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
