Red Hat Bugzilla – Bug 839231
The jboss-jbpm-engine zip should only contain the CXF 2.4.1 jars and not the CXF 2.2.9 jars
Last modified: 2013-10-07 18:50:37 EDT
According the resolution on this bugzilla
We agreed upon:
In the product builds, only some zips should contain drools-camel.jar with cxf-2.4.1.jar (and other dependencies that drools-camel needs):
-- jboss-brms-engine.zip: Yes (drools-camel + the cxf jar that drools-camel needs)
-- jboss-jbpm-engine.zip: Yes (drools-camel + the cxf jar that drools-camel needs)
But something went wrong in the implementation, which is apparently this file:
And also this file (brms-engine.zip might suffer from this problem too)
That file is using filesets, instead of dependencyset. As a result of which, the maven dependency conflict resolution does NOT kick in. So some jars (such as CXF) might be on the classpath multiple times in different versions (which will cause errors as only 1 jar will be used and it's chosen arbitrary).
(In reply to comment #0)
> According the resolution on this bugzilla
> We agreed upon:
> In the product builds, only some zips should contain drools-camel.jar with
> cxf-2.4.1.jar (and other dependencies that drools-camel needs):
> - deployable.zip:
> -- jboss-brms-engine.zip: Yes (drools-camel + the cxf jar that drools-camel
> -- jboss-jbpm-engine.zip: Yes (drools-camel + the cxf jar that drools-camel
> But something went wrong in the implementation, which is apparently this
> And also this file (brms-engine.zip might suffer from this problem too)
> That file is using filesets, instead of dependencyset. As a result of which,
> the maven dependency conflict resolution does NOT kick in. So some jars
> (such as CXF) might be on the classpath multiple times in different versions
> (which will cause errors as only 1 jar will be used and it's chosen
I think you distracted by only looking part of build script.
The real assembly for collecting the dependencies for drools-camel is
let's say if I defined a very simple pom.xml like:
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
<name>Test drools-camel's deps</name>
And run: mvn dependency:tree
I ends up with 2 versions cxf.
I think I see the cause behind this.
Both droolsjbpm-parent.pom (ie. drools-camel's parents pom) and camel-parent.pom(ie. camel-cxf's parent pom) defined cxf-version and defined differently.
And according to maven transitive dependencies resovling resolution, it would choose the nearest definition.
So in upstream, it can choose cxf 2.4.1 as it is the nearest. However for any downstream project which refers to drools-camel artifact like the simple sample in comments, it nearest definition obvious can't find the best solution.
I believe there are several ways to resolve this. The best way from my perspective is to add "exclude option" in upsteam 's camel-cxf dependencyset.
Then it can fix this issue in the root.
I attached the patch to the droolsjbpm-integration/drools-camel/pom.xml.
Geffreoy, what do you think?
See maven transitive dependency ref at https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Transitive_Dependencies
Created attachment 597702 [details]
droolsjbpm-integration/drools-camel pom patch
If you depend on drools-camel, you 'll see this in your tree:
[INFO] \- org.drools:drools-camel:jar:5.3.3.Final:compile
[INFO] +- org.apache.camel:camel-cxf:jar:2.4.0:compile
[INFO] | \- org.apache.cxf:cxf-rt-frontend-jaxrs:jar:2.2.9:compile // WRONG
[INFO] +- org.apache.cxf:cxf-rt-frontend-jaxws:jar:2.4.1:compile
However, drools-camel itself, has this:
[INFO] +- org.apache.camel:camel-cxf:jar:2.4.0:compile
[INFO] | \- org.apache.cxf:cxf-rt-frontend-jaxrs:jar:2.4.1:compile (version managed from 2.2.9)
[INFO] +- org.apache.cxf:cxf-rt-frontend-jaxws:jar:2.4.1:compile // CORRECT
BROKEN: 1) exclude cxf-rt-frontend-jaxrs from camel-cxf. That will break camel-cxf at runtime.
2) configure droolsjbpm-parent to uplift cxf-rt-frontend-jaxrs to 2.4.1
3) configure drools-camel to uplift cxf-rt-frontend-jaxrs to 2.4.1
Will 2) or 3) work?
We already 2) and that doesn't fix it (maven bug).
Here's the proof that we already do 2) and that it doesn't work:
We have the same problem with the spring dependencies. In community dependency:tree they are all 3.0.6, but in the depended productization project they are 2.5.6, 3.0.3 and 3.0.6.
There's only way way to fix this as far as I can see.
Add this bit to the productization parent pom (or all individual poms if there is no such parent pom):
Yes, It is.
So far it seems to be the only way to workaround this strange maven behavior.
Also not sure how serious this issue is. There should be no problem with the runtime behaviour, right?
It's not a bug in Maven per se; it's just a very subtle design decision that was made. Basically, dependencyManagement has two very similar roles, and only one is used when dependencyManagement happens in a dependency (as opposed to being used in the project you're building):
1. Specify versions/scopes/excludes for dependencies you declare in your POM and the POMs that inherit from it.
2. Enforce managed versions throughout the dependency graph of the project you're building.
#1 applies universally, even when a your project defines a dependency and that dependency's POM has dependencyManagement in effect for one of _its_ dependencies. HOWEVER, #2 only applies when building THAT project.
While drools-camel may provide a version for cxf-rt-frontend-jaxrs, this version is ONLY used to override the specification in camel-cxf (in intermediary in the depgraph) when drools-camel is being built.
As soon as something DEPENDS ON drools-camel, that #2 effect of dependencyManagement goes dormant. This means the project that depends on drools-camel will also need a similar dependencyManagement section...which is why injecting an import-scoped dependency on droolsjbpm-parent works.
I believe this is the "most" correct solution, BTW (importing droolsjbpm-parent).
Thanks very much for your explaination.
I think it explains everything here.
I would do the import droolsjbpm-parent pom to avoid this issue.
Change has been committed to product build.
Noticed that after this change, several transitive dependencies version have also been upgraded besides cxf jars. But they should be fixed as cxf is.
"Bug 839231 Enforce droolsjbpm-parent's dependency managerment by importing its pom"
Both EE5 and EE6 deployable contain only CXF 2.4.1. VERIFIED with 5.3.1 ER1.