Hi, I always looked at repo IDs as "something local" to my machine (take into account Brian's note: apache.snapshot vs apache.snapshots vs apache-snapshot etc). How many builds exists with those variants of the same repo?
Also, you can easily "pull in" the _same_ repo with different ID into the build over some dependency or different profile. What then? My thought: a) if using "entry level" / OSS maven, the repo URL will be entered by the user anyway. b) if using "enterprise level", where we can expect some control, the URL will also be added once somewhere (centrally managed settings, repoman or whatever), but we can expect that "enterprise level" users will/should use "enterprise level" tools :) Hence, the URL is the one and only thing that fulfills the HTTP "adressability" of repo, even if the repo is "dead" (absent, host is down or simply the project ceased to exist), we can keep a history/list/directory of know reposes and optionally offer some alternatives. Not saying this is a job for maven itself, mere for the maven community. And we can make tools easily that consumes those directories and makes the job. ~t~ On Mon, Mar 17, 2008 at 1:33 AM, Brian E. Fox <[EMAIL PROTECTED]> wrote: > I think there are two mutually exclusive things : 1) in an enterprise > with a repo man and 2) not > > So 1) If a repo manager is declared, that url is used for all lookups > regardless of defined repos on settings or poms. Perhaps a translation > to url like Nicolas' feature is used here for repo mans/proxies that > don't provide aggregation. This should be able to be declared in a > profile to enable devs to work in an enterprise/with repo man and > without easily (currently it's a pain to switch back and forth) > > 2) This is where proxies/mirrors/repo definitions come into play. Same > as above, all should be in profiles. I think that mirroring by Id isn't > always the greatest, but I also see no harm in continuing to support it > because it can be useful in some instances. The adhoc nature of > declaring repos is annoying to be sure (I'm sure everyone has seen > apache.snapshot and apache.snapshots) but I don't currently have any > ideas how this can be handled better. > > An additional mirrorOfUrl could be added to the settings so you could > use mirrors by id or by url as you see fit. > > It would be nice to provide some automatic geo lookup but I'm not sure > how that would happen. It seems like this data needs to be stored in the > repo itself and then cached in the local repo. Otherwise someone would > have to provide a redirection service which isn't feasible for all > repos. > > > > > -----Original Message----- > From: Brett Porter [mailto:[EMAIL PROTECTED] > Sent: Sunday, March 16, 2008 7:06 PM > To: Maven Developers List > Subject: Maven's future repository support > > 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] > > -- Thanks, ~t~ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
