Just to be clear, when you say "version scope" do you mean version range?
What you could do is to use a property for some elements in your pom. The default value is defined in the pom through defining the property. It is then possible for each user to override this, either through their settings.xml or the command line. Have a look at the Apache parent pom I linked to earlier: http://repo2.maven.org/maven2/org/apache/apache/6/apache-6.pom In that pom this technique is used for the url of the snapshot repo of their distribution management. However, I agree that there are some elements of the pom that one could think shouldn't be "locked down" for a release. However, often there's a wider concept like with the scm part. The scm info in the pom of a release artifact can be used to retrieve that exact project. Very useful for open source projects where a lot of people are interested in quickly getting them. The benefit of not having to trying to find this info on the home page is not to ignore. So, do change them! :-) Or, at least make sure that the old url continue to work for released artifacts (the importance of this depends on the size of your audience). Regarding having to "walk through all POMs that are using that value" I'd argue that the benefit of having the value defined in a parent pom means you don't have to traverse every pom updating the old value. As you clearly understand the concepts I think I'm missing something to the story here... Regarding the settings.xml it would be very interesting to hear about some success story using the global settings.xml for corp wide stuff and the personal one just for passwords etc. How do you go about doing this in an agile, lightweight way? As the global settings.xml is part of the Maven installation, it will be replaced whenever a new Maven version is installed. This would either require a centrally re-package Maven bin or some tool for always keeping this file updated. I have always kept away from the global one for these reason. Any best-practice solution anyone can share? /Anders On Fri, Dec 11, 2009 at 07:46, Oskar Carlstedt <oskar.carlst...@gmail.com>wrote: > > 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 > >
