maven-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brian Fox (JIRA)" <>
Subject [jira] Commented: (MNG-4457) dependency:resolve decides to take older (incompatible) version for transitive dep
Date Thu, 19 Nov 2009 20:47:55 GMT


Brian Fox commented on MNG-4457:

1) isn't true. A is using 1.3.0 by nature of declaring B as a dependency, and by declaring
1.3.0 it in it's DependencyManagement. Even though it's not a direct dependency, the fact
you have it in DepMgt says: "IF it's in my transitive hull, use THIS version." This is exactly

2)There is a message in the logs about selecting one version over another because of a "managed"
version. Maven assumes that since you asked for this version, you know it's supposed to be
used. A warning is in appropriate in this case and thus the debug message. If we printed even
an INFO everytime someone used DepMgt, that would be a mess. Again, "some deps older than
requested" is not true, 1.3.0 was requested by DepMgt in the case of A.

3)Most likely because C is also managing the dependency down to 1.3.0. Otherwise it would
pick the closest version which in this case would be 1.4.1

> dependency:resolve decides to take older (incompatible) version for transitive dep
> ----------------------------------------------------------------------------------
>                 Key: MNG-4457
>                 URL:
>             Project: Maven 2
>          Issue Type: Bug
>          Components: Artifacts and Repositories
>    Affects Versions: 2.2.1
>         Environment: WinXp
> Maven 2.0.9/2.2.1
>            Reporter: Paolo Compieta
>            Assignee: Brian Fox
>         Attachments:,
> I'll use modules Parent,ModuleA,ModuleB,ModuleEAR and dependency Commons-Net to explain
the case.
> Parent specifies commons-net/1.3.0 in dependencyManagement
> \- ModuleB declares commons-net/1.4.1 as dependency (overrides version), and resolves
correctly 1.4.1
> \- ModuleA declares ModuleB as dependency (obtaining transitive dep to commons-net),
and resolves *erroneously* 1.3.0
> \- ModuleC (ear) takes in 1.3.0 whilst no module is actually using or declaring it
> I'd expect this case to resolve 1.4.1 or at least to fail the build, because in this
example B is the only one using commons-net (maybe exploiting 1.4.1-only features), while
the final build resolves 1.3.0 (see ModuleA or ModuleC).
> I'm not 100% which is the best policy, but i've got problems (wrong jars, different behaviours
and runtime errors) with this kind silent down-resolution of version.
> Regards,
> Paolo

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see:


View raw message