Different server credentials is not a problem since you just associate each cred with an ID. Unless for some reason you are defining a single repository ID for multiple deployment URLs.
Multiple proxies would require separate settings, but I wouldn't think this is a common use case. If it is common, I guess proxies should be put into profiles. Stephen Connolly wrote: > 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 >> >> > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
