AndrewS, I'm not sure if I'm the one that said that on the podcast--I haven't listened to it yet to re-familiarize myself with what we talked about-- but it certainly sounds like something I would say. The rule in the enforcer plugin helps, but it still leaves a problem. As is common in large assemblies with 200+ JARs, having just 1 dependency with a version mismatch somewhere in the transitive tree is not only highly likely but > 99% guaranteed. Most of these artifacts make their way into the <dependencyManagement> section to solve the conflict after some negotiation on which version is actually the one I need, but that's a painful trial-and-error solution. It also introduces a problem where now <dependencyManagement> can list dependencies that aren't actually used anymore (i.e. I upgrade one of my dependencies that now no longer depends on one of its original dependencies and I don't know that I can now remove it from being a managed dependency).
Ideally, to me, Maven would switch from a "nearest first" dependency resolution policy to a "highest first" policy. I can't really think of a case when directly depending on 1.0 is preferred over a dependency's need for 1.2. However, given that this is not the case, and it's probably not going to change now, I think we need some additional goals/reports in the Maven plugin ecosystem to mitigate. These would be: 1. A goal/report to flag dependencies that are resolved to be an earlier version than what is needed by some dependency in the tree 2. A goal/report to flag dependencies in the tree that aren't also in the <dependencyManagement> section 3. A goal/report to flag dependencies that are in the <dependencyManagement> section but aren't actually in the dependency tree One of my interns last year developed an enhancement to the maven- dependency-plugin to address #1. Please vote/watch it if you're interested over at http://jira.codehaus.org/browse/MDEP-273. It's been stagnant for quite awhile, unfortunately, so we might have to release it internally in our company to actually get some benefit from what we developed almost a year ago! #2 helps when you want to have complete control over the dependencies in your assembly (i.e. WAR) while #3 helps you keep it clean. All three are really needed to confidently build an assembly, and unfortunately we're still a ways away from that. If there are other plugins/goals/steps that help with any of these problems I'd really like to know. -Sean -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
