Hi Peter, Peter Horlock wrote: > 2008/7/3 Jörg Schaible <[EMAIL PROTECTED]>: > >> Sorry, but our priority is to ensure that all artifacts are built >> with the same plugins and use the same artifact versions. In your >> model I have to duplicate all the versions for your individual >> service parents. That's what I call an anti-pattern. No, thanks, >> we've already bitten enough by that. > > > I am not sure if I properly got your point, but I also think > that using > version ranges and no proper dep. mgmt will lead to using different > submodule version in the same project. We had that with Maven 1, and > wasn't that one of the main reasons for Maven 2? The dep mgmt makes > using dep. more > strict - it allows you to exactly nail down one version all other sub > modules are sharing among each other - if, in the rare case, > that there is a > sub project that does need to violate this rule and has to > use an older / > newer version of a dep., you may do so by overiding its > version number. > > Not sure if I got it right, but imho that was Michaels point, > using version > ranges and so...
Since M206 the depMgmnt will overwrite even the versions of transitive deps. If I really want to use a different version in a project, I can add either directly a version to the dependency or introduce another depMgmnt section in the POM hierarchy that overwrites the inherited version of the global master. The latter is what we do with an individual parent POM for a complete project that inherits also our global master. We originally also used only released versions but switched to SNAPSHOTs later on. However, we did not use ranges, therefore we also had to change always to a new parent after a release. With Michael's version range approach you can avoid this at least for compatible releases. IMHO you will have to find the development model that fits best your way of working. If you look at the Maven source, they use again a different approach. Therefore take your time and play with some scenarios using the different approaches. - Jörg --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
