Affected component: Spring Boot Gradle Plugin Affected version: 2.3.0
The recent release of Spring Boot 2.3.0 included automatic creation and configuration of the GradledevelopmentOnly configuration profile (awesome, we think!). While useful for removing the need for boilerplate configuration to support using devtools in a Spring Boot project/module, the implementation no longer allows for the old-style manual configuration at the same time (i.e. the plugin detecting and re-using an existing configuration of the same name, if present).
This breaks multi-module builds where there are a mixture of Spring Boot and non-Boot modules with common Gradle configuration (e.g. using allprojects {..} or subprojects {..}), and where the non-Boot modules also use this configuration for common development use cases. If we want to upgrade these projects to 2.3.0, we are now forced to split up and increase the complexity of our Gradle configuration.
Given the negative impact to user experience (split / more complex configuration to work around the new feature), this feels like a probably unintentional bug. Also, while we recognise supporting this notably increases the complexity of the plugin code and tests, the new feature introduced is similarly (effectively) breaking substantial amounts of pre-existing project code.
Comment From: wilkinsona
Sorry for the inconvenience.
Unfortunately, a user-configured developmentOnly configuration is unlikely to be set up in the way that is now necessary for bootJar and bootWar to have the desired contents. In other words, backing off when a developmentOnly configuration already exists is likely to result in development-only dependencies being packaged in the fat jar or war.
I think there are a few alternatives to splitting up your configuration that will hopefully make it easier to adapt to this change in a multi-module build. You may be able to use maybeCreate, or getByName and then create, when creating your configuration. Alternatively, if your own configuration was meeting your needs everywhere, you could do a global search and replace to rename it.
There may be other approaches but it’s hard to say without knowing more about your build. We can take another look if you can share an example that illustrates its structure and how it is currently configured.
Comment From: spring-projects-issues
If you would like us to look at this issue, please provide the requested information. If the information is not provided within the next 7 days this issue will be closed.
Comment From: spring-projects-issues
Closing due to lack of requested feedback. If you would like us to look at this issue, please provide the requested information and we will re-open the issue.