-
Bug
-
Resolution: Unresolved
-
Minor
-
None
-
7.58.0.Final
-
None
-
False
-
False
-
NEW
-
NEW
-
undefined
-
-
Much of this is just copied from issue report on the appropriate repo https://github.com/kiegroup/kie-soup/issues/190.
I'm unclear on the reason for the getAllDependencies method.
This method aggregates together all dependencies both direct and transitive into a Set; however, this Set is only constrained by duplicates and does not attempt to resolve version conflicts in the standard way maven would in the same case. (see https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Transitive_Dependencies).
The drools project leverages this method (see https://github.com/kiegroup/drools/blob/master/kie-ci/src/main/java/org/kie/scanner/KieModuleMetaDataImpl.java#L173) and a side effect of this turns out to be many transitive artifacts are resolved (i.e. downloaded to local disk repo). Additionally, this project goes on to attempt to load all classes from all versions of a dependency into its KieContainer instance's classloader.
Luckily this turns out to fail since that classloader was not backed by the same set of resolved artifacts, but its easy to imagine a worse outcome and the chaos this would create.
A side effect of this "bug" that impacts the kie-server project in the drools ecosystem is that deployments of kjars to the kie-server application require a maven repository either contain or actively resolve these unnecessary dependencies. In the context of containerizing a kjar backed application this presents an interesting challenge as approaches such as this (see https://github.com/kiegroup/droolsjbpm-integration/blob/master/kie-maven-plugin/src/main/java/org/kie/maven/plugin/PackageKjarDependenciesMojo.java) seem destined to reliably fail in all cases where there is a conflict in the dependency graph. To be clear, when I say fail I only mean the expectation that an artifact can be resolved is baked into the product as it does not seem to have any awareness that some of these dependencies really should not be coming back from the ArtifactResolver's getAllDependecies method at all.
I do not have any context on if this method has value in some other way, but I believe its likely a bug and at best is misleading.
- is related to
-
JBPM-9829 Spring Boot jar containing kjar and commons-beanutils causes "Could not read pom in jar" error.
-
- Resolved
-