To me file:// repos were for local situations where you wanted to test
or fix maven build behaviour because of some condition. For example,
you're one machine is behind a firewall and you are not able to cross
the boundary to pull in stuff into your build system, so you create a
repo for that project that is accessed via file://. This "local-ish"
repo is then auditable by some team that you would have had to
submit .jars to anyway. Or cases where some java core jar isn't
available (days before java.net repo) and you didn't want it in your
local repository, because you blow away your local repo to debug
someone else's build issues, attempting to replicate them on your own
machine.
Most of the cases I've seen involve this sort of disallowed external
access, or missing external presence, and file:// is a great way of
doing the equivalent of install:install-file once and not having to
repeat it. Also, it's a better simulation of the case if you are
anticipating the eventual availability of what you put into local.
The other case is where you are building a repo out of a 3rd party app
that CANNOT be distributed, such as, say, BEA Weblogic Portal.
Building a locally hosted repo once is monumentally easier than trying
to install all the files, once someone goes through the trouble.
Basically, file:// is a great way to work around access limitations
and resource limitations in environments that don't really allow the
sort of code ecosystem that maven attempts to encourage. I vote
(clearly non-binding) to leave it in.
Christian.
On 10-Sep-07, at 11:18 AM, Gregory Kick wrote:
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
