You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by "sean.chen(陈思淼)" <ch...@gmail.com> on 2008/11/17 13:41:35 UTC
why maven determine to adopt "nearest definition" to resolve the dependcy conflicts?
In our enterprise project, we are care about the version change of the
dependency, sometimes our EAR project fail in the production environment
just because of a new version of dependency have be adopted. the version
change just because someone add a new transitive dependency which has the
"shortest path" to the dependency tree root. and in this situation, we
didn't know anything about the final EAR changes.
I am question why maven determine to adopt "nearest definition" to
resolve the dependcy conflicts, can it config it just throw a exception with
enough information, and we can specific write the version of dependency in
the < dependencyManagement > section.
Re: why maven determine to adopt "nearest definition" to resolve the dependcy conflicts?
Posted by "sean.chen(陈思淼)" <ch...@gmail.com>.
Actually I will write a plugin to do such kind of thing, of cause i will
create a "ignore list" which contains such as "log4j, commons-logging" we
dont care about, the list will be increased with new ingore item add to it.then
I will find all the conflict dependency that dont list in the
<dependencyManagement> Tag, and throw a exception with full infomations to
tell people to manually add it into the dependencyManagement,.
2008/11/17 Geoffrey Wiseman <ge...@gmail.com>
> On Mon, Nov 17, 2008 at 7:47 AM, David Delbecq <de...@oma.be> wrote:
>
> > This might be what you'r looking for:
> >
> >
> http://maven.apache.org/plugins/maven-dependency-plugin/analyze-mojo.html
> >
>
> Huh - are you suggesting that dependency:analyze will also warn you if,
> say,
> one dependency's POM declares that it works with commons-collections 1.1.4
> and another's requires commons-collections 1.2.3?
>
> I don't remember that when I briefly looked at it, but that'd be
> interesting
> to discover.
> - Geoffrey
> --
> Geoffrey Wiseman
>
Re: why maven determine to adopt "nearest definition" to resolve the dependcy conflicts?
Posted by Geoffrey Wiseman <ge...@gmail.com>.
On Mon, Nov 17, 2008 at 7:47 AM, David Delbecq <de...@oma.be> wrote:
> This might be what you'r looking for:
>
> http://maven.apache.org/plugins/maven-dependency-plugin/analyze-mojo.html
>
Huh - are you suggesting that dependency:analyze will also warn you if, say,
one dependency's POM declares that it works with commons-collections 1.1.4
and another's requires commons-collections 1.2.3?
I don't remember that when I briefly looked at it, but that'd be interesting
to discover.
- Geoffrey
--
Geoffrey Wiseman
Re: why maven determine to adopt "nearest definition" to resolve
the dependcy conflicts?
Posted by David Delbecq <de...@oma.be>.
En l'instant précis du 17/11/08 13:41, sean.chen(陈思淼) s'exprimait en
ces termes:
> In our enterprise project, we are care about the version change of the
> dependency, sometimes our EAR project fail in the production environment
> just because of a new version of dependency have be adopted. the version
> change just because someone add a new transitive dependency which has the
> "shortest path" to the dependency tree root. and in this situation, we
> didn't know anything about the final EAR changes.
> I am question why maven determine to adopt "nearest definition" to
> resolve the dependcy conflicts, can it config it just throw a exception with
> enough information, and we can specific write the version of dependency in
> the < dependencyManagement > section.
>
>
This might be what you'r looking for:
http://maven.apache.org/plugins/maven-dependency-plugin/analyze-mojo.html
--
David Delbecq
ICT
Institut Royal Météorologique
Ext:557
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org