On 8/8/06, Jörg Schaible <[EMAIL PROTECTED]> wrote:
Hi Craig,
Hello Jörg
Craig McClanahan wrote on Wednesday, August 09, 2006 6:58 AM:
> 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).
If you have a depednencyManagement section in your top-level POM and add
the dep to your webapp without the version, it will work.
Agreed ... but the requirement to explicitly do this in every single webapp
is not what I want. The whole point of my apps inheriting a parent POM is
to get rid of this sort of administrivia.
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.
Point is, that you *have to* desclare the dep in the webapp, since the
algorithm for the "nearest version" would take another version from one of
your dependencies.
Why should I have to declare it in the app, when I've declared it at the
parent level? What's the point of transitive dependencies if they do not
work the way you want, and there's no way to force them to do so?
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?
Vote for it:
http://jira.codehaus.org/browse/MNG-1577
Done.
- Jörg
Craig
