Can't apply plugin: maven-publish


It seems that resolving the earlib configuration in one project prevents a different project to apply the maven-publish plugin. Simply running ‘gradlew’ in the sample ploject will result in:

FAILURE: Build failed with an exception.

  • Where:
    Build file ‘C:\Devel\UFFMANNA\ws_head\gradle-maven-publish-bug\common\build.gradle’ line: 5
  • What went wrong:
    A problem occurred evaluating project ‘:common’.

Failed to apply plugin [class ‘org.gradle.api.publish.plugins.PublishingPlugin’]
Cannot add rule PublishingPlugin.Rules#tasksDependOnProjectPublicationRegistry for model element ‘tasks’ at state Initialized as this element is already at state SelfClosed.


include ‘common’, ‘server’


apply plugin: ‘java’
apply plugin: ‘maven-publish’


apply plugin: 'java’
apply plugin: ‘ear’

repositories {

dependencies {
compile project(’:common’)

earlib ‘’

// original use case
jar {
manifest {
“Class-Path”: configurations.earlib.files*.name.join(’ ')

// Simplified version
println configurations.earlib.files*.name.join(’ ') (52.8 KB)

(Stefan Oehme) #2

You are resolving dependencies during the configuration phase, which is too early and leads to your problem.

The manifest attributes are computed lazily by calling their toString() method. So you can do something like

jar {
  manifest {
      "Class-Path": new ManifestClasspath(configurations.earlib)

class ManifestClasspath {
  Configuration configuration

  String toString() {' ')

You can also do it shorter by using the fact that Groovy’s GStrings are lazy. But it might look a little too magic:

  "Class-Path": "${configurations.earlib.files*.name.join(' ')}"

How to handle run-time dependencies

Thanks for that hint, but what does resolving the server configuration earlib have to do with applying the maven-publish plugin in the project common?

(Stefan Oehme) #4

In your common project you have this line: `evaluationDependsOn(’:server’), which will evaluate the server build script. The server build script resolves dependencies and it depends on the common project. So at that point the server project has already read the configuration of the common project. Now the control flow comes back to the common project and it tries to change the configuration. But it has already been read, which causes the error you saw.