Failed to apply plugin class 'org.gradle.api.publish.plugins.PublishingPlugin'

Help/Discuss
1

I have a multi-project configuration that has many libraries in it, some that I publish to our local Nexus.

I am in the process of converting our Gradle scripts to Kotlin and to using our company wide compiled conventions also stored in our local Nexus server.

We have a convention for publishing libraries to Nexus which looks like this:

plugins {
    `maven-publish`
}

publishing {
    publications {
        create<MavenPublication>("maven") {
        // Details removed
        }
    }

    repositories {
        maven {
            url = uri( "https://nexus.details.removed" )

            credentials {
            // Details removed
            }
        }
    }
}

In some of the libraries, not all, if I include this convention I get an error:

An exception occurred applying plugin request [id: 'my.company.conventions.publish-convention']
> Failed to apply plugin class 'org.gradle.api.publish.plugins.PublishingPlugin'.
   > Project#afterEvaluate(Action) on project ':UtilityDb' cannot be executed in the current context.

If I simply include the maven-publish plugin I still get a similar error:

Failed to apply plugin class 'org.gradle.api.publish.plugins.PublishingPlugin'.
> Project#afterEvaluate(Action) on project ':UtilityDb' cannot be executed in the current context.

Here are a few scans if they help:
https://scans.gradle.com/s/7beujpur47fw6
https://scans.gradle.com/s/dga5attgb6l7q
https://scans.gradle.com/s/7beujpur47fw6

2

What is line 20 (and around) in the build script?

3

I’m not sure which build.gradle.kts file you mean but the one in buildSrc has this at line 20:

allprojects.forEach {
    project -> project.tasks.withType<JavaCompile> {
        val compilerArgs = options.compilerArgs
        compilerArgs.add("-Xlint:unchecked")
        compilerArgs.add("-Xlint:deprecation")
        options.encoding = "UTF-8"
    }
4

I’ve now realised that in the process of converting from groovy to kotlin this should have been moved to a different build script but commenting it out does not fix the problem.

5

The builds are already past building buildSrc and buildSrc also is not published. So while you have shown highly discouraged bad-practice code, it is from the only file that is uninteresting.

Which of the other build scripts I cannot tell you as the stack traces only contain the script name, not the path. That’s one of various reasons I would never call multiple files in the same build build.gradle or build.gradle.kts. (The name is configurable in the settings script)

6

Thanks for the tip. It helped to rename all the build.gradle.kts files. I was able to pinpoint the problem. It was failing on this:

tasks.jar {
    manifest {
        attributes["Class-Path"] = configurations.runtimeClasspath.get().joinToString { "lib/" + it.getName() }
    }
}

If I change it to this it works

var classpath = configurations.runtimeClasspath.get().joinToString { "lib/" + it.getName() }

tasks.jar {
    manifest {
        attributes["Class-Path"] = classpath
    }
}

The error was not occuring in the Gradle file containing maven-publish but in a Gradle file that had a dependency on a project containing maven-publish. Something about looping through the runtimeClasspath when a dependent library has the maven-publish plugin applied to it??
Is there a better way to gather runtime library information for use in the manifest?

7

What the exact reason is that it is failing might be a bit trickier and I cannot tell without seeing the full build.

But your new version also is problematic.
If after that line anyone is trying to change the contents of the runtimeClasspath it will now fail, as you resolve the runtimeClasspath directly in that line and thus lock it against any further modification.

Just do for example after that line a dependencies { implementation("commons-io:commons-io:+") } and I think it will bail and error-out.

Is there a better way to gather runtime library information for use in the manifest?

Imho, don’t do it at all.
Use the application plugin to build a proper distribution instead that then contains start scripts for *nix and Windows that properly call Java with properly assembled classpath or modulepath and also takes the usual JAVA_HOME environment variable into account.

8

Ok. It’s not my project. I’m just trying to convert it. I’ll give it a go.

1 Like