Hello all of you! Thank for your replies. I've tested all strategies told here, except for using a plugin generating the settings.xml, in earlier projects. I never had the feeling feeling of hitting the big success. Maybe the plugin way will work.
I can understand all arguments for not being able to change the pom after a release, and therefore all arguments of not having a version scope on the parent pom. For me this applies to all build logic, but not for distribution management, deploy management etc., etc. This is the case where I want to be able to change some settings, not changing the build itself. Let say we change the url to our SCM, then we have to change all POMs configured using the old SCM. This mitgh be a network problem, but still such things happens. Let say I change the URL to the location of my globally published WSDL files or other resources. Then it is a must to walk through all POMs that are using that value. Ok, in booth cases above I can put expected data into the settings.xml file. I don't like this way because I think settings.xml is the user's personal file and it does not have the purpose of holding default values. Further, all settings had during a build is not checked in during a release because these vales are put in the settings.xml file. But it might be the only way to go. So having a plugin generating the most up to date settings.xml file might be a good way finding the path to the big success. Maybe we shall vote for a extra feature in the release plugin that makes it possible to checkin the current settings.xml and the full build log when doing a release. Just to get the full trace of a build. Thank you all again for your answers! Cheers, Oskar -- View this message in context: http://old.nabble.com/Pattern-to-setup-common-organization-specific-data-in-single-pom--tp26723137p26739437.html Sent from the Maven - Users mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
