Hi Bernd,
But what difference does it make if two modules use different versions
of commons-logging, as long as each passes its unit tests?
For any module, its external dependencies may well be using libraries
that the module also uses directly, and in that case the module has
absolutely no control over what they say in their poms. Nevertheless, it
all works fine. So why should the approach to managing versions suddenly
change just because modules happen to exist in the same directory tree?
=== for plugin dependencies
Parent P1
Child C1 uses plugin foo version 1.0
Child C2 uses plugin foo version 1.1
Now if C1 and C2 both build fine, pass all their unit tests, etc. then
why does it matter *at all* that they use different versions of the
plugin?
And if changes are made to C2 which trigger a plugin bug, or need a
feature of a newer version of the plugin, then C2 has to be upgraded to
use plugin foo 1.2. But why on earth would you want to simultaneously
force C1 to upgrade when it is working perfectly fine as it is?
=== for library dependencies
Parent P1
Child C1 declares a dependency on foo 1.0
Child C2 declares a dependency on foo 1.1
If C1 correctly compiles and correctly runs, and C2 correctly compiles
and correctly runs, then what difference does it make that they declare
dependencies on different versions?
When some external app E1 has a dependency on C1, C2, and directly on
foo 1.2 then at runtime what is used is actually different from any
version that C1 or C2 explicitly declares.
In short, the version is only a "preferred" version as far as users of
that module is concerned.
It *is* important to have a specific version, so that compiling the
source code ends up with the same binary output each time rather than
being affected by what happens to be in the local m2 repo of the user
who built it.
But I still fail to see any benefits in synchronizing versions across a
set of modules when in actual use other versions will probably be used
anyway.
=====
You say below that when the dependencyManagement is not defined, then
the version of a lib used is defined "by the nearest pom". But what I am
recommending is that *every* dependency declaration *always* has a
version number. So this never happens.
The only time this problem (unclear dependencies) occurs is when your
approach is used (dependencyManagement in parent, no version in child)
then someone screws up by not putting a version on something that does
NOT have a dependencyManagement in the parent. That's quite an easy
mistake to make, though.
If every dependency has a version tag, then it is easy to spot mistakes
where they have been left out. If some are allowed to "inherit" stuff
from the parent it is much less easy to spot.
BTW, there is a maven plugin currently in development called
maven-enforcer-plugin that will hopefully spot "uncontrolled
dependencies" and fail the build. I look forward to trying that out when
it is released..
Regards,
Simon
BTW: I hate top-posting....
On Tue, 2008-01-22 at 17:40 +0100, Bernd Bohmann wrote:
> Hello Simon,
>
> I think a multi module project should define the common configuration of
> plugins and dependencies in the management section.
>
> For example: If you define different versions of the commons-logging
> api. The dependency mechanism is not using the most recent version of
> commons-logging, maven resolves to the version of the dependency from
> the nearest pom. (
>
>
> Simon Kitching schrieb:
> > ---- Bernd Bohmann <[EMAIL PROTECTED]> schrieb:
> >>
> >> Simon Kitching schrieb:
> >>
> >>> Yes, the above approach will work. But it is worrying to look at a pom
> >>> and see something without a version attached. It requires work to confirm
> >>> that this is valid (ie that a parent does define a version). And it sets
> >>> a bad example for other people; I have just been through all the poms and
> >>> cleaned up *many* cases where plugins and dependencies were being used
> >>> without any version being declared anywhere.
> >>>
> >>> The supposed advantage of declaring the version in a parent pom is that
> >>> all the children can be "pushed" to a new version at once. But in fact
> >>> that is not true, because this requires (a) a new version of the parent
> >>> to be released, then (b) every child be updated to use the new parent.
> >>> Ok, it does work a little better during SNAPSHOT cycles, where a modified
> >>> parent gets picked up automatically.
> >>>
> >>> But there is no great advantage in having all child modules using the
> >>> same plugin version anyway. If a module works with version X of a plugin,
> >>> then why move to a different one? That just risks breakage of that module
> >>> for no gain, as it worked fine before with the old one.
> >>>
> >> I think everybody should use pluginManagement and dependencyManagement
> >> in a multi module maven project.
> >
> > A few reasons would be helpful Bernd :-)
> >
> > Why do you think pluginManagement/dependencyManagement is better? What are
> > the errors in my statements above?
> >
> > Regards,
> > Simon
> >
