cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ralph Goers <Ralph.Go...@dslextreme.com>
Subject Re: svn commit: r517439 - /cocoon/trunk/core/cocoon-servlet-service/cocoon-servlet-service-impl/pom.xml
Date Tue, 13 Mar 2007 03:46:50 GMT
We should consider leveraging the new feature that I finally got 
committed into Maven - real dependency management.  With the change any 
version you specify in a dependencyManagement section will override 
versions specified in transitive dependencies as well as being the 
version used when no version is specified in a pom.  What I would 
suggest trying is having a "master" pom that everything extends. The 
master should specify all the versions to be used across all the blocks, 
unless a block has a real need to use a different version.  This will be 
available in 2.0.6.

Ralph

Grzegorz Kossakowski wrote:
> This dependency is really important. Otherwise Maven 2.0.5 will (but
> it's for sure) include all Spring's artifacts of version 2.0.3 but not
> core of which 2.0.2 version will be used at runtime. This of course
> leads to many really hard-to-track problems.
>
> What's more interesting it's not really next Maven bug. Take a look at
> this quotation[1]:
> "Dependency mediation - this determines what version of a dependency
> will be used when multiple versions of an artifact are encountered.
> Currently, Maven 2.0 only supports using the "nearest definition" which
> means that it will use the version of the closest dependency to your
> project in the tree of dependencies. You can always guarantee a version
> by declaring it explicitly in your project's POM. Note that if two
> dependency versions are at the same depth in the dependency tree it's
> not defined which one will win."
>
> Last sentence is crucial here. We depend on spring-configurator which
> depends on 2.0.2 version of spring. This dependency is overrided by
> dependencies from servlet-service-impl when it comes to all spring
> artifacts because they are one step "closer". However, core is
> referenced indirectly (by dependencies in other spring artifacts) which
> lengthen "dependency distance" by one step. Now we are in _real_ trouble
> - Maven is completely unpredictable on which version of spring's core is
> going to choose.
>
> I personally think that Maven's mechanism is not that bad as far as all
> direct dependencies are correctly specified in all poms. Even more, I
> think that eclipse plug-in generating build path which includes
> transitive dependencies is most problematic part[2].
>
> If you wonder why I've written all of this - just for your information,
> I hope this will save you from some frustration (especially if you are
> not skilled with debugging Maven).
>
>   


Mime
View raw message