We Keep Coding

How can I remove the old vulnerable Apache commons collection version dependency from my project's maven dependency tree?

My Java app project is being managed by Maven.
My project has a few library dependencies depending again on Apache commons collection 3.2.1 which is vulnerable - e.g. Apache commons configuration, velocity, etc.
(I can see it is being used by running mvn dependency:tree command.)
I did neither write any line of codes using Apache commons collection directly nor defined the dependency of it, but it's being used.
What could I do to remove its dependency and to force to use safe version - 3.2.2, 4.1.
For your information:
JIRA Bug - Arbitrary remote code execution with InvokerTransformer
Here is the part of my pom.xml, and I guess there's nothing remarkable.
...
<dependency>
<groupId>commons-configuration</groupId>
<artifactId>commons-configuration</artifactId>
<version>1.6</version>
</dependency>
<dependency>
<groupId>org.apache.velocity</groupId>
<artifactId>velocity</artifactId>
<version>1.7</version>
</dependency>
...

Unless I am missing something obvious, just specifying dependency in your POM ought to be sufficient:
<dependencies>
<dependency>
<groupId>commons-collections</groupId>
<artifactId>commons-collections</artifactId>
<version>3.2.2</version>
<dependency>
...
</dependencies>
If you specify it a the top of your <dependencies> section, it will override any other transitive inclusion of commons-collections.
Of course, you may wind up with incompatibilities where other dependencies depend on the other version, but that's what unit tests are for, right? ;-)

What you need to do is exclude commons-collections from the affected dependencies and include the desired version in your dependencies directly.
Example pom.xml excerpt assuming commons-configuration uses the vulnerable commons-collections
<dependency>
<groupId>commons-configuration</groupId>
<artifactId>commons-configuration</artifactId>
<version>1.10</version>
<exclusions>
<exclusion>
<artifactId>commons-collections</artifactId>
<groupId>commons-collections</groupId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>commons-collections</groupId>
<artifactId>commons-collections</artifactId>
<version>3.2.2</version>
<scope>runtime</scope>
</dependency>
For simplicity I didn't show configuring this in a root pom.xml in the dependency-management section.
The <scope> should be set to runtime since you mentioned not using the library directly.

I've added these lines in my pom.xml, but still commons-collections3.2 is getting downloaded..
<dependencies>
<dependency>
<groupId>org.apache.commons</groupId>
<artifactId>commons-collections4</artifactId>
<version>4.1</version>
</dependency>
<dependency>
<groupId>org.apache.commons</groupId>
<artifactId>commons-lang3</artifactId>
<version>${apachecommonslang.version}</version>
<exclusions>
<exclusion>
<artifactId>commons-collections</artifactId>
<groupId>commons-collections</groupId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>commons-dbcp</groupId>
<artifactId>commons-dbcp</artifactId>
<version>${dbcp.version}</version>
<exclusions>
<exclusion>
<artifactId>commons-collections</artifactId>
<groupId>commons-collections</groupId>
</exclusion>
</exclusions>
</dependency>

Error deploying plugin to jira

I'm trying to deploy my custom plugin to jira and then the error occurs:
java.lang.ClassCastException: org.apache.xerces.jaxp.datatype.DatatypeFactoryImpl cannot be cast to javax.xml.datatype.DatatypeFactory
The project is build with Maven and if I remove and exclude every
<exclusion>
<groupId>javax.xml.bind</groupId>
<artifactId>jaxb-api</artifactId>
</exclusion>
<exclusion>
<groupId>javax.xml.bind</groupId>
<artifactId>jaxb-impl</artifactId>
</exclusion>
<exclusion>
<groupId>com.sun.xml.bind</groupId>
<artifactId>jaxb-impl</artifactId>
</exclusion>
<exclusion>
<groupId>com.sun.xml.bind</groupId>
<artifactId>jaxb-api</artifactId>
</exclusion>
<exclusion>
<groupId>xerces</groupId>
<artifactId>xercesImpl</artifactId>
</exclusion>
dependency
// I just paniced :)
logs inform about ClassNotFoundException
I have no idea what to do, so can anybody help?

Actually, I have no idea why this bug occured, but I rolled back and reconfigured all my pom files, and I believe that the issue was in incorrect api dependency. It concerns QuickBooks API v3, and now it works fine with
<dependency>
<groupId>com.intuit.code.devkit.v3</groupId>
<artifactId>ipp-v3-java-devkit</artifactId>
<version>2.3.2</version>
<scope>compile</scope>
</dependency>
And, probably, the problem was in one one these dependencies
<dependency>
<groupId>com.intuit</groupId>
<artifactId>ipp-java-devkit</artifactId>
<version>2.0.13</version>
</dependency>
<dependency>
<groupId>com.intuit.code.devkit</groupId>
<artifactId>ipp-java-qbhelper</artifactId>
<version>1.1.0</version>
</dependency>

How to Overcome Spring and Jbehave Versioning Problem?

In our project we are using Spring 3.0.0.RELEASE, and now we are trying to add JBehave to our project.
Here the problem is JBehave latest 3.4.5(Release) version uses Spring 2.5.6 (spring-context, spring-test).
then we got problem in dependencies in maven.
is there any solution to continue our project with Spring version 3.0 and Jbehave Spring version 2.5.6 without any conflicts?

JBehave will probably also work with Spring 3.0. You could simply try to exclude the transitive dependency from JBehave. I didn't test this but it should look similar to this:
<dependencyManagement>
<dependencies>
...
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-core</artifactId>
<version>3.0</version>
<scope>compile</scope>
</dependency>
...
<dependency>
<groupId>org.jbehave</groupId>
<artifactId>jbehave</artifactId>
<version>3.4.5</version>
<scope>test</scope>
<exclusions>
<exclusion>
<groupId>org.springframework</groupId>
<artifactId>spring-context</artifactId>
</exclusion>
<exclusion>
<groupId>org.springframework</groupId>
<artifactId>spring-test</artifactId>
</exclusion>
</exclusions>
</dependency>
....
</dependencies>
</dependencyManagement>

Jackson ObjectMapper() constructor throws NoSuchMethod

I'm using Jackson sample code to deserialize a POJO:
ObjectMapper m = new ObjectMapper();
This line throws a NoSuchMethodError:
Exception in thread "main" java.lang.NoSuchMethodError: org.codehaus.jackson.type.JavaType.<init>(Ljava/lang/Class;)V
at org.codehaus.jackson.map.type.TypeBase.<init>(TypeBase.java:15)
at org.codehaus.jackson.map.type.SimpleType.<init>(SimpleType.java:45)
at org.codehaus.jackson.map.type.SimpleType.<init>(SimpleType.java:40)
at org.codehaus.jackson.map.type.TypeBindings.<clinit>(TypeBindings.java:18)
at org.codehaus.jackson.map.type.TypeFactory._fromType(TypeFactory.java:525)
at org.codehaus.jackson.map.type.TypeFactory.type(TypeFactory.java:61)
at org.codehaus.jackson.map.ObjectMapper.<clinit>(ObjectMapper.java:179)
at com.me.util.ctrl.BillingJobStatus.fromJson(BillingJobStatus.java:37)
I don't get it

I'm guessing your Jackson JARs are out of sync. The JavaType class is in the jackson-core JAR, and the ObjectMapper class is in jackson-mapper.
Make sure these are both of the same version.

I had this same problem. The core jar was 1.7.1 while the mapper was 1.8.1. Note: To fix this for maven I added an exclusion and pulled down the proper version.
<exclusions>
<exclusion>
<groupId>org.codehaus.jackson</groupId>
<artifactId>jackson-mapper-asl</artifactId>
</exclusion>
</exclusions>

The trick here is to exclude jackson from the dependencies that use it.
To check which dependencies import it, you can use the following maven command:
mvn dependency:tree -Dincludes=org.codehaus.jackson

In my case it was due to yammer-metrics library including an older version of jackson.
<dependency>
<groupId>com.yammer.metrics</groupId>
<artifactId>metrics-servlet</artifactId>
<version>2.1.2</version>
<exclusions>
<exclusion>
<groupId>org.codehaus.jackson</groupId>
<artifactId>jackson-mapper-asl</artifactId>
</exclusion>
</exclusions>
</dependency>

In my case it was the amazonaws sdk that caused this. Using just the exclusion for jackson-mapper-asl didn't work but using an exclusion for core and mapper did:
<dependency>
<groupId>com.amazonaws</groupId>
<artifactId>aws-java-sdk</artifactId>
<version>1.3.13</version>
<exclusions>
<exclusion>
<groupId>org.codehaus.jackson</groupId>
<artifactId>jackson-core-asl</artifactId>
</exclusion>
<exclusion>
<groupId>org.codehaus.jackson</groupId>
<artifactId>jackson-mapper-asl</artifactId>
</exclusion>
</exclusions>
</dependency>

While working on Hadoop, I eliminated this error by setting the following exclusions
<dependency>
<groupId>org.apache.hadoop</groupId>
<artifactId>hadoop-core</artifactId>
<version>1.0.1</version>
<exclusions>
<exclusion>
<groupId>org.codehaus.jackson</groupId>
<artifactId>jackson-mapper-asl</artifactId>
</exclusion>
</exclusions>
</dependency>

it is beacuse of #RequestBody use different jars for different spring versions :
if using spring 4 than have to add different jars :
<dependency>
<groupId>com.fasterxml.jackson.core</groupId>
<artifactId>jackson-core</artifactId>
<version>2.4.3</version>
</dependency>
<dependency>
<groupId>com.fasterxml.jackson.core</groupId>
<artifactId>jackson-databind</artifactId>
<version>2.4.3</version>
</dependency>
if using spring 3 have to use this jar :
<dependency>
<groupId>org.codehaus.jackson</groupId>
<artifactId>jackson-mapper-asl</artifactId>
<version>1.5.0</version>
</dependency>

Yes, anyone who is facing this issue, he should definetely investigate the dependencies with
mvn dependency:tree -Dincludes=org.codehaus.jackson
In my case, I had a jackson dependency on Atmosphere-Socket-io :
<dependency>
<groupId>org.atmosphere</groupId>
<artifactId>atmosphere-socketio</artifactId>
<version>2.2.1</version>
<exclusions>
<exclusion>
<groupId>org.codehaus.jackson</groupId>
<artifactId>jackson-mapper-lgpl</artifactId>
</exclusion>
<exclusion>
<groupId>org.codehaus.jackson</groupId>
<artifactId>jackson-core-lgpl</artifactId>
</exclusion>
</exclusions>
</dependency>
It took me several hours to track that down, thank you all guys for the above solutions which inspired me! Keep up the good work!

I have faced this problem when migrating my WebApp from Tomcat 6 to Tomcat 8.
On Tomcat6 and Tomcat7 my WebApp would start just fine, but on Tomcat8 I would get this exception(seems that T6 and T7 loads classes alphabeticaly but T8 doesn't - https://stackoverflow.com/a/26642798/1864614).
The problem was that I was having 2 versions of the class org.codehaus.jackson.map.ObjectMapper
As answered by #wild_nothing I have checked dependency the tree to list all dependencies on org.codehaus.jackson
In my case the problem was that I had several versions of libraries that provided this class:
org.codehaus.jackson:jackson-mapper-lgpl:jar:1.5.0
org.codehaus.jackson:jackson-core-lgpl:jar:1.5.0
org.codehaus.jackson:jackson-mapper-asl:jar:1.8.2
org.codehaus.jackson:jackson-core-asl:jar:1.8.2
My solution was to exclude the older versions(1.5.0) and only leave the 1.8.2 version
<dependency>
<groupId>cfm.foo</groupId>
<artifactId>jive</artifactId>
<exclusions>
<exclusion>
<groupId>org.codehaus.jackson</groupId>
<artifactId>jackson-core-lgpl</artifactId>
</exclusion>
<exclusion>
<groupId>org.codehaus.jackson</groupId>
<artifactId>jackson-mapper-lgpl</artifactId>
</exclusion>
</exclusions>
</dependency>
in this case jive was depending on older 1.5.0 version

Java - getting jar dependencies right

I'm relatively new to Java & maven, and so to get to know my way around, I decided to do a project as a means for learning.
I picked a pretty common stack :
Java 1.6
Hibernate (with annotations)
Spring (with annotations)
JUnit 4
Tomcat
Oracle XE / In-mem hsqldb
By far one of the biggest problems I've experienced is getting the correct combination of jar versions to get a stable environment. It's an issue I'm still fighting with over two months later.
Quite often I get noSuchMethod or classNotFound exceptions thrown, and it turns out to be that Spring module A x.x.x is not compatible with Hibernate module B y.y.y. Or even, just as commonly, spring module A x.x.x is not compatible with spring module B y.y.y
I expected in starting from a clean slate, version dependencies should be minimal -- just grab the latest version and everything should work... but that has not been the case.
I expected that using maven would simplify this process, and no doubt it has.
But it's certainly be far from painless. I'd have thought that if module A requires a specific version of module B, that it be enforced somewhere along the line, and certinaly provide more meaningful messages that just "noSuchMethod".
Additionally, it seems that the only way I discover these problems is to try a new method call, get the dreaded noSuchMethod error, and start googling.
Have I missed something along the way here that has made this more difficult on myself than it needed to be?
For reference, here's the dependencies section of my pom...if you notice anything horrendously non-standard, please let me know!
<dependencies>
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-api</artifactId>
<version>1.5.6</version>
</dependency>
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-log4j12</artifactId>
<version>1.5.6</version>
</dependency>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>4.4</version>
</dependency>
<dependency>
<groupId>commons-lang</groupId>
<artifactId>commons-lang</artifactId>
<version>2.3</version>
</dependency>
<dependency>
<groupId>ojdbc</groupId>
<artifactId>ojdbc</artifactId>
<version>14</version>
</dependency>
<dependency>
<groupId>org.apache.commons</groupId>
<artifactId>commons-io</artifactId>
<version>1.3.2</version>
</dependency>
<dependency>
<groupId>commons-io</groupId>
<artifactId>commons-io</artifactId>
<version>1.4</version>
</dependency>
<dependency><!-- java bytecode processor -->
<groupId>javassist</groupId>
<artifactId>javassist</artifactId>
<version>3.8.0.GA</version>
</dependency>
<dependency>
<groupId>commons-dbcp</groupId>
<artifactId>commons-dbcp</artifactId>
<version>1.2.1</version>
</dependency>
<dependency>
<groupId>hsqldb</groupId>
<artifactId>hsqldb</artifactId>
<version>1.8.0.7</version>
</dependency>
<dependency>
<groupId>org.dbunit</groupId>
<artifactId>dbunit</artifactId>
<version>2.4.4</version>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring</artifactId>
<version>2.5.6</version>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-test</artifactId>
<version>2.5.6</version>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-orm</artifactId>
<version>2.5.6</version>
</dependency>
<dependency>
<groupId>org.hibernate</groupId>
<artifactId>hibernate-annotations</artifactId>
<version>3.4.0.GA</version>
</dependency>
<dependency>
<groupId>org.hibernate</groupId>
<artifactId>hibernate-commons-annotations</artifactId>
<version>3.3.0.ga</version>
</dependency>
<dependency>
<groupId>org.hibernate</groupId>
<artifactId>hibernate-core</artifactId>
<version>3.3.1.GA</version>
</dependency>
<dependency>
<groupId>org.hibernate</groupId>
<artifactId>hibernate-validator</artifactId>
<version>3.1.0.GA</version>
</dependency>
<dependency>
<groupId>org.hibernate</groupId>
<artifactId>hibernate-entitymanager</artifactId>
<version>3.4.0.GA</version>
</dependency>
<dependency>
<groupId>commons-lang</groupId>
<artifactId>commons-lang</artifactId>
<version>2.3</version>
</dependency>
</dependencies>
Thanks
Marty

One thing that I've found challenging is determining what is in each package, especially from Spring.
To that end, I've found Netbeans' support for maven to be outstanding in how it lets you know what libraries are pulled in by each requirement. 6.7 Beta contains a graphical tree which is outstanding, and m2eclipse also has a very nice graphical dependency tree. How else would you know that spring-orm includes, spring-beans, spring-core, spring-context, and spring-tx? You can ask maven for the dependencies using the dependency plugin from the command line, but the graphical representation is quite handy. dependency:tree is the goal you want to run. Obviously you can also run that from Netbeans or Eclipse.
So, as an example of one of your collisions:
<dependency>
<groupId>org.hibernate</groupId>
<artifactId>hibernate-annotations</artifactId>
<version>3.4.0.GA</version>
</dependency>
actually includes hibernate-commons-annotations-3.1.0.GA not 3.3. It also includes hibernate-core-3.3.0.SP1, not 3.3.1.GA.
I would start at your "biggest" component, and start to see what parts that already includes and only add what is missing. Even then, double check that you don't have a duplicate dependency and if need be, exclude the duplicate as shown in the answer to this question.

If you are using eclipse, then you should download the maven plugin from sonatype here http://m2eclipse.sonatype.org/.
This comes with a useful graphic visualisation of your dependencies (in particular transitive dependencies - dependencies you have not explicitly defined in your POM), and also shows conflicting dependencies.
Update: from the comments below, your mileage may vary.