maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Lyons, Roy" <>
Subject Re: How best to manage project dependency versions
Date Wed, 30 Jan 2013 21:21:27 GMT

Is these the droids you are looking for?


Roy Lyons
Senior Configuration Engineer

On 1/30/13 3:12 PM, "Pimentel, Robert" <> wrote:

>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

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message