maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Pimentel, Robert" <>
Subject How best to manage project dependency versions
Date Wed, 30 Jan 2013 21:12:50 GMT

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?

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message