3

I love the maven-versions-plugin but sometimes I forget to run it for a while. Is there a way to make a maven build fail (and thus have a continuous build fail) when certain important dependencies are out of date?

Community
  • 1
  • 1
Craig P. Motlin
  • 26,452
  • 17
  • 99
  • 126

2 Answers2

0

I think you're approaching this incorrectly. Mail yourself the output of the maven-versions-plugin if you want, but don't fail the build due to changes outside of your control.

Even more, why would you want to needlessly update to the latest versions? I have seen many tricky problems appear due to upgrades which have brought slight changes to previous behaviour.

Robert Munteanu
  • 67,031
  • 36
  • 206
  • 278
  • By "important dependencies" I mean jars developed by other teams in my company. I ought to upgrade as soon as new versions are available. If there are problems, the other team ought to know quickly. – Craig P. Motlin Dec 10 '10 at 18:27
  • I don't to read an email every day with no differences. I want an alert that only occurs when there are new jars. I wouldn't be failing THE build, I'd be failing A build. No big deal. – Craig P. Motlin Dec 10 '10 at 18:28
  • Have you considered using version ranges? – Robert Munteanu Dec 10 '10 at 22:24
  • Version ranges will cause compilation and tests to fail when new versions come out. I want to immediately know when new versions are out, but still update by hand. That way I can still check out any revision and it will build. – Craig P. Motlin Dec 18 '10 at 06:46
-1

This, in general, is a bad practice - to update versions automatically. There is no practical reason of using the latest version of any package. If the library you're using satisfies your requirements you should stay with this version for security/stability reasons. And forever.

I think that maven-versions-plugin is an anti-pattern itself.

ps. When and if you want to do integration testing of modules developed by different teams/programmers, it is "integration testing". Even in this case I still think that on-fly version updating is the wrong approach. Root project should not do this integration testing, instead, every sub-module (or JAR, in your case), has to be responsible for integration testing of itself together with the rest of the system. When a sub-module increases its version it has to validate whether everything is still fine, and only then has to release a new version to the repository. And when the sub-module is doing the validation it has to be dependent on statically specified version numbers.

yegor256
  • 102,010
  • 123
  • 446
  • 597
  • See the comments on the other answer. – Craig P. Motlin Dec 18 '10 at 06:43
  • I do specify all version numbers statically. That's why I need to set up a second, separate build which will alert me when I need to update dependencies by hand, hopefully on the same day. – Craig P. Motlin Dec 19 '10 at 07:15
  • @Craig Right, but the question is - why do you need to update versions? What is the reason? Just to update? Why spending time/effort for this operation? If the project works why making changes to it? It is more a question of SDLC than of Maven :) Sorry, if I confused you with my answer – yegor256 Dec 19 '10 at 08:56
  • @Vincenzo I develop libraries and frameworks so I want to update quickly for two reasons. First, if I don't upgrade, other teams in my company who depend on my library can't upgrade either. Second, being a library developer puts me in a good position to report back to other teams that develop libraries internally and let them know if there are any problems during integration. – Craig P. Motlin Dec 20 '10 at 14:53
  • @Craig What you're explaining is a good sign of incorrect SDLC organization. Version upgrade should happen when a downlink (user of your library) **needs** certain particular new feature from an uplink (your library). And it should never happen for the sake of sanity check ("Are we still OK with latest versions?"). Mostly because such a sanity check has nobody responsible for problems. If a problem is detected during the sanity check procedure we don't know who should fix it. Lack of explicit responsibility is a clear indicator of SDLC flaw. – yegor256 Dec 21 '10 at 11:26
  • @Vincenzo Many projects in my firm depend on our libraries, so any time we don't upgrade, we inevitably prevent the entire firm from upgrading (through transitive dependencies). It's also an extremely common request. Plus it's part of the explicit mandate of the team which makes sense since we're a core team. We get ahead of these requests by integrating early so that when people request new features, they're never held back on old versions of anything. Hence we really do use the maven-versions-plugin like once a week. If there's no answer, I'll have to write a new maven plugin. – Craig P. Motlin Dec 21 '10 at 13:39