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. - Joakim John Casey wrote: > I think it's also a reasonable goal to allow people to use projects > that refer to embedded remote repositories to build...that way, the > build is totally self-contained. This is one of the things that the > assembly plugin tries to do with its <repositories/> section (though > it doesn't work very well so far...but that's just a matter of time). > > IMO, file:// is a nice thing to have, unless we have some way of > allowing the above to work without the file wagon being in core (maybe > I'm not thinking about it the right way). > > -john > > > On Sep 7, 2007, at 8:20 PM, Brian E. Fox wrote: > >> I don't currently, but have in the past used file:// for remote. >> >> The use case was that we had to mirror our internal repo to another corp >> network. We essentially zipped up the repo and transferred it to their >> machine (regularly and automatically via scm), which set a mirror entry >> pointing to the local fs. This had to be done this way because a proxied >> connection to our internal repo was not allowed, they needed full copies >> of the entire build in scm. >> --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
