Apply maven-publish plugin from init script

Old Forum Archive
1

I’m attempting to apply the ‘maven-publish’ plugin to all my projects via an init script something like this

allprojects {
    apply plugin: 'maven-publish'
}

I am then attempting to configure my publications like so

configure(subprojects) {
    apply plugin: 'java'
      publishing {
        publications {
            mavenJava(MavenPublication) {
                from components.java
            }
        }
    }
}

When my build runs I get the error ‘Cannot configure the ‘publishing’ extension after it has been accessed.’. If I move the ‘apply’ statement into my build.gradle file everything works fine. Somehow applying the maven-publish plugin from an init script is initializing the extension even though I make no attempt to configure it from the init script itself.

2

Just bumping this topic to see if anyone has any ideas.

3

Sorry for a late response to this but another forum user referenced this thread so I’m having a look. Unfortunately I’m not able to reproduce. Can you please provide exact steps to reproduce? Or even better, a reproducible sample? Also, which Gradle version are you seeing this with?

4

I am suddenly unable to reproduce this as well, even going back to Gradle 1.11. I ran into this why trying to migrate a particular project to the new publishing mechanism. I’ll try and give that another go and see if I run into the same issues.

5

I’ve run into this and, based on some brief Googling, it seems to be relatively common. Here’s a build script that will fail:

buildscript {
    repositories {
        maven { url "https://oss.sonatype.org/content/groups/public"}
    }
    dependencies {
        classpath 'com.github.townsfolk:gradle-release:1.2'
    }
}
  group = "dummy"
version = "0.1-SNAPSHOT"
  apply plugin: 'java'
  apply plugin: 'maven-publish'
apply plugin: 'release'
  publishing {
    publications {
        mavenJava(MavenPublication) {
            from components.java
        }
    }
}

Swap the apply order of the ‘release’ and ‘maven-publish’ plugins and it’ll work. I have no idea what causes it. All I know is that the maven-publish plugin is super picky about configuration ordering.

I have tons of trouble trying to use the maven-publish plugin with any kind of release style plugin. See here for a related example (which really needs a JIRA issue):

http://forums.gradle.org/gradle/topics/maven_publish_and_dynamically_setting_the_version_results_in_build_failure?rfm=1

6

Ryan,

Please be aware that maven-publish plugin is incubating (as noted in the documentation of the plugin at http://www.gradle.org/docs/current/userguide/publishing_maven.html). Unfortunately it currently doesn’t handle more complex use cases too well and is indeed sensitive to the order of configuring things in your project. I can explain exactly why maven-publish and release plugin are not playing together nicely but don’t know if you’re interested in the technicalities.

For the time being you’re probably better off using the “old” maven plugin: http://www.gradle.org/docs/current/userguide/maven_plugin.html. We plan to change the internals of the new “maven-publish” plugin a lot in the coming months thus removing its limitations and feature matching it with the old plugin.

7

Hey Marcin,

Thanks for the reply. I’m glad to hear the maven-publish plugin is going to get some attention. I like the way it works. It just needs to be a little less brittle.

I wouldn’t mind knowing what’s going on with the release plugin. I’m mainly just curious since the old plugin is the most logical solution for now. I tried to follow the source code, but couldn’t figure out where the release plugin is reading the maven-publish plugin’s config (assuming that’s what’s happening). If it won’t take you too long, I’d appreciate a brief explanation. If you don’t have time, it’s not a big deal.

Thanks, Ryan

8

Cool, so this is what happens.

DefaultPublishingExtension which is backing the ‘publishing {}’ block is a DeferredConfigurable. It’s a mechanism that allows to register a configuration block to be executed when an extension is accessed. Unfortunately sometimes it causes unexpected behaviour if you access this kind of extension unawares. This is exactly the case when for example you try to get all the properties of a project (as the release plugin does here: https://github.com/townsfolk/gradle-release/blob/master/src/main/groovy/release/PluginHelper.groovy#L230).

9

Marcin, is the idea behind ‘DeferredConfigurable’ to avoid having to use methods like ‘project.afterEvaluate { }’ in your plugins? What are the best practices to follow then when writing plugins that depend on configuration from a ‘DeferredConfigurable’? How can a plugin author avoid premature evaluation of configuration block that a subsequent plugin may need to modify?

10

Mark, that’s exactly the idea behind ‘DeferedConfigurable’. Unfortunately it didn’t work out the way we wanted and we will eventually remove it. We are currently working on another mechanism to better manage the order in which things are configured. At the moment the only deferred configurable out there is ‘DefaultPublishingExtension’ used by ‘maven-publish’ plugin.

I think that it’s not possible to depend on a configuration of a ‘DeferredConfigurable’ in any deferred way other than what’s currently available (e g. ‘project.afterEvaluate {}’) because it gets locked down the moment you access it.

11

Thanks for the info, Marcin. Is there a design doc out there for the new configuration ordering mechanism?

12

Sure there is: https://github.com/gradle/gradle/blob/master/design-docs/unified-configuration-and-task-model.md, but be warned - it’s massive. :slight_smile:

13

Thanks!