During a composite build, the parent jar is copied in place of all composite build jars in the generated kar

[crosscontrol]

When generating a kar from a gradle composite build, the composite build project jar is copied in place of all of the included includeBuild('projectPath') jar files.

To reproduce the problem, please see the attached zip file.

Extract the zip file and run gradlew jar generateFeatures generateKar from the karafPluginCompositeBug directory.

Now extract ProjectA.jar from the exploded kar directory:
"karafPluginCompositeBug/build/karaf/kar/exploded/repository/com/github/projecta/ProjectA/1.0/ProjectA-1.0.jar"

You will notice that the plugin copied the parent jar file (karafPluginCompositeBug-1.0.jar) but with the name ProjectA-1.0.jar which is the bug. It should contain the ProjectA.class file but instead contains Bug.class.

If you examine the ProjectA-1.0.jar file in "ProjectA/build/libs/ProjectA-1.0.jar", you will notice it contains the proper ProjectA.class file.

Thank you for all your great work on this project!

karafPluginCompositeBug.zip

[lburgazzoli]

I have not yet looked at composite builds, I hope ti have time while working on full gradle 4.x support

[crosscontrol]

Okay. I am new to groovy and gradle but I can try to look into it more. What development tools do you recommend to debug this?

[lburgazzoli]

I use Jetrbrains IDEA but any ide with groovy support should be enough

[crosscontrol]

I think I have a pretty good idea of the problem... I'm pretty new to gradle and your plugin so bear with me.

The issue is in KarafFeaturesUtils.groovy.

It looks like the code returns the path to the parent composite project every time and gets its artifact which is later copied to the proper location in the kar file.

I evaluated this snippet of code in the debugger and using it, you can find the proper path to the artifact (from gradle cache or project built artifact) regardless of whether its a ProjectComponentIdentifier or a DefaultModuleComponentIdentifier:

configuration.resolvedConfiguration.resolvedArtifacts.findAll {it.moduleVersion.id == root.moduleVersion}

Do you think the code should be modified to always grab the location of the artifact, regardless of if its a project or not, from the "file" location? This seems more robust.

[lburgazzoli]

I need to digg into it a little more as I do not remember but you are free to open a PR and I will check it

[crosscontrol]

I have a fix for this. I created a fix branch based off of the .49 tag since there seem to be some bugs in the current commits (config file resolution). I didn't have time to look into that for now. Here is the fix branch.

As an addition to this comment... The reason this fixes the problem is that in a composite build, gradle associates an artifact with the included build since it gets built before anything that depends on it. This allows us to grab the artifact from the composite build. Even though an included composite build is still a ProjectComponentIdentifier, the relative path to the artifact (in relation to the parent project) will likely be erroneous. By trying to get the artifact first, you ensure that you are getting the proper file and not the parent jar due to the erroneous relative path. One thing I don't like in the fix is the lack of an else statement. What you feel should fill that gap.