On 11/01/2008, Simon Kitching <[EMAIL PROTECTED]> wrote: > ---- Aleksandras Skrynikovas <[EMAIL PROTECTED]> schrieb: > > Hi, I've browsed the mailing list for a solution but there doesn't > > seem to be a clear cut answer. > > > > Problem: in my app many projects depend on a single parent which uses > > dependencyManagement to keep > > module versions nice and tidy. When releasing some project with the > > release plugin, I have to update the > > version of that project in the dependencyManagement element of the > > parent pom as I understand, > > which leads to a new version of the parent itself, but how can I > > avoid having to manually increment the parent version > > in all child poms? > > > > I've read in a couple of places that the release plugin somehow > > handles this but haven't been able to find any documentation > > of explanation. If there is no pretty solution, what could be the > > most viable workaround? > > Currently, either the updates are done manually in the children, or the > maven-release-plugin is used, which just does automatically the same tasks > that could be done by hand. However the maven-release-plugin can only be used > if the children of the released parent are actually in the same directory > tree in the version control repository, and if the children are released at > the same time as the parent. > > > > I've never really understood why the dependencyManagement section is useful > at all. > > Why not just have each module declare the minimum version of a library that > *it* needs in order to compile and pass the unit tests? > > Why would you ever want to omit the version tag? That just seems to be > deliberate obfuscation.
It is important in some organizations (like where I am working now) where dependency management is not (and should not be) in the hand of the developers. The developers are handed a list of version that they should be using. If there is a clear separation of concern, it should be reflected in the code ... > When someone uses this module in another project, any library that is the > target of multiple dependencies just gets automatically resolved as the max > value of all the versioned references to it. So what version a *user* of this > module gets depends on the "global needs", but that's a different issue and > is handled fine by Maven. The pom of the original module, however, is still > being "true to itself" and honestly declaring exactly what its requirements > are. > > A pom then only ever updates its <version> reference to a dependency if it is > modified in such a way that it needs the new version. Otherwise leave it > alone. > > This then completely does away with the need to release new versions of > parent poms just in order to update dependencyManagement versions. > > If you're building a final distribution bundle for product, then that *final* > pom may choose to lock down all the dependencies to specific versions. But > that is then being done at a *leaf* of the tree, not at the *root* so changes > don't trigger cascading problems throughout the parent/child chain. > > Otherwise, what possible reason is there for requiring a tree of modules to > use the same dependency version? > > > And for plugins, IMO every plugin reference in a pom should specify the > version exactly, and maven should always provide exactly that version > (ignoring any parent). If that version of the plugin is sufficient to > correctly build the project, why would you ever want anything different? That > is just asking for trouble. App libs need dependency resolution because only > one copy can be present in the classpath of the final app. However that > constraint doesn't apply to plugins; each module can have its own private > version that suits it. > > And if dependencyManagement is not used then the parent pom only needs > updating if it adds functionality that the child actually wants, eg binding a > new plugin or adding a new report. Children that *want* that functionality > should then be updated to point to the new parent. > > Have I missed something here? [I'm not a maven newbie, but not a pro either. > Any corrections happily accepted...] > > Regards, > > Simon > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Jabber : [EMAIL PROTECTED] Skype : Guillaume.Lederrey Projects : * http://rwanda.wordpress.com/ * http://rwandatech.wordpress.com/ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
