java.lang.NoClassDefFoundError: org/codehaus/jackson/map/Module

[Deepak Bala]

I have the following dependency hierarcy on a project managed by maven

WebApp 
|
|
-> Project B -> Library X -> jackson-core-asl 1.9.2
|
|
|
-> jersey-json 1.4 -> jackson-core-asl 1.5.5

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
org.springframework.beans.factory.support.ConstructorResolver.autowireConstructor(ConstructorResolver.java:288)
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.autowireConstructor(AbstractAutowireCapableBeanFactory.java:1003)

To avoid the error, I overrode the version on my webApp's pom.xml using the following configuration fragment.

  <dependencyManagement>
  	<dependencies>
  		<dependency>
  			<groupId>org.codehaus.jackson</groupId>
  			<artifactId>jackson-mapper-asl</artifactId>
  			<version>1.9.2</version>
  		</dependency>
  		<dependency>
  			<groupId>org.codehaus.jackson</groupId>
  			<artifactId>jackson-core-asl</artifactId>
  			<version>1.9.2</version>
  		</dependency>
  	</dependencies>
  </dependencyManagement>

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.