[
http://jira.codehaus.org/browse/MNG-4457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paolo Compieta reopened MNG-4457:
---------------------------------
I agree with MNG-1577, but there are a few differences here, so i'm kindly
asking more clarifications.
1) *no one* is using 1.3.0 in the build, but Maven resolves 1.3.0 -could we
point this out during the build or better manage this case?
2) Maven chooses the *older* version (not a newer one) while B is declaring a
*direct dep* with an *explicit,newer* version -could we could point this out
with a short message? [also a short hint in the dep resolution phase would be
ok: "some deps older than requested"]
3) why is A's-transitive-older-managed-dep winning over B's direct-dep? Is this
right?
Regarding point 3), i could agree if there were (another) ModuleD with
direct-dep inheriting version 1.3.0 from parent: in this case, resolving 1.3.0
instead of 1.4.1 would be fair (see attached example).
> dependency:resolve decides to take older (incompatible) version for
> transitive dep
> ----------------------------------------------------------------------------------
>
> Key: MNG-4457
> URL: http://jira.codehaus.org/browse/MNG-4457
> 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: m2FairTransitiveDepResolve.zip,
> m2WrongTransitiveDepResolve.zip
>
>
> 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:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
