Explore the possibility of making `./gradlew build` run `bootJar` rather than `jar`

As things stand running build runs the jar task rather than bootJar. This happens because the jar task’s artifact is added to the archives configuration, assemble depends upon every task that builds an artifact in the archives configuration, and build depends upon assemble. bootJar would be run as part of build if bootJar’s artifact was added to the archives configuration, however this would have the unwanted downside of causing both the jar and the bootJar tasks to be run.

Instead of bootJar adding its output to archives it adds it to a new configuration named bootArchives. Using a separate configuration makes it easy for a project dependency to reference either the jar artifact or the bootJar artifact. It also allows the plugin to provide the uploadBootArchives task to publish a fat jar to a Maven repository. We don’t want to lose any of these capabilities.

I think the ideal would be for bootJar to somehow take the place of jar so that build, by default, would run bootJar instead of jar. We would still want the jar task to be available should anyone wish to build the project’s normal jar. We’d also, ideally, still want the separate arrangement of configurations so that the fat jar or the normal jar can be depended upon or published independently.

[wilkinsona]

After some consultation with the Gradle team (thanks again @bmuschko and @eriwen) the recommendation is to configure assemble to depend upon bootJar (or bootWar) and disable jar (or war). This will allow build to create the executable jar or war without also creating the normal jar or war. It’s also easy for a user to reverse. If they want both the standard archive and the executable archive then they can explicitly enable the jar or war task in their build script.

[wilkinsona]

@jeffbswope The couple of lines that you’ve shown above for a library will, I think, do what you want. However, if you’re building a library and just want “certain guarantees about compatibility with the Spring Boot applications inside and outside this build” then I wouldn’t apply the Spring Boot plugin at all. Instead, I’d apply the dependency management plugin and import the spring-boot-dependencies bom for the Spring Boot version with which you want to be compatible.

Something like this:

plugins {
    id "io.spring.dependency-management" version "1.0.2.RELEASE"
}

dependencyManagement {
    imports {
        mavenBom 'org.springframework.boot:spring-boot-dependencies:2.0.0.BUILD-SNAPSHOT'
    }
}