CycloneDX / CycloneDX/cyclonedx-gradle-plugin

The cyclonedxBom task fails at compileOnly dependencies with version enforced via platform

Open
#84 1 comment 1 reaction 0 assignees View on GitHub
Dominant language
Java
Stars
239
Forks
102
Avg merge
1d 9h
Merged PRs (30d)
11

Description

Hi,

I'm trying to incorporate Cyclone DX report to our company's project and it fails to resolve version of a `compileOnly` (`compileApiOnly`, too) dependency that has version enforced via the Java platform feature Gradle provides. Note that other dependency types like `api`, `implementation`, `runtimeOnly` work as expected.

I am using the plugin in version **1.2.0** (latest) and **Gradle 6.7**, and tried both OpenJDK 8 and OpenJDK 11.

Executing the task `gradle cyclonedxBom` produces the following error:

```
> Task :cyclonedxBom FAILED

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':cyclonedxBom'.
> Could not resolve all dependencies for configuration ':submodule1:compileOnly'.
> Could not find com.github.spotbugs:spotbugs-annotations:.
Required by:
project :submodule1
> Could not find javax.servlet:javax.servlet-api:.
Required by:
project :submodule1

* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output. Run with --scan to get full insights.

* Get more help at https://help.gradle.org

Deprecated Gradle features were used in this build, making it incompatible with Gradle 7.0.
Use '--warning-mode all' to show the individual deprecation warnings.
See https://docs.gradle.org/6.7/userguide/command_line_interface.html#sec:command_line_warnings

BUILD FAILED in 818ms
1 actionable task: 1 executed
```

Also note that when running this task, Gradle reports usage of deprecated or unsafe APIs. The `--warning-mode all` option reveals issues that seem to be directly connected to the resolution of those dependencies:

```
The archives configuration has been deprecated for resolution. This will fail with an error in Gradle 7.0. Please resolve the compileClasspath or runtimeClasspath configuration instead. Consult the upgrading guide for further information: https://docs.gradle.org/6.7/userguide/upgrading_version_5.html#dependencies_should_no_longer_be_declared_using_the_compile_and_runtime_configurations
The default configuration has been deprecated for resolution. This will fail with an error in Gradle 7.0. Please resolve the compileClasspath or runtimeClasspath configuration instead. Consult the upgrading guide for further information: https://docs.gradle.org/6.7/userguide/upgrading_version_5.html#dependencies_should_no_longer_be_declared_using_the_compile_and_runtime_configurations
The configuration :bom:archives was resolved without accessing the project in a safe manner. This may happen when a configuration is resolved from a different project. This behaviour has been deprecated and is scheduled to be removed in Gradle 7.0. See https://docs.gradle.org/6.7/userguide/viewing_debugging_dependencies.html#sub:resolving-unsafe-configuration-resolution-errors for more details.
The configuration :bom:classpath was resolved without accessing the project in a safe manner. This may happen when a configuration is resolved from a different project. This behaviour has been deprecated and is scheduled to be removed in Gradle 7.0. See https://docs.gradle.org/6.7/userguide/viewing_debugging_dependencies.html#sub:resolving-unsafe-configuration-resolution-errors for more details.
The configuration :bom:default was resolved without accessing the project in a safe manner. This may happen when a configuration is resolved from a different project. This behaviour has been deprecated and is scheduled to be removed in Gradle 7.0. See https://docs.gradle.org/6.7/userguide/viewing_debugging_dependencies.html#sub:resolving-unsafe-configuration-resolution-errors for more details.
The configuration :dependencies:archives was resolved without accessing the project in a safe manner. This may happen when a configuration is resolved from a different project. This behaviour has been deprecated and is scheduled to be removed in Gradle 7.0. See https://docs.gradle.org/6.7/userguide/viewing_debugging_dependencies.html#sub:resolving-unsafe-configuration-resolution-errors for more details.
The configuration :dependencies:classpath was resolved without accessing the project in a safe manner. This may happen when a configuration is resolved from a different project. This behaviour has been deprecated and is scheduled to be removed in Gradle 7.0. See https://docs.gradle.org/6.7/userguide/viewing_debugging_dependencies.html#sub:resolving-unsafe-configuration-resolution-errors for more details.
The configuration :dependencies:default was resolved without accessing the project in a safe manner. This may happen when a configuration is resolved from a different project. This behaviour has been deprecated and is scheduled to be removed in Gradle 7.0. See https://docs.gradle.org/6.7/userguide/viewing_debugging_dependencies.html#sub:resolving-unsafe-configuration-resolution-errors for more details.
The configuration :submodule1:annotationProcessor was resolved without accessing the project in a safe manner. This may happen when a configuration is resolved from a different project. This behaviour has been deprecated and is scheduled to be removed in Gradle 7.0. See https://docs.gradle.org/6.7/userguide/viewing_debugging_dependencies.html#sub:resolving-unsafe-configuration-resolution-errors for more details.
The configuration :submodule1:archives was resolved without accessing the project in a safe manner. This may happen when a configuration is resolved from a different project. This behaviour has been deprecated and is scheduled to be removed in Gradle 7.0. See https://docs.gradle.org/6.7/userguide/viewing_debugging_dependencies.html#sub:resolving-unsafe-configuration-resolution-errors for more details.
The compile configuration has been deprecated for resolution. This will fail with an error in Gradle 7.0. Please resolve the compileClasspath configuration instead. Consult the upgrading guide for further information: https://docs.gradle.org/6.7/userguide/upgrading_version_5.html#dependencies_should_no_longer_be_declared_using_the_compile_and_runtime_configurations
The configuration :submodule1:compile was resolved without accessing the project in a safe manner. This may happen when a configuration is resolved from a different project. This behaviour has been deprecated and is scheduled to be removed in Gradle 7.0. See https://docs.gradle.org/6.7/userguide/viewing_debugging_dependencies.html#sub:resolving-unsafe-configuration-resolution-errors for more details.
The configuration :submodule1:compileClasspath was resolved without accessing the project in a safe manner. This may happen when a configuration is resolved from a different project. This behaviour has been deprecated and is scheduled to be removed in Gradle 7.0. See https://docs.gradle.org/6.7/userguide/viewing_debugging_dependencies.html#sub:resolving-unsafe-configuration-resolution-errors for more details.
The compileOnly configuration has been deprecated for resolution. This will fail with an error in Gradle 7.0. Please resolve the compileClasspath configuration instead. Consult the upgrading guide for further information: https://docs.gradle.org/6.7/userguide/upgrading_version_5.html#dependencies_should_no_longer_be_declared_using_the_compile_and_runtime_configurations
The configuration :submodule1:compileOnly was resolved without accessing the project in a safe manner. This may happen when a configuration is resolved from a different project. This behaviour has been deprecated and is scheduled to be removed in Gradle 7.0. See https://docs.gradle.org/6.7/userguide/viewing_debugging_dependencies.html#sub:resolving-unsafe-configuration-resolution-errors for more details.
```

The full example is included as an attachment, but to show the main configuration that leads to the issue, let me show how it's configured:

The java-platform module called `dependencies` that works as a BOM for the whole project basically looks like this:
```groovy
javaPlatform {
// allows importing other platforms/BOMs in a java-platform project
allowDependencies()
}

dependencies {
// First, import other BOMs
//-------------------------
api enforcedPlatform(project(':bom')) // BOM declaring just our modules, without the other dependencies

// Second, define custom constraints (i.e. dependency management)
//---------------------------------------------------------------
constraints {
api 'com.github.spotbugs:spotbugs-annotations:3.1.12'
api 'javax.servlet:javax.servlet-api:3.1.0'
}
}
```
Note those `api` dependencies under `constraints`.

Then we have a submodule's `build.gradle` file that specifies dependencies on those APIs:
```groovy
dependencies {
compileOnly 'com.github.spotbugs:spotbugs-annotations'
compileOnly 'javax.servlet:javax.servlet-api'
}
```

I don't want to post the whole contents of the main `build.gradle` (see it in the attachment), but just to show how the `dependencies` platform is enforced on submodules, here's the excerpt that does that:
```groovy
// ...

// configure java libraries
configure([
project(':submodule1'),
// ...
]) {
apply plugin: 'java-library'

dependencies {
api enforcedPlatform(project(':bom'))
api enforcedPlatform(project(':dependencies'))
}

// ...
}
```

A workaround for this issue is to specify the version of such `compileOnly` dependencies directly in the `build.gradle` file of each submodule that declares them, but that destroys the purpose of the platform (aka BOM) modules.

[cyclonedx-gradle-issue.zip](https://github.com/CycloneDX/cyclonedx-gradle-plugin/files/5546861/cyclonedx-gradle-issue.zip)

Contributor guide

Open the contributing guide

Research direction

Start by reproducing `gradle cyclonedxBom` with the attached example and inspect the `build.gradle` platform and `compileOnly` declarations in `submodule1`. Compare dependency resolution for `compileOnly` with the working `api`, `implementation`, and `runtimeOnly` cases. Done means the task resolves platform-provided versions for compile-only dependencies without requiring versions in each submodule.

Written by the indexing model from the issue text.

Assessment

Tech stack
java
Domain
build-system
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.