Found out about this bug today, while trying to fix a full downstream build. A test in kie-server-integ-tests-policy, KieServerPolicyDroolsIntegrationTest, broke with a ClassCastException. The cast however should have been legal.

tl;dr:

there is a class loading problem with kie-server-integ-tests-policy because of the way the Maven plugin is used there.

Suggested solution

KieServerPolicyDroolsIntegrationTest instantiates a MavenCli object, but (apparently) the classpath is inherited by the test runner, causing classloading issues (detailed later). We should probably fork a new JVM with a fresh classpath, limited to the dependencies of the Maven plugin so that spurious classes are not on the classpath of the test.

Other details

As part of DROOLS-3355, DROOLS-3307 I have moved CMMN package-building phase to the Assembler API. This highlighted an issue in the way the Maven plugin is tested (and/or the Service discovery mechanism, depending on how you want to see it)

This is what I have understood:

• CMMNAssemblerService is in its own package, which depends on jBPM.
• the Maven plugin injects its own ClassLoader,
• then it calls KieServices.Factory.get(),
• this causes the Service discovery to start, and all the services found in the {{kie.conf}}s that are on the current classpath
  Please notice that the classpath in the Full Downstream Build includes all the packages, so every kie.conf found in every project jar

In the test that broke KieServerPolicyDroolsIntegrationTest:

• Maven instance is created; It is created a new class loader (@ BuildMojo#buildDrl() ) with the jars on which Maven plugin depends.
  Before my fix, this DID not include the dependency on CMMN
• however kie.conf for CMMNAssemblerService is in the class path of full downstream build!
• because it is not a direct Maven dependency, it is not in the class loader of the Maven build
• CMMNAssemblerService is therefore loaded from the root classloader
• when KieAssemblerServices are processed, all assembler services except CMMN are found in the maven classpath, so they are loaded from that class loader
• ClassCastException is raised when CMMNAssemblerService is used because it is not an instance of KieAssemblerService (really, it is: but the class KieAssemblerService has now been loaded from the maven class loader, while CMMNAssemblerService has been loaded from the root classloader)

The problem is that the chain of classloaders AND the service discovery mechanism:

• The classloader delegates to the root classloader, which loads from the full downstream classpath, which includes everything and loads a service that should not be found; this in turn causes the ClassCastException
• the service discovery mechanism loads kie.conf from the full downstream classpath, which includes jars that should not be processed (as they would not be in the maven plugin classpath)