server specific setting and proxy details go into settings.xml you might need to use a different proxy to deploy to a specific repo
you might need to use different server credentials.... esp if you have two different projects which have decided to use the same server-id for different servers On 27 April 2010 16:14, Thiessen, Todd (Todd) <tthies...@avaya.com> wrote: > But isn't settings.xml only related to artifacts that are downloaded, not > deployed? Deployment of artifacts to a repo I believe goes in the pom. > > > -----Original Message----- > > From: Stephen Connolly [mailto:stephen.alan.conno...@gmail.com] > > Sent: Tuesday, April 27, 2010 11:09 AM > > To: Maven Developers List > > Subject: Re: Central repository in settings.xml > > > > You can't deploy to different repos via the same repo manager though > > > > On 27 April 2010 15:43, Thiessen, Todd (Todd) > > <tthies...@avaya.com> wrote: > > > > > I think you can already do what you are asking with a repo manager. > > > > > > If you need to communicate to 3 different repos, then those repos > > > should all be controlled through the repo manager. One of the repos > > > could be public > > > (ie: like an org) and another could be private (like a com). > > > > > > Your settings.xml file would then just point to the one > > repo manager > > > which grouped the three repos into a single group. > > > > > > Nexus has a "routing" feature [1] which I believe (if I understand > > > your needs correctly) will allow you to do what your asking for. > > > > > > [1] > > > > > http://www.sonatype.com/books/nexus-book/reference/config-sect-managin > > > g-routes.html > > > > > > > -----Original Message----- > > > > From: Tim O'Brien [mailto:tobr...@discursive.com] > > > > Sent: Tuesday, April 27, 2010 10:34 AM > > > > To: Maven Developers List > > > > Subject: Re: Central repository in settings.xml > > > > > > > > Arnaud, I run into situations where one project demands a complete > > > > different settings.xml than another. Assume you have a > > book project > > > > that deals with a separate repo manager and set of > > credentials vs. a > > > > tiny codehaus project with a separate repo man vs. an internal > > > > corporate project with different settings. > > > > > > > > I can't be the only one who is constantly having to > > either pass in > > > > the -s option or just swap out default settings.xml. > > > > Has anyone given any thought to the idea of different > > settings.xml > > > > files which would be activated by groupId? > > > > Assume I had three files: > > > > > > > > A. settings.xml > > > > B. settings-org-codehaus.xml > > > > C. settings-com-example.xml > > > > > > > > The idea would be that if I were working on a project > > with a groupId > > > > matching "org.codehaus.**" Maven would interpolate A > > > > -> B, and if I were working on a project with a groupId > > > > matching "com.example.**" > > > > Maven would interpolate A -> C. > > > > > > > > That and I'm sick of having to explain mirror configuration. > > > > I wish it were as simple as > > > > "<repoman>http://localhost:8081/whatever</repoman>", but I guess > > > > this all has to wait. > > > > > > > > Ok, I take that back, I really wish it were as simple as Maven > > > > sensing the presence of a repository manager via a > > multicast ping, > > > > but I'm fully prepared for someone to tell me that this > > is the worst > > > > idea anyone has ever come up with on this list. > > > > > > > > > > > > 2010/4/27 Arnaud Héritier <aherit...@gmail.com>: > > > > > It could be better but far from perfect. Few users are reading > > > > > this file and are using it to create their own. > > > > > I think they are often copying it from the page you pointed. > > > > > There are several annoying things about settings from my > > > > point of view > > > > > but we won't be able to change before a 3.x : > > > > > - We cannot use properties in mirror url (if we want to > > > > switch between > > > > > several mirrors with different profiles) > > > > > - We don't have inheritence or mix-in capacity to share > > > > some part of > > > > > them and to split env related settings (repo, mirrors, ..) from > > > > > personal settings > > > > > (credentials) > > > > > > > > > > Arnaud Héritier > > > > > Software Factory Manager > > > > > eXo platform - http://www.exoplatform.com > > > > > --- > > > > > http://www.aheritier.net > > > > > > > > > > > > > > > On Tue, Apr 27, 2010 at 2:16 AM, Brian Fox > > > > <bri...@infinity.nu> wrote: > > > > > > > > > >> I assume you want to make it easier for people to get > > the correct > > > > >> settings? Moving it from the super pom could have > > unexpected side > > > > >> effects, but what if we put the default "boiler plate"[1] > > > > >> configuration for that into the default settings.xml > > > > commented out? I > > > > >> think this would solve the main visibility problem without > > > > affecting > > > > >> runtime. > > > > >> > > > > >> [1] > > > > >> > > > > > > http://www.sonatype.com/books/nexus-book/reference/maven-sect-single > > > > - > > > > >> group.html#ex-maven-nexus-simple > > > > >> > > > > >> On Mon, Apr 26, 2010 at 6:41 PM, Benjamin Bentmann > > > > >> <benjamin.bentm...@udo.edu> wrote: > > > > >> > Paul Gier wrote: > > > > >> > > > > > >> >> Would there be any problems if the central repo > > definition was > > > > >> >> moved out of the Maven internals and into the default > > > > settings.xml > > > > >> >> [1]? > > > > >> > > > > > >> > I assume you refer to the global settings file shipped > > > > inside the > > > > >> > Maven installation directory. The one issue I know about is > > > > >> > that embedders of Maven like M2E don't have a CLI-style > > > > >> > installation directory and hence no global settings > > file. Not > > > > >> > impossible to solve but it needs to be > > > > >> considered. > > > > >> > > > > > >> > > > > > >> > Benjamin > > > > >> > > > > > >> > > > > > > > ------------------------------------------------------------------- > > > > >> > -- To unsubscribe, e-mail: > > dev-unsubscr...@maven.apache.org For > > > > >> > additional commands, e-mail: dev-h...@maven.apache.org > > > > >> > > > > > >> > > > > > >> > > > > >> > > > > > > -------------------------------------------------------------------- > > > > - > > > > >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For > > > > >> additional commands, e-mail: dev-h...@maven.apache.org > > > > >> > > > > >> > > > > > > > > > > > > > > > -------------------------------------------------------------------- > > > > - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For > > > > additional commands, e-mail: dev-h...@maven.apache.org > > > > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For > > > additional commands, e-mail: dev-h...@maven.apache.org > > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
