publish-plugin: Task ':publishXXX' uses this output of task ':signPluginMavenPublication' without declaring an explicit or implicit dependency - error in Gradle 8

I started to see it on 8.0.2 (probably 8+). It is happening with tons of plugins, not only this one. And it started to happen on all plugins on Gradle 8+.

I am fixing it by myself in my DSL plugin (not tested yet) with

val signingTasks: TaskCollection<Sign> = tasks.withType<Sign>()
tasks.withType<PublishToMavenRepository>().configureEach { task ->
    task.mustRunAfter(signingTasks)
}

But I am not sure if it is a good approach as withType<Sign>() fetch eagerly all Sign tasks.

I investigated the problem further and I posted my findings here. It looks like a problem with the gradle signing plugin in combination with multiple publications which use the same input artifact.

Thanks @Legion2. I’ve updated the original issue report to mention your analysis and a workaround (as it might be useful for the other affected users).

It’s worth noting as well, by the way, I don’t think the Kotlin plugin officially supports Gradle 8 yet (https://kotlinlang.org/docs/whatsnew1820.html#gradle), so I wouldn’t be surprised if this ends up being a problem with the Kotlin plugin. I’m curious if anyone here has managed to reproduce this in a non-Kotlin project, or at least in a non-Kotlin Multiplatform project.

The reproduction that I posted above that we concluded is not GNPP’s fault (even though the issue still occurs when publishing via a GNPP task) is not an Android project. It is Kotlin multiplatform, but it doesn’t even have an Android target.

I have found it in KMP, but I don’t remember if it has android too.

Just wanted to drop an update to my previous comment in case it helps anyone (https://github.com/gradle-nexus/publish-plugin/issues/208#issuecomment-1535022566).

My project is Android and I encountered my issue which seemed similar. The previous fix I mentioned wasn’t quite right, but this was the ultimate solution I found for my Android library project. I added this publishing block in the android block of my build.gradle file and the problem went away entirely.

android {
    ...

    publishing {
        singleVariant("release")
    }
}

I found it here https://developer.android.com/reference/tools/gradle-api/7.1/com/android/build/api/dsl/Publishing and I think it might be related to the Android Gradle Plugin changes that coincided with Gradle 8 in this specific case https://developer.android.com/build/releases/gradle-plugin#8-0-0

Once this was added the publish script was able to locate components.release and the error mentioned previously did not occur.

This still smells like a bug to me, though, I find it weird that we have to manually specify that a publishing task depends on the signing of its artifacts; this should, in my opinion, be implicit. Do you have any clue on which component would be responsible for this, in order to perhaps open a ticket in the correct repo? I’m not sure whether this would be an issue with the maven-publish plugin, kotlin(-multiplatform) plugin, or elsewhere.

@YarnSphere I’m not sure, personally, I’m lagging behind the latest Gradle releases. Maybe it would be good to ask about that on the Gradle forum?

I fixed my issues by adding a dependency like the one below:

tasks.named("generateMetadataFileForReleasePublication").configure { .. }

Update: See here for the solution I found for the issue I encountered in this comment https://github.com/gradle-nexus/publish-plugin/issues/208#issuecomment-1548869188 regarding publishing my Android lib.

Original comment Our project updated to Gradle 8 and I think we are blocked on the same issue

Reason: Task ':signReleasePublication' uses this output of task ':bundleReleaseAar' without declaring an explicit or implicit dependency. This can lead to incorrect results being produced, depending on what order the tasks are executed.

    Possible solutions:
      1. Declare task ':bundleReleaseAar' as an input of ':signReleasePublication'.
      2. Declare an explicit dependency on ':bundleReleaseAar' from ':signReleasePublication' using Task#dependsOn.
      3. Declare an explicit dependency on ':bundleReleaseAar' from ':signReleasePublication' using Task#mustRunAfter.

    Please refer to https://docs.gradle.org/8.0.2/userguide/validation_problems.html#implicit_dependency for more details about this problem.

Update:

I was able to fix my build problem by adding dependsOn(':bundleReleaseAar') into a task I had in my publishing code

Removed this fix snippet because it was wrong and cut out my dependencies from the POM… oops.

Regarding https://github.com/gradle-nexus/publish-plugin/issues/208#issuecomment-1520845369, where I say:

If I’m missing something obvious and there’s a less hacky workaround please do let me know!

The less hacky workaround is simply:

nexusPublishing {
    this.repositories {
        sonatype()
    }
}

Which I find acceptable (I don’t know how I originally missed this 😅).

@szpak, I didn’t try to reproduce it with your example project, but I created a minimal reproduction with Kotlin multiplatform at: https://github.com/YarnSphere/nexus-publish-gradle-8

The issue appears when adding a Javadoc artifact to the publications and trying to sign them. In the example I create a Javadoc jar from Dokka’s output and add it as an artifact to the publications.

Running the publishToMavenLocal task should reproduce the issue.

Hope this helps! Let me know if you need something else.

Unrelated to the above but also related to Gradle 8 compatibility (at least with Gradle 8.1.1):

The repositories function is now clashing with Project.repositories from the Kotlin DSL. For now it seems to still compile, but it does show an error in the IDE. Doing something like the following fixes it (since thankfully the Project.repositories argument has a different name):

It might make sense to introduce an alias to repositories such as nexusRepositories and perhaps deprecate the former.

If I’m missing something obvious and there’s a less hacky workaround please do let me know!

I tried going over the Gradle release notes to check if this change in behaviour is mentioned anywhere but couldn’t find anything to reference. I’d appreciate if someone could find a reference as to why this is now happening.

Also, please let me know if you’d prefer that I create a new issue to track this.

Gradle 8 compatibility

For some reasons, I originally perceived it as “Java 8 compatibility”… That’s why I asked about your Gradle version…