Bug 839231

(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

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.

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

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?

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:
  https://github.com/droolsjbpm/droolsjbpm-build-bootstrap/blob/5.3.x/pom.xml#L1830

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>>

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. 

Commit message:
"Bug 839231 Enforce droolsjbpm-parent's dependency managerment by importing its pom"
正在发送       drools-camel/pom.xml
正在发送       pom.xml
传输文件数据..
提交后的版本为 11275

Both EE5 and EE6 deployable contain only CXF 2.4.1. VERIFIED with 5.3.1 ER1.