build in Gradle 2.3 runs more tasks than in Gradle 2.2

[wilkinsona]

I'm not sure if this is entirely due to Gradle, and there's nothing we can do about it, or if our plugin's involved.

With Gradle 2.2:

$ ./gradlew build
:compileJava
:processResources UP-TO-DATE
:classes
:jar
:bootRepackage
:assemble
:compileTestJava UP-TO-DATE
:processTestResources UP-TO-DATE
:testClasses UP-TO-DATE
:test UP-TO-DATE
:check UP-TO-DATE
:build

With Gradle 2.3:

$ ./gradlew build
:compileJava UP-TO-DATE
:processResources UP-TO-DATE
:classes UP-TO-DATE
:jar
:findMainClass
:startScripts
:distTar
:distZip
:bootRepackage
:assemble
:compileTestJava UP-TO-DATE
:processTestResources UP-TO-DATE
:testClasses UP-TO-DATE
:test UP-TO-DATE
:check UP-TO-DATE
:build

Note the additional findMainClass, startScripts, distTar, and distZip tasks that have been run with Gradle 2.3

Question on StackOverflow that brought this to my attention.

[wilkinsona]

Removing Boot's plugin, and making no other changes, makes Gradle 2.3 behave the same as Gradle 2.2, i.e. it's our plugin that's causing the different behaviour. I wonder if this could be related to bootRepackage depending on the distribution tasks (#2622), although that doesn't appear to explain the behaviour change between Gradle 2.2 and 2.3.

[jeffbswope]

This appears to break builds which rely on bootRepackage.enabled = false. The :startScripts task is still queued and fails for lack of a main class.

[wilkinsona]

@philwebb I think we should tackle this in 1.2.x. Do you agree?

[philwebb]

Sounds good.

[wilkinsona]

The change is due to a change in the application plugin's behaviour between Gradle 2.2 and 2.3.

In my comment above I stated that the behaviour in Gradle 2.3 was the same as Gradle 2.2 when you removed the Spring Boot plugin. This wasn't really a fair comparison as removing the Spring Boot plugin also removed Gradle's application plugin.

Consider this build script:

apply plugin: 'application'

It fails with Gradle 2.3:

gradle build
:compileJava UP-TO-DATE
:processResources UP-TO-DATE
:classes UP-TO-DATE
:jar UP-TO-DATE
:startScripts FAILED

FAILURE: Build failed with an exception.

* What went wrong:
A problem was found with the configuration of task ':startScripts'.
> No value has been specified for property 'mainClassName'.

* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output.

BUILD FAILED

Total time: 3.124 secs

But works fine with Gradle 2.2.1:

gradle build
:compileJava UP-TO-DATE
:processResources UP-TO-DATE
:classes UP-TO-DATE
:jar
:assemble
:compileTestJava UP-TO-DATE
:processTestResources UP-TO-DATE
:testClasses UP-TO-DATE
:test UP-TO-DATE
:check UP-TO-DATE
:build

BUILD SUCCESSFUL

Total time: 3.332 secs

I'm not sure that there's anything that we can do, particularly in 1.2.x, to address this pretty fundamental change in Gradle's behaviour

[wilkinsona]

@jeffbswope You can make Gradle 2.3 happy by configuring mainClassName with any value. For example, this build script works fine:

buildscript {
    repositories {
        jcenter()
    }
    dependencies {
        classpath 'org.springframework.boot:spring-boot-gradle-plugin:1.2.2.RELEASE'
    }
}

apply plugin: 'spring-boot'

bootRepackage {
    enabled = false
}

mainClassName = 'com.foo.Bar'

You'll end up with start scripts that don't work (as they point to a non-existent main class) but, as I said above, I'm not sure what we can do about that given the change in Gradle's behaviour.

[jeffbswope]

Thanks @wilkinsona

This is entirely too bound to the specifics of the problem but also seems to work as a workaround without creating invalid start scripts:

buildscript {
    repositories {
        jcenter()
    }
    dependencies {
        classpath 'org.springframework.boot:spring-boot-gradle-plugin:1.2.2.RELEASE'
    }
}

apply plugin: 'spring-boot'

bootRepackage {
    enabled = false
}

gradle.taskGraph.whenReady { graph ->
    def badTasks = ['findMainClass', 'startScripts', 'distTar', 'distZip']
    graph.allTasks.findAll {it.name in badTasks}.each { task ->
        task.enabled = false
    }
}

The reality is that the dependency management plugin being spun off likely eliminates our need/desire to use the boot plugin with bootRepackage disabled for our libs, but have not dug into making that change yet.

[wilkinsona]

I've posted on the Gradle forum about the regression caused by the new behaviour in Gradle 2.3. Given that we have a workaround, I'd like to wait and see what the response is before deciding what, if anything, we should do about this.

[wilkinsona]

So I don't forget, I prototyped this as a solution:

project.afterEvaluate {
    if (!project.plugins.hasPlugin(ApplicationPlugin)) {
        project.plugins.apply(ApplicationPlugin)
        project.tasks.withType(CreateStartScripts) { CreateStartScripts task ->
            task.enabled = false
        }
    }
}

The idea was to switch off the problematic pieces of the application plugin unless the user has explicitly applied the application plugin. I'm not sure it's a good solution, but it did get the build working.

[stuartstevenson]

Can I ask why there is a dependency on the application plugin? It makes assumptions about how the distributions plugin works, that means that an app using the spring-boot gradle plugin has to also inherit the immutable CopySpec from the application plugin, and cannot create it's own unique distributions.

There is an outstanding pull request to make this configurable: gradle/gradle#264.

Would it be actually be better to find a way to remove the dependency to reduce coupling and hidden behaviours?