Hi Craig,
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.
> 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.
> 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
- Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
