[BUG] Component differences between reports produced by NexusIQ CLI and Gradle plugin

[jwise-sncr]

Describe the bug
The component list between a NexusIQ CLI report and a report generated via this plugin differ when run against the same project.

To Reproduce
Steps to reproduce the behavior:

1. Define a project which uses compile only artifacts like a code generation library
2. Run a scan using this plugin against that project
3. Run a scan using NexusIQ CLI against the produced artifacts of that project

Expected behavior
I expect the list of components in each report to match. I understand there may be differences in direct/transitive labels, but the list of components should match. Unfortunately this plugin includes dependencies on the compileClasspath configuration which don't end up in the deployable artifacts and I see no way to exclude them from the scan.

Desktop (please complete the following information):

• OS: OS X, Linux
• Gradle Version: 7.6.2
• JVM Version and Flavor: 1.8.0_382 (Amazon.com Inc. 25.382-b05)
• Nexus IQ Server Version: 165
• Version: 2.6.1

[guillermo-varela]

Thanks for bringing this to our attention, @jwise-sncr

One important thing to note is the fact that this plugin doesn’t aim to be equivalent to the IQ CLI tool but to the Maven plugin and from it's documentation:
https://help.sonatype.com/en/sonatype-clm-for-maven.html#included-dependencies

Only dependencies in the compile and runtime scopes are considered

That’s the reason we include compile dependencies here.

However, I recall seeing comments about only including runtime dependencies on this plugin and as a new feature I’d think that’s something we can consider implementing.

[jwise-sncr]

@guillermo-varela According to Gradle, its compileOnly configuration is meant to more closely mirror Maven's provided scope, and not the compile scope. See https://blog.gradle.org/introducing-compile-only-dependencies.

[jwise-sncr]

Also, is there a use case where you'd want the Gradle plugin, Maven plugin, or CLI to produce different results against the same codebase? I understand the limitations of the CLI around direct/transitive labels, but I'd think the list of dependencies would match between all three tools.

[guillermo-varela]

@jwise-sncr, a draft pull-request has been created that adds a new property to include only dependencies from the runtime configuration, that is no more compile dependencies in the evaluation. Hopefully that covers the case you have at hand:
#153

More tests are needed, but an initial run was successful.

Also, is there a use case where you'd want the Gradle plugin, Maven plugin, or CLI to produce different results against the same codebase? I understand the limitations of the CLI around direct/transitive labels, but I'd think the list of dependencies would match between all three tools.

Do you have sample projects you can share with us where that happens?

[jwise-sncr]

@guillermo-varela, a sample project is not needed. Create a small maven project that contains a dependency marked with 'provided' scope. The equivalent Gradle project will have the same dependency marked with 'compileOnly' configuration. The Sonatype Maven plugin will not report on the dependency marked with 'provided' scope per the documentation you referenced earlier. The NexusIQ CLI will not report on the dependency marked as 'provided' scope nor the dependency marked as 'compileOnly' configuration since the dependency will not appear in the built jar. The Sonatype Gradle plugin will report on the dependency marked with 'compileOnly' scope. Given your claim that the Gradle plugin behavior was designed to match the Maven plugin behavior, I consider this a bug as the Gradle blog I mentioned says the 'compileOnly' configuration is equivalent to the Maven 'provided' scope.

[guillermo-varela]

As follow up and documenting newest findings:

After understanding better the ask on this issue, a deeper looks was taken into Gradle configurations documentation:
https://docs.gradle.org/current/userguide/java_library_plugin.html#sec:java_library_configurations_graph

From what I see compileOnly is not a resolvable configuration and we're using the resolved ones to get the actual files/artifacts for the dependencies:

scan-gradle-plugin/src/main/java/org/sonatype/gradle/plugins/scan/common/DependenciesFinder.java

Lines 111 to 120 in b0d8252

	findResolvedArtifacts(project, allConfigurations, variantAttributes).forEach(resolvedArtifact -> {
	ModuleVersionIdentifier artifactId = resolvedArtifact.getModuleVersion().getId();
	Artifact artifact = new Artifact()
	.setId(artifactId.getGroup() + ":" + artifactId.getName() + ":" + artifactId.getVersion())
	.setPathname(resolvedArtifact.getFile())
	.setMonitored(true);
	module.addConsumedArtifact(artifact);
	});

An initial test was made to get the dependencies from compileOnly without resolving the configuration to exclude them for evaluation and it was successful, however we'd also need to consider the transitive dependencies comming from those to also exclude them, only if not comming by any other dependencies in other configurations.

We're also getting dependencies without resolving configurations to set the Direct and Transitive labels on the evaluation report, but currently that's done in a later step:

scan-gradle-plugin/src/main/java/org/sonatype/gradle/plugins/scan/common/DependenciesFinder.java

Lines 122 to 124 in b0d8252

	findResolvedDependencies(project, allConfigurations, variantAttributes).forEach(
	resolvedDependency -> module.addDependency(processDependency(resolvedDependency, true, new HashSet<>()))
	);

An attempt will be made to see if we can filter out the dependencies (direct and transitive) comming from the compileOnly from the resolved artifacts by checking first the configuration without resolving it.

[guillermo-varela]

@jwise-sncr,

Version 2.8.0 has been published with a new option to exclude compileOnly dependencies:
https://github.com/sonatype-nexus-community/scan-gradle-plugin/releases/tag/2.8.0

Please try it out and let us know if that fulfils your requirement.