Applying with GradleUp's Shadow forces local Gradle API on `compileOnly` configuration

[Jonathing]

Expected Behavior

The local Gradle API (DependencyHandler#gradleApi() should not be used under the presence of the internal flag org.gradle.unsafe.suppress-gradle-api.

Current Behavior

Attempting to suppress the usage of the local Gradle API while applying both the Plugin Publish and Shadow plugins will result in the local Gradle API being used anyway.

This is also a bug with the Shadow plugin (see GradleUp/shadow#1422), but it also needs to be fixed with this plugin (see bottom of the issue for my proposed change).

Context

Part of what the Plugin Publish plugin does to work with the Shadow plugin is remove the Gradle API from the api configuration and add it to the compileOnly configuration. This is fine and has worked for a while now, but with the ongoing work on publishing external Gradle APIs (gradle/gradle#29483), this will pose problems when trying to use a non-local Gradle API.

Additionally, the Shadow plugin already does this (see ShadowJavaPlugin#Project.configureJavaGradlePlugin) when the java-gradle-plugin plugin is applied -- a plugin which this plugin applies.

Steps to Reproduce

1. Generate a plugin project using gradle init
   • When I reproduce this bug, I used the Groovy preset and the Groovy DSL. But this bug should be present on whatever language or DSL you use.
2. Add the following to your gradle.properties file:

systemProp.org.gradle.unsafe.suppress-gradle-api=true

3. Apply com.gradle.plugin-publish to your project.
4. Apply com.gradleup.shadow to your project (latest as of writing is 9.0.0-beta13)
5. Run the dependencies task for your project, and see that the local Gradle API (marked as "unspecified") continues to exist in the compileOnly configuration.

For now, I am working around this by putting this in my build.gradle script:

afterEvaluate { project ->
    project.configurations.named(JavaPlugin.COMPILE_ONLY_CONFIGURATION_NAME) { compileOnly ->
        compileOnly.dependencies.remove project.dependencies.gradleApi()
    }
}

Your Environment

Gradle 8.14
Gradle Publish Plugin 1.3.1
GradleUp Shadow 9.0.0-beta13

Proposed Fix

Since the sources for this plugin are available as part of the Plugin Portal, I saw where this is taking place and would like to offer a quick fix for this.

In PublishTaskShadowAction.java:52, method #manipulateDependencies

private void manipulateDependencies(ConfigurationContainer configurations) {
    Dependency gradleApi = project.getDependencies().gradleApi();

    Configuration api = configurations.findByName("api");
    if (api != null) {
        api.getDependencies().remove(gradleApi);
    }

    Configuration compileOnly = configurations.findByName("compileOnly");
    if (compileOnly != null) {
        compileOnly.getDependencies().add(gradleApi);
    }
}

This can be changed to look something like this:

private void manipulateDependencies(ConfigurationContainer configurations) {
    Dependency gradleApi = project.getDependencies().gradleApi();

    Configuration api = configurations.findByName("api");
    if (api != null && api.getDependencies().remove(gradleApi)) {
        Configuration compileOnly = configurations.findByName("compileOnly");
        if (compileOnly != null) {
            compileOnly.getDependencies().add(gradleApi);
        }
    }
}

In this implementation, there will still be an attempt to remove the local Gradle API from the api configuration like usual. If the remove was successful (it was present), then continue with adding it to the compileOnly configuration.

[ljacomet]

The issue is in the backlog of the relevant team, but the existence of a workaround means it might take a while before a fix is made.

---

Indeed, the plugin publish plugin could account for this property.

[Jonathing]

Indeed, the plugin publish plugin could account for this property.

Checking the return value of api.getDependencies().remove(gradleApi) would probably be better than arbitrarily checking for the property, since it would indirectly account for other plugins that modify configurations with the local Gradle API.

[Goooler]

FYI, I addressed the fix in GradleUp/shadow#1422 to Shadow 9.0.0-rc1.

[Jonathing]

Yeah, but this issue needs to be addressed from both ends since both plugins had same behavior.

[Jonathing]

This is still not addressed as of 2.0.0.

[Goooler]

FYI, it will become compileOnly in gradle/gradle#34540.

[Jonathing]

It looks like based on this comment, there hasn't been a decision on that. compileOnly would be the best option to prevent leakage in the outgoing configuration. But that still would not change the fact that this plugin would re-add the dependency themselves.