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. > > 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
