Affects Drools 5.3.x and jBPM 5.2.x at least. When assembling BRMS-P from Drools/jBPm modules and their dependencies, multiple third-party jar versions are used: asm-3.1.jar asm-3.3.jar commons-codec-1.2.jar commons-codec-1.3.jar cxf-api-2.4.1.jar cxf-bundle-jaxrs-2.4.1.jar cxf-common-utilities-2.2.9.jar cxf-rt-bindings-soap-2.4.1.jar cxf-rt-bindings-xml-2.4.1.jar cxf-rt-core-2.4.1.jar cxf-rt-databinding-aegis-2.2.9.jar cxf-rt-databinding-jaxb-2.4.1.jar cxf-rt-frontend-jaxrs-2.2.9.jar cxf-rt-frontend-jaxws-2.4.1.jar cxf-rt-frontend-simple-2.4.1.jar cxf-rt-transports-http-2.2.9.jar cxf-rt-ws-addr-2.4.1.jar cxf-tools-common-2.4.1.jar spring-aop-2.5.6.jar spring-asm-3.0.5.RELEASE.jar spring-beans-2.5.6.jar spring-context-2.5.6.jar spring-core-2.5.6.jar spring-expression-3.0.5.RELEASE.jar spring-tx-3.0.3.RELEASE.jar spring-web-2.5.6.jar xmlbeans-2.3.0.jar xmlbeans-2.4.0.jar xstream-1.3.1.jar xstream-1.4.1.jar The different versions appear to be the result of transitive dependencies of direct dependencies. They should be unified by using a dependencyManagement section in the parent POM. Also, as a minimum, Spring versions should be upgraded to 2.5.6 SEC02 and 3.0.6.
What brings in the CXF 2.2.x deps? Those shouldn't be necessary as we have no issues with shipping 2.4.x in the jboss-brms-engine.zip.
We've upgraded everything to spring 3.0.6.RELEASE.
I can't reproduce the different cxf versions. Here's my listing of the droolsjbpm-integration-distribution-5.3.2-SNAPSHOT zip: $ pwd /home/gdesmet/projects/jboss/branches/droolsjbpm-5.3.x/droolsjbpm-integration/droolsjbpm-integration-distribution/target/droolsjbpm-integration-distribution-5.3.2-SNAPSHOT/droolsjbpm-integration-distribution-5.3.2-SNAPSHOT/binaries $ ls cxf-*.jar cxf-api-2.4.1.jar cxf-common-utilities-2.4.1.jar cxf-rt-bindings-xml-2.4.1.jar cxf-rt-databinding-jaxb-2.4.1.jar cxf-rt-frontend-jaxws-2.4.1.jar cxf-rt-transports-common-2.4.1.jar cxf-rt-ws-addr-2.4.1.jar cxf-bundle-jaxrs-2.4.1.jar cxf-rt-bindings-soap-2.4.1.jar cxf-rt-core-2.4.1.jar cxf-rt-frontend-jaxrs-2.4.1.jar cxf-rt-frontend-simple-2.4.1.jar cxf-rt-transports-http-2.4.1.jar cxf-tools-common-2.4.1.jar
There are 2 types of issues here: - 1) Different versions of different artifacts of the same framework mixed. That's bad. These should all be ok now: -- spring is fixed -- cxf is unreproducable (not in integration and not in guvnor) - 2) Different versions of same artifact. That can be normal in some cases (maven conflict detection will deal it when they arrive in the same classpath). Simply overwritting them in dependencyManagement is dangerous as we could inadvertently and silently overwrite it with a too low version (especially if upgrade other dependencies later on). -- common-codec. Cannot reproduce (*) Already defined as 1.5 in droolsjbpm-parent's dependencyManagement. So both 1.2 and 1.3 are wrong. -- asm: Cannot reproduce (*) -- xmlbeans: Cannot reproduce (*) -- xstream Cannot reproduce (*) Already defined as 1.4.1 in droolsjbpm-parent's dependencyManagement. (*) Not enough information to reproduce: I 'll need to know which droolsjbpm artifacts (= GAV's) are responsible for bringing in the different versions. Or which .org assembly zip has those multiple different versions of the same artifact.
Update status to ON_QA. Please verify them against ER6.
CFX is 2.2.12-patch-02, found no duplicates, marking this as VERIFIED.