Feat/new implementation cyclonedx bom

[gordonrousselle]

This is a proposal implementation for the next major version of the cyclonedx gradle plugin. The reason for this is twofold. Firstly, this implementation will support Gradle's configuration cache which will be enforced by default in the near future. Secondly, it aims to resolve some of the open issues reported against the current implementation.

Most of the existing features are still supported, but a couple of points are worth noting:

• child projects, if exists, are now also included as component in the resulting BOM
• component that represent gradle projects have purls without a type field (defaulted to JAR in previous version)
• Version 1.0 of the CycloneDX BOM is not supported anymore

[skhokhlov]

I think this PR should resolve https://github.com/CycloneDX/cyclonedx-gradle-plugin/issues/528, @gordonrousselle can you please add test for it?

[skhokhlov]

@stevespringett @DarthHater @nscuro @mr-zepol Do you have any concerns here? If not, I'll merge it tomorrow

[jeremylong]

Somehow I missed this PR - I was about to submit a PR that migrates from Configuration.getResolvedConfiguration() to Configuration.getIncoming() because I have an Android project that is facing issues with variant selection. My PR is not as substantial - but does solve the issue with variant selection (in my case). However, when I use this implementation I still face:

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':app:cyclonedxBom'.
> Could not resolve all artifacts for configuration ...

The (trimmed) exception is:

...
Cause 22: org.gradle.internal.component.AmbiguousArtifactVariantsException: The consumer was configured to find a library for use during compile-time, preferably optimized for Android, as well as attribute 
...
 at org.cyclonedx.gradle.SbomGraphProvider.lambda$getArtifacts$6(SbomGraphProvider.java:131)

I'm looking into this more to see if I can provide a suggestion/workaround.

[skhokhlov]

Hi @jeremylong, I'm very excited that such small change can fix Android issues. Can you please open a separate PR with this fix? Then we can properly test it and close related issues

[jeremylong]

The "small" change - requires moving from Configuration.getResolvedConfiguration() to Configuration.getIncoming() And using a lenient artifactView. As such, this full PR would be needed - plus my small addition.

I might have a minor fix I can propose to the current implementation. Let me test something.

[jeremylong]

It turns out even using a lenient configuration using the legacy getResolvedConfiguration() still fails for Android:

        final LenientConfiguration resolvedConfiguration =
                configuration.getResolvedConfiguration().getLenientConfiguration();
        final Set<ResolvedDependency> directModuleDependencies =
                resolvedConfiguration.getFirstLevelModuleDependencies();

As such, this PR - with the addition of the lenient artifact view appears to solve the android issues.

[jeremylong]

I could submit another PR that isn't as large, follows more of the code paths that were used previously, and solves the Android issues. But honestly, the code in this PR is really good and you should just go with this one.

[jeremylong]

I'll submit another PR to add the lenient artifactView.