I have the following dependency hierarcy on a project managed by maven
At runtime, the version picked by maven is 1.5.5. This is because it uses the nearest child strategy by default to pick the winner during a conflict. This creates the following error when I instantiate my spring bean on the server
<Truncated class names so we can focus on the problem>
org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'Blah' defined in class path resource [applicationContext.xml]: Instantiation of bean failed; nested exception is org.springframework.beans.BeanInstantiationException: Could not instantiate bean class [dao.Blah]: Constructor threw exception; nested exception is java.lang.NoClassDefFoundError: org/codehaus/jackson/map/Module
To avoid the error, I overrode the version on my webApp's pom.xml using the following configuration fragment.
I have 2 questions
1. Would you suggest this approach to resolve the conflict ? I do not have control over the jackson-core versions mentioned on Library X or jersey, so this seemed like a good choice.
2. Why would maven pick the nearest-version-to-the-root approach over the newest-version-of-a-jar approach by default ? As long as the major version of the jars are the same, should maven not pick that instead ? That seems to make more sense.