Hi Matt, You may need a way for developers to override this, so they can work on old versions. Also, be carefull that your overrides to settings.xml doesn't effect vanilla maven builds -- say someone wants to build some tool they downloaded from the web.
I don't claim that this is best, but what I've done is to create three copies of settings.xml called dev.xml, staged.xml, and cert.xml to reflect the settings for the three different groups who do builds. I store these settings files separate from the maven install directories. I then created a build script which invokes maven with the -s switch passing the correct settings file. So, when a developer runs the build script, mvn -s /shared/maven_utils/2.0/dev.xml is executed. Hope this helps, Christopher Helck -----Original Message----- From: Matthew Tordoff [mailto:[EMAIL PROTECTED] Sent: Thursday, February 07, 2008 10:11 AM To: users@maven.apache.org Subject: Re: Updating M2_HOME/conf/settings.xml Hi Stefan, The reason that we don't have one master POM as a parent to all other POMs is that we have multiple different products, all under independant source control. These products may want to have differing master POMs. Also, we will be overriding the central repository location in the global settings.xml. Without the repository you won't be able to retrieve the master POM. The solution we have decided upon is to use a software distribution management tool from Symantec (LiveState) which can be used to automatically push the latest configuration for Maven directly onto developers machines (even upgrade Maven itself if necessary). This requires no manual work to be done from the developers point of view. Matt -----Original Message----- From: VUB Stefan Seidel [mailto:[EMAIL PROTECTED] Sent: 07 February 2008 13:42 To: Maven Users List Subject: Re: Updating M2_HOME/conf/settings.xml Put <maven-install-dir>/conf/settings.xml on a shared drive, or replace it with a symlink to a shared drive. Why do you need to change the settings.xml anyway? Could it not be done in a master pom that is the parent to all other poms? Then you can simply deploy the master pom and you're done. Stefan Matthew Tordoff wrote: > Hi all, > > I just wondered if anyone has any best practises for updating the global > settings.xml in Maven. I have considered checking the conf folder into SVN, > or even potentially checking the whole maven install into SVN, then when > changes are made send out an email and people can just do an SVN update to > pick up the changes. The only disadvantage of this process is that it relies > on people reading their mail and kicking off the update. I would preferably > like a method of automatically publishing changes which would automatically > update all developers machines. > > Any thoughts around this would be greatly appreciated. > > Regards, > > Matt > > P.S. I would also be interested on your views regarding checking in solely > the settings.xml file into version control, vs checking in the whole install. > > _________________________________________________________________ > Free games, great prizes - get gaming at Gamesbox. > http://www.searchgamesbox.com -- best regards, Stefan Seidel software developer ________________________ VUB Printmedia GmbH Chopinstraße 4 D-04103 Leipzig Germany tel. +49 (341) 9 60 50 07 fax. +49 (341) 9 60 50 92 mail. [EMAIL PROTECTED] web. www.vub.de HRB Köln 24015 UStID DE 122 649 251 GF Dr. Achim Preuss Neudorf, Dr. Christian Preuss Neudorf --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _________________________________________________________________ Share what Santa brought you https://www.mycooluncool.com ********************************************************************** This communication and all information (including, but not limited to, market prices/levels and data) contained therein (the "Information") is for informational purposes only, is confidential, may be legally privileged and is the intellectual property of ICAP plc and its affiliates ("ICAP") or third parties. No confidentiality or privilege is waived or lost by any mistransmission. The Information is not, and should not be construed as, an offer, bid or solicitation in relation to any financial instrument or as an official confirmation of any transaction. The Information is not warranted, including, but not limited, as to completeness, timeliness or accuracy and is subject to change without notice. ICAP assumes no liability for use or misuse of the Information. All representations and warranties are expressly disclaimed. The Information does not necessarily reflect the views of ICAP. Access to the Information by anyone else other than the recipient is unauthorized and any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it is prohibited. If you receive this message in error, please immediately delete it and all copies of it from your system, destroy any hard copies of it and notify the sender. ********************************************************************** --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
