A quick thought about file:// repositories: I've seen it done from time to time, and I always thought that it was decidedly un-maven. Instead of distributing a framework with copies of jars, which seemed to be the problem remote repositories were trying to solve, you just distribute the same collections of jar, but call it a repository instead? While I could see Jason's usecase for a remote repository on a shared drive, I really hope that we're not trying to keep file:// around so that it's easier to _distribute_ repositories.
On 9/10/07, Jochen Wiedmann <[EMAIL PROTECTED]> wrote: > On 9/10/07, Joakim Erdfelt <[EMAIL PROTECTED]> wrote: > > > Just a thought, but why not dump wagon in 2.1 and just use the java.net > > package for file / http / https / ftp fetch, any valid java.net.URL > > could work that way. > > > > Instead of picking and choosing what to support, just punt and support > > what is in java itself for fetch. > > > > And we can get rid of a lot of commons-* stuff in the core binary too. > > I think that's the logical generalization of Jason's suggestion and > provides room for the common use cases like file://... and jar://.. > (For practical reasons, I'd like to have pull-only repositories in a > ZIP file.) A possibility to add a custom URLHandler would be nice, > tough. That way we'd have Wagon's flexibility for pulling. > > Jochen > > -- > Look, that's why there's rules, understand? So that you think before > you break 'em. > > -- (Terry Pratchett, Thief of Time) > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Gregory Kick http://kickstyle.net/ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
