Bug 839231 - The jboss-jbpm-engine zip should only contain the CXF 2.4.1 jars and not the CXF 2.2.9 jars
The jboss-jbpm-engine zip should only contain the CXF 2.4.1 jars and not the ...
Status: VERIFIED
Product: JBoss Enterprise BRMS Platform 5
Classification: JBoss
Component: jBPM 5 (Show other bugs)
BRMS 5.3.1
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Ryan Zhang
Lukáš Petrovický
:
Depends On: 806208
Blocks:
  Show dependency treegraph
 
Reported: 2012-07-11 05:52 EDT by Geoffrey De Smet
Modified: 2013-10-07 18:50 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
droolsjbpm-integration/drools-camel pom patch (632 bytes, patch)
2012-07-11 22:48 EDT, Ryan Zhang
no flags Details | Diff

  None (edit)
Description Geoffrey De Smet 2012-07-11 05:52:03 EDT
According the resolution on this bugzilla
  https://bugzilla.redhat.com/show_bug.cgi?id=806208#c6
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 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:
  http://svn.devel.redhat.com/repos/jboss-soa/trunk/brms-p/src/main/assembly/jbpm-engine.zip.xml
And also this file (brms-engine.zip might suffer from this problem too)
  http://svn.devel.redhat.com/repos/jboss-soa/trunk/brms-p/src/main/assembly/brms-engine.zip.xml

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).
Comment 1 Ryan Zhang 2012-07-11 06:48:18 EDT
(In reply to comment #0)
> According the resolution on this bugzilla
>   https://bugzilla.redhat.com/show_bug.cgi?id=806208#c6
> 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
> 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:
>  
> http://svn.devel.redhat.com/repos/jboss-soa/trunk/brms-p/src/main/assembly/
> jbpm-engine.zip.xml
> And also this file (brms-engine.zip might suffer from this problem too)
>  
> http://svn.devel.redhat.com/repos/jboss-soa/trunk/brms-p/src/main/assembly/
> brms-engine.zip.xml
> 
> 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).
I think you distracted  by only looking part of build script.

The real assembly for collecting the dependencies for drools-camel is
http://svn.devel.redhat.com/repos/jboss-soa/trunk/brms-p/drools-camel/pom.xml
and
http://svn.devel.redhat.com/repos/jboss-soa/trunk/brms-p/drools-camel/src/main/assembly/brms-camel.xml
Comment 2 Ryan Zhang 2012-07-11 08:16:45 EDT
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">
    <modelVersion>4.0.0</modelVersion>
    <name>Test drools-camel's deps</name>
    <groupId>org.jboss</groupId>
    <artifactId>test-drools-camel</artifactId>
    <packaging>pom</packaging>
    <version>1.0</version>
 
 
  <dependencies>
    <dependency>
      <groupId>org.drools</groupId>
      <artifactId>drools-camel</artifactId>
      <version>5.3.3.Final</version>
    </dependency>
  </dependencies>
 
</project>

And run: mvn dependency:tree
I ends up with 2 versions cxf.
Comment 3 Ryan Zhang 2012-07-11 22:46:43 EDT
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
Comment 4 Ryan Zhang 2012-07-11 22:48:12 EDT
Created attachment 597702 [details]
droolsjbpm-integration/drools-camel pom patch
Comment 5 Geoffrey De Smet 2012-07-12 04:27:04 EDT
Problem:

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

Solution proposals:

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?
Comment 6 Geoffrey De Smet 2012-07-12 04:36:06 EDT
We already 2) and that doesn't fix it (maven bug).
Comment 7 Geoffrey De Smet 2012-07-12 04:38:04 EDT
Here's the proof that we already do 2) and that it doesn't work:
  https://github.com/droolsjbpm/droolsjbpm-build-bootstrap/blob/5.3.x/pom.xml#L1830
Comment 8 Geoffrey De Smet 2012-07-12 04:56:00 EDT
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):

<dependencyManagement>
  <dependency>
    <groupId>org.drools</groupId>
    <artifactId>droolsjbpm-parent</artifactId>
    <version>...</>
    <scope>import</scope>
  </dependency>
</dependencyManagement>>
Comment 9 Ryan Zhang 2012-07-12 06:12:48 EDT
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?
Comment 10 John Casey 2012-07-12 11:36:54 EDT
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).
Comment 11 Ryan Zhang 2012-07-12 22:01:26 EDT
Thanks very much for your explaination.

I think it explains everything here.

I would do the import droolsjbpm-parent pom to avoid this issue.
Comment 12 Ryan Zhang 2012-07-12 22:39:05 EDT
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. 

Commit message:
"Bug 839231 Enforce droolsjbpm-parent's dependency managerment by importing its pom"
正在发送       drools-camel/pom.xml
正在发送       pom.xml
传输文件数据..
提交后的版本为 11275
Comment 14 Lukáš Petrovický 2012-09-18 03:07:42 EDT
Both EE5 and EE6 deployable contain only CXF 2.4.1. VERIFIED with 5.3.1 ER1.

Note You need to log in before you can comment on or make changes to this bug.