That sounds good to me, and I see where the identifiers have come in; I think you could do without them though, and just use the repository URI as the identifier :-
For 'external' mirrors, accessed directly and not through a repo manager: Say you have repo1.maven.org/maven2, and global mirrors of eu.repo1.maven.org/maven2 and us.repo1.maven.org/maven2. I think the <repository> doesn't need an id. There are a few options to get it to use a more localised mirror - Geo aware DNS (I think things like wikipedia are doing this). A bit hard core. - Your settings.xml file, containing a list of mirrors/redirect information based on the URI. But this settings.xml could be configured from choices either shipped with maven after installation, or (better), there might be a repo-config-SNAPSHOT.xml[1] in repo1.maven.org/maven2/repo1/maven/org/maven2/ that contains this information. Something interactive gives you the choice of manipulating your settings from the known, valid options. But a default, non-interactive build would still know where to go. For 'internal' mirrors, accessed through a repo manager: - Your install wants http://repo1.maven.org/maven2 - Your settings, as you're inside the corp firewall, say 'here is the proxy server' - The repo manager uses the appropriate strategy (including the above) to fetch or deny from repo1 or the appropriate mirror. [1] Or whatever. What would be really nice is that as well as keeping metadata about artifacts in the repository, there was a way of accessing (optionally available) metadata about the repository itself in some downloadable artifact. That way an entire 'uptodate' check for repo1 might be simply checking the ETag on 1 file. A black/whitelist of available artifacts would help preventing asking for SNAPSHOT artifacts from umpteen repos before hitting the right one; if search/index information were standardised, that could be transferred as well... On Sun, Mar 16, 2008 at 11:05 PM, Brett Porter <[EMAIL PROTECTED]> wrote: > Forking the other thread. > > Maven still needs to work properly without a repository manager (even > if it is a good practice to use one). In my opinion, that means: > - proper unique identifiers for repositories (my preference would > actually be to control this by group ID, but I see too many counter > examples in the Maven repositories to make this realistic - if anyone > has ideas on this front please say so). > - proper mirroring support (ie, specify which mirror you want to use > for central, etc so you can get a nearby one out of the box, like > CPAN, yum, etc type setups - I have some hand written notes from some > time back sitting on my desk I can kick into the wiki) > - full control over the repositories you use from the settings file. > > When it comes to handling repositories in POMs - I think they should > still be in there, but only be a hint. ie, if the repo with that ID is > not configured, Maven can intelligently tell you how to configure it > if you want to, and the consequences of doing so. But I'm sure there > are plenty of other ways we could deal with this. > > On top of this, explicit support for repository managers (that > supports all of them) as a way to replace one or all of your > repositories should be available and encouraged. > > Are these all the use cases folks see? > > - Brett > > -- > Brett Porter > [EMAIL PROTECTED] > http://blogs.exist.com/bporter/ > > > --------------------------------------------------------------------- > 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]
