Skip to content

Don't apply Spring Boot's plugin to the library project #40

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wilkinsona opened this issue Feb 6, 2021 · 4 comments
Closed

Don't apply Spring Boot's plugin to the library project #40

wilkinsona opened this issue Feb 6, 2021 · 4 comments

Comments

@wilkinsona
Copy link
Contributor

The guide currently applies Boot's Gradle plugin to the library project and then disables the bootJar task but that's not what we recommend. Instead, it should just use Boot's dependency management in the library project. Boot's documentation describes how to do this.

@C-Otto
Copy link

C-Otto commented Feb 7, 2021

Please also mention how to achieve this for (convention) plugins. In my case I'm using plugins { id = 'myproject-library-convention' } to pull in all the configurations and plugin details that are common for library subprojects in my project (such as having integration tests, coverage checks, java version, ...).

The boot dependencies and features work if I add id 'org.springframework.boot' version '2.4.2' apply false to my library subproject's build.gradle, but as soon as I add id 'org.springframework.boot' apply false to my convention plugin myproject-library-convention.gradle the build fails with Failed to calculate the value of task ':library-subproject:bootJar' property 'mainClass'.. I believe the bootJar property should not exist as the boot plugin is never enabled.

More about convention plugins: https://docs.gradle.org/current/samples/sample_convention_plugins.html#compiling_convention_plugins
My toy project (without Spring Boot!) that uses convention plugins: https://github.com/C-Otto/playground

@wilkinsona
Copy link
Contributor Author

IMO, conventions plugins are out of the scope of this guide. They're really just an encapsulation of logic that could be written in a build.gradle so the recommendations in this guide (once updated) should equally apply when wrapped up in a conventions plugin.

@dsyer dsyer closed this as completed in 0addd22 Sep 10, 2021
@tomasAlabes
Copy link

@C-Otto @wilkinsona this happened to me today with 3.1.5.
My convention plugin is defined by this:

plugins {
    id("org.springframework.boot") apply false
    id("io.spring.dependency-management")
}
ext["snakeyaml.version"] = "2.2"
dependencyManagement {
  imports{
        mavenBom(org.springframework.boot.gradle.plugin.SpringBootPlugin.BOM_COORDINATES)
  }
}

With this implementation dependencies for the convention plugins:

implementation("org.springframework.boot:spring-boot-gradle-plugin:3.1.5")
implementation("io.spring.gradle:dependency-management-plugin:1.1.3")

The parent project has the boot plugin applied, all the subprojects use this convention plugin. But all subprojects had the bootJar task and failed looking for the main class.
I tried overriding the plugin in different ways but I couldn't. I ended up pointing to org.springframework.boot:spring-boot-dependencies:3.1.5 in mavenBom to remove the plugin.

@dgallego58
Copy link

i did it as @tomasAlabes did, have one convention plugin but the apply false does not disable the bootJar task so it fails when there is no MainClass in another module , how would be a way to make a multimodule project (with convention plugin) when you are doing for example a library but wants to use the dependency management?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants