How best to manage project dependency versions

["Pimentel, Robert" <Ro...@tgslc.org>]

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

Re: How best to manage project dependency versions

["Lyons, Roy" <Ro...@cmegroup.com>]

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" <Ro...@tgslc.org> 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: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org