When a cpp plugin is applied, set cpp module type

[yahavi]

• All tests passed. If this feature is not already covered by the tests, I added new
  tests.

---

Depends on jfrog/build-info#773 (will not compile before it)
Fix #91

When the cpp-application or cpp-library plugin are applied to a project, set the module type to cpp.

[eyalbe4]

Shouldn't this be an AND condition instead of OR?

[yahavi]

No. We need one of the plugin lists to be not empty.
In other words -
The cpp-application plugin or the cpp-library plugin should be applied.

[enaess]

Actually, you maybe better off using NativeBasePlugin.class here instead. We provide our own CppLibrary/CppApplication plugins w/a custom CppBasePlugin (possible alternative to NativeBasePlugin.class). However, if you do use NativeBasePlugin.class, this change would also capture e.g. swift projects (which is really just a C++ extension provided by Apple if you ask me).

[enaess]

Add the following import statement, and remove the ones related to the CppApplication and CppLibrary plugins

import org.gradle.language.plugins.NativeBasePlugin;

Then add:

     private ModuleType getModuleType(Project project) {
         PluginContainer plugins = project.getPlugins();
         if (!plugins.withType(NativeBasePlugin.class).isEmpty()) {
             return ModuleType.CPP;
         }
         return ModuleType.GRADLE;
     }

Sorry it took me so long to get that tested. I had to fix up the build to publish to mavenLocal and then re-run my separate build using that. In addition, the ModuleType.CPP change wasn't in the build-info-api yet so I had to additionally publish that locally too.

But the above works, it fills in the module with a type="cpp" field, and any dependencies under it seem to inherit it (despite being empty in the build-info.json file) when published to artifactory. They do show up as CPP type for X-Ray / Build SBOM and the dependencies are correctly being tracked there.

[enaess]

I added some additional notes to my review, and if you sue the NativeBasePlugin instead of the CppApplicationPlugin or CppLibraryPlugin classes, this change will work for me.

[enaess]

Actually, you maybe better off using NativeBasePlugin.class here instead. We provide our own CppLibrary/CppApplication plugins w/a custom CppBasePlugin (possible alternative to NativeBasePlugin.class). However, if you do use NativeBasePlugin.class, this change would also capture e.g. swift projects (which is really just a C++ extension provided by Apple if you ask me).

[enaess]

Add the following import statement, and remove the ones related to the CppApplication and CppLibrary plugins

import org.gradle.language.plugins.NativeBasePlugin;

Then add:

     private ModuleType getModuleType(Project project) {
         PluginContainer plugins = project.getPlugins();
         if (!plugins.withType(NativeBasePlugin.class).isEmpty()) {
             return ModuleType.CPP;
         }
         return ModuleType.GRADLE;
     }

Sorry it took me so long to get that tested. I had to fix up the build to publish to mavenLocal and then re-run my separate build using that. In addition, the ModuleType.CPP change wasn't in the build-info-api yet so I had to additionally publish that locally too.

But the above works, it fills in the module with a type="cpp" field, and any dependencies under it seem to inherit it (despite being empty in the build-info.json file) when published to artifactory. They do show up as CPP type for X-Ray / Build SBOM and the dependencies are correctly being tracked there.

[yahavi]

Thanks for sharing your thoughts, @enaess! Your feedback is appreciated.

It seems like the NativeBasePlugin might not fit the specific CPP use case very well. Perhaps considering an alternative approach by allowing manual module type setting could be beneficial.

For instance, setting the module type manually could look something like this:

configure<ArtifactoryPluginConvention> {
   publish {
       defaults {
           moduleType("CPP")
       }
   }
}

And within the project scope:

tasks.named<ArtifactoryTask>("artifactoryPublish") {
   setModuleType("CPP")
}

This could offer more flexibility and customization for the CPP use case.
We would appreciate your feedback on this approach.

[enaess]

I have a plugin that I apply that will apply the artifactory plugin, I can fix this up there for the individual projects that applies the cpp/library plugin to set the module type to CPP -- I don't really care whichever way we chose here ..

Looking through the code now, configuring the ModuleType.CPP for the defaults doesn't exist, in fact it probably doesn't have the right wiring in place to take any overrides, no? This is being called from the GradleModuleExtractor not the ArtifactoryTask ...

Is this something you can fix rather quick and dirty and do another release of the plugin?

[yahavi]

Hey @enaess,
I'm a bit unclear on this.
Will the approach of setting the module type manually in the project solve your issue? If it will, we can incorporate the above example it into the Artifactory plugin.

[enaess]

I think it will. Please a PR asap would be preferable @yahavi

[yahavi]

@enaess
Thanks for your feedback.
We created #99 to add this improvement.