Is these the droids you are looking for? http://mojo.codehaus.org/versions-maven-plugin/examples/advancing-dependenc y-versions.html
http://mojo.codehaus.org/versions-maven-plugin/examples/update-parent.html Thanks, Roy Lyons Senior Configuration Engineer On 1/30/13 3:12 PM, "Pimentel, Robert" <[email protected]> wrote: >Hi, > >Historically we've had a lot of trouble getting our developers to adhere >to our company's stated best practices. For example, we want all projects >to depend upon the latest version of other projects (unless they have a >valid reason not to). Typically our developers will only update the >dependency version for the projects they are changing, or someone on >their project team is changing. They will not look at the full list of >projects that are changing as part of the release. Consequently, many >projects get compiled against one version of a project, but at run-time >they use the latest version of that project. This usually doesn't cause >problems, but can. > >We audit the versions just prior to releasing them. Sometimes when we >change the dependency version to the latest value, the project fails to >compile. One reason is because the code is referencing non-existent code >(no longer in newer version). We are usually up against it at this point >because of our inefficient approach to releasing artifacts, so instead of >chasing down the developer to fix it, we keep the dependency at the older >version. Usually this isn't a problem because, even though the old code >is required at compile time, it is never invoked (called) at run-time, so >that application doesn't blow up. It will be a problem one day, and I am >trying to prevent that from happening. > >Our approach to this problem has been to take the responsibility out of >the developers' hands. We've implemented a bunch of properties (using >groupid.artifactid-[dev/prod]-version naming convention) in our >organization POM, and set the values there. We then replaced the >hard-coded values in each of the project pom files with the appropriate >-dev or -prod property. So essentially, we can change the version for >each project that is used as a dependency from a single location. Another >reason we opted for this approach is because it simplifies the release >process for us. We simply validate that the property values have the >correct values for this release in one place (org pom), and then we >update the project pom files by replacing -dev for -prod prior to >releasing them. > >This introduces its own set of problems. For example, every project >references a particular version (2.0) of our organization POM as its >parent. When we update the values for one or more of these properties (in >preparation for release) in the org POM, we can either (a) leave the >version of the org pom the same (2.0) or (b) increment the version (2.1, >2.2, 2.3, etc.). Option 'a' seems problematic because I believe >developers will not automatically pull down the latest version of org pom >2.0 since it is supposed to be immutable. They'll need to purge it from >their local repository after each release, or update the pom.xml (pull >down latest changes from SVN), and run make install against it. Option >'b' is good because developers would automatically pull down the newer >version of the org pom when they ran a build on any of the projects >referencing it. The tradeoff is that we would have to update X project >pom files to refer to the new version of the org pom. X is sometimes 20 >or 30. It would be more manageable if we could use a property for the org >pom version, but I am not sure we could define that property in the org >pom...seems like a chicken and egg problem. I wonder if there is a >plug-in that allows maven to check for the latest version of an artifact >if the version is omitted. > >Can you please share what is considered the best practice approach for >this? >Thanks, >Rob > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
