tags:

views:

92

answers:

5

We have multiple maven projects depending on on our own common libraries.

When we upgrade a library it would be useful to quickly find out which projects have a dependency on the library (and might need to use the new version)

Obviously I can manually look in all the pom files or write a script to do it but this is less than ideal.

Are there any tools that provide this functionality. e.g. a hudson plugin, Nexus, artifactory etc?

EDIT:

Some clarifications:

I don't want to upgrade all projects at once. The regression testing and release effort makes this impractical and often unnecessary (even with automated testing and releasing). I just want a report showing me what may projects may need to have the library upgraded...

Many answers focus around the project itself flagging what version is used. Ideally the solution would work so that for a given library I can ask what uses this. This looks like what the Nexus issue below is talking about.

Hudson does something similar with automated downstream maven builds. I may look into extending this with a hudson plugin.

+2  A: 

I know that albeit being a good tool for managing poms and jars, Artifactory has no such feature you're asking :(

You might want to check this StackOverflow question: http://stackoverflow.com/questions/431332/maven-look-for-new-versions-of-dependencies

Alternatively you might want to check Versions Maven Plugin. Among other things, it allows you to scan trough project's dependencies and produce a report of those dependencies which have newer versions available.

mindas
+1  A: 

A quite usual practice is to declare all the versions in dependencyManagement of the parent module and reference dependencies without versions everywhere else. In this case you'll only need to update only one POM.

lexicore
Good advice, and if you want to go a step further, considering putting these dependencies in a "corporate pom": http://www.sonatype.com/people/2008/05/misused-maven-terms-defined/I dislike the name but the technique is pretty darn good.
whaley
We do not put version declaration to the corporate pom since we run a number of independent projects which use completely different dependencies. I generally won't agree that dependency management in corporate poms is a good practice.
lexicore
We have a corporate pom - however the problem isn't having to upgrade the dependencies in many locations. In many cases I don't want to upgrade all together. See my edit.
Pablojim
I understand now. We use dependency graphs (http://confluence.highsource.org/display/MSTP/User+Guide) for similar task. However it assumes that you have a "topmost" artifact (like a distribution) which "heads" the dependency graph.
lexicore
A: 

Not exactly what you're asking for but the Dependency Convergence report might be helpful. Here are some examples.

Update: I'm aware that I'm not exactly answering the question with my suggestion but doing it the other way (finding all projects that reference a given artifact) would require gathering all POMs of all projects and I'm not aware of a solution currently offering such a referenced by feature (a corporate repository would be the perfect candidate to implement this though).

Pascal Thivent
A: 

I solved this issue by using dependency version ranges to fetch the newest versions automatically.

  <dependency>
      <groupId>foo.xyzzy</groupId>
      <artifactId>bar</artifactId>
      <version>[1.0.0,2.0.0)</version>
  </dependency>

It might make sense to use a version range such as [1.0,) to include the newest version after 1.0.

The trick to make this work is to have dev and prod profiles that include and exclude the snapshot repos for your commons and to use hudson to automatically build projects when a dependency is re-built.

sal
I find version ranges very harmful for build stability and reproducibility and consider them as a bad practice. Having a build that suddenly starts to to fail for an unknown reason is extremely annoying, I want control on dependencies. But that's a personal opinion of course.
Pascal Thivent
@Pascal, I agree with you in general. I use them with one caveat; I set up profiles to restrict which repos are active to avoid the problem of builds _just breaking_ and I would only used them for internal components that will be published to a departmental or company wide repos. I remove the restriction when the dev profile is active.
sal
Thanks for the answer - see the edit - I don't want upgrade automatically. Some changes will be breaking changes... others will be minor where there is no reason to immediately upgrade, regression test and release all dependencies.
Pablojim
@sal Oh, I see. Adding explicitly a repository via a profile gives you some control indeed.
Pascal Thivent
A: 

My search is over: http://www.sonarsource.org/sonar-2-1-in-screenshots/

Sonar now provides this.

Pablojim