A project[1] that I'm a participant in is a recent convert to Maven2 as a
build environment. So far, there's a lot to like. But ... I think I've run
into a limitation of the current design related to resolving conflicts in
dependency versions. I'm looking for advice on what I can do other than
wait for FINR ("fixed in next rev") as the "Better Builds" book implies will
be necessary :-).
The starting point for my scenario is I wanted to explore whether Commons
Logging 1.1 could successfully replace version 1.0.4 in a Shale-created
webapp. To see all the gory details, you're probably best off downloading
the sources and trying the build yourself. But the bottom line is that the
only way I can convince a particular webapp build to use the new version of
Commons Logging is to put the explicit dependence on 1.1 directly in the POM
for that webapp. This is *not* what I want -- I'd much prefer to inherit
the Commons Logging version dependency from the top-level shale POM (
org.apache.shale:shale-parent), or even from the intermediate layer I have
as a basis for all the example webapps (org.apache.shale:shale-apps-parent).
Alas, this doesn't work. Any dependency such as MyFaces that declares a
dependency on Commons Logging 1.0.4 seems to win, because it is closer on
the "nearness" algorithm described in Section 3.6 of the "Better Builds"
book.
It would seem to me that the simplest way to deal with this is that
inherited dependencies (from a parent POM) should be considered as being at
the same level of the dependency graph, just as if they had been explicitly
declared. That would always allow a project to establish priority for
shared dependencies itself, without having their builds destabilized because
inheritance and dependence are both being treated as one step down the
graph. Am I missing something? Is there some way to accomplish what I want
(with M2 2.0.4) in the mean time, without explicitly declaring this
dependency in the leaf node artifact POMs?
Craig McClanahan
[1] http://shale.apache.org/
