Re: Pattern to setup common organization specific data in single pom?
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 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 > >
Re: Pattern to setup common organization specific data in single pom?
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
Re: Pattern to setup common organization specific data in single pom?
There are also solutions with a maven plugin downloading and installing settings.xml. Such a plugin is included in Nexus Pro, but it shouldn't be too hard to write yourself (or is there an oss version already?). /Anders On Thu, Dec 10, 2009 at 16:35, Wayne Fay wrote: > > One way is to define a lot of properties in a settings.xml - but then the > > user has to define all these properties himself. When properties are > > changing, then we have a mess. Even worse, there is no version tracking > of > > properties using this solution. That is not good enough. > > I've heard of many organizations who check in their settings.xml file > into their SCM, making distributing and updating it pretty much dead > simple. > > Wayne > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
Re: Pattern to setup common organization specific data in single pom?
> One way is to define a lot of properties in a settings.xml - but then the > user has to define all these properties himself. When properties are > changing, then we have a mess. Even worse, there is no version tracking of > properties using this solution. That is not good enough. I've heard of many organizations who check in their settings.xml file into their SCM, making distributing and updating it pretty much dead simple. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Pattern to setup common organization specific data in single pom?
I'd say the Maven way is to keep this info/data in a corp parent. For instance, have a look how this is done at Apache: http://repo1.maven.org/maven2/org/apache/apache/6/apache-6.pom As you can see, some values are handled by properties which make them customizable by projects using this parent. You should never, never change the info in a released artifact (a corp parent pom for instance). Instead, increment the version and do the necessary changes. I see this as an advantage and not a disadvantage. If you want to make sure that all projects are using the latest and greatest corp parent, that should be possible to enforce by an appropriate rule and the enforcer plugin. /Anders On Thu, Dec 10, 2009 at 08:34, Oskar Carlstedt wrote: > > Hello? > > I wonder if there is any pattern in Maven defining how to setup common > organization specific data. What I mean is that I only want to define my > distribution management in one place, I only want to setup specific deploy > paths in one place etc., etc. > > One way is to define a lot of properties in a settings.xml - but then the > user has to define all these properties himself. When properties are > changing, then we have a mess. Even worse, there is no version tracking of > properties using this solution. That is not good enough. > > One other way would be to use a global parent. Going that way it is > possible > to inherit all common data. But the disadvantage is that I cannot change > the > values without updating the same version of the parent in the repository > (because Maven does not manage to resolve version ranges for the parent > pom). > > So, is there any other suggestions? Can I import the data using version > scopes. I like to be able to define exact versions of what I include in my > builds but when it comes to build/deploy specific data, then I would like > to > be able to change this for all users in one place. > > Any advice to solve this problem is really appreciated! > Cheers, > Oskar > > > -- > View this message in context: > http://old.nabble.com/Pattern-to-setup-common-organization-specific-data-in-single-pom--tp26723137p26723137.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 > >
Pattern to setup common organization specific data in single pom?
Hello? I wonder if there is any pattern in Maven defining how to setup common organization specific data. What I mean is that I only want to define my distribution management in one place, I only want to setup specific deploy paths in one place etc., etc. One way is to define a lot of properties in a settings.xml - but then the user has to define all these properties himself. When properties are changing, then we have a mess. Even worse, there is no version tracking of properties using this solution. That is not good enough. One other way would be to use a global parent. Going that way it is possible to inherit all common data. But the disadvantage is that I cannot change the values without updating the same version of the parent in the repository (because Maven does not manage to resolve version ranges for the parent pom). So, is there any other suggestions? Can I import the data using version scopes. I like to be able to define exact versions of what I include in my builds but when it comes to build/deploy specific data, then I would like to be able to change this for all users in one place. Any advice to solve this problem is really appreciated! Cheers, Oskar -- View this message in context: http://old.nabble.com/Pattern-to-setup-common-organization-specific-data-in-single-pom--tp26723137p26723137.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