Details
-
Bug
-
Status: Closed
-
Major
-
Resolution: Not A Bug
-
2.2.1
-
None
-
None
-
WinXp
Maven 2.0.9/2.2.1
Description
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
Attachments
Attachments
Issue Links
- is related to
-
MNG-1577 dependencyManagement does not work for transitive dependencies
- Reopened