Proposal for subproject configuration

[loosebazooka]

Instead of configuring subproject via the wacky taskExtension (which maybe should be limited to use only for mapping maven deps). We have a companion plugin to org.spdx.sbom called org.spdx.sbom-package that can be applied to sub projects to configure their properties.

subproject/build.gradle.kts

plugins {
  ...
  id("org.spdx.sbom-package")
}

spdxPackage {
  name.set(...)
  version.set(...)
  supplier/creator... whatever
  scm {
     ...
   }
}

[AlexanderYukhanov]

I like the idea, but we do need some support for large size projects. For example, configuring each of 745 subprojects in JetBrains Kotlin independently with the same values seems to be a bit too much. i suppose in most cases, subprojects sharing the same parent folder have the same configuration and it would be nice to have some an ability to configure subprojects based on their source path.

[loosebazooka]

Yeah, so it should be mostly optional, by default projects shouldn't need to configure it. But configuring it this way feels a bit more more conventional. I not sure the callback into the taskExtension plays nice with any caching that gradle does?

This should still be apply-able globally via build-logic or something else like that?

[mathjeff]

The thing that seems most weird to me about having a task extension for specifying the spdx name/version/etc is it allows setting different values (of dependency projects) in dependent projects and in different tasks, which sounds to me like an accident (although I don't know of anyone doing that yet - in AndroidX we probably won't encounter that since we're configuring this plugin in all of our projects in one method)

If we want to make sure that the current approach allows the tasks to be cacheable I think we can do that too, maybe making sure that the classpath of the SpdxTaskExtension instance is included as an input to the task, or maybe by calling the SpdxTaskExtension on each project and putting the results in a data structure and declaring that as an input to the task

(so I don't really have much opinion for or against adding or changing subproject configuration like this)

[AlexanderYukhanov]

Let's have a support for a configuration provided as sbom.spdx.json file in the root of the subproject as well. If i have an subproject which is a fork of an upstream, it's more natural to update an sbom with every upstream merge instead of updating the build files. Plus, having such opportunity will allow us to not have every single spdx attribute support in the plugin. E.g. if somebody really need to add cpe locator, they can add it in the sbom.spdx.json instead of waiting for us to add the references and locators

[loosebazooka]

Do we just merge sbom.spdx.json into the generated one?

[loosebazooka]

incompatible with project isolation. It looks like @AlexanderYukhanov suggestion of a single config file would actually make more sense.