I would like to reuse those blocks (with a few more additions) in 2 convention plugins:
my-java-app
my-java-lib
So that I can easily share build configurations between all my apps and libraries.
I have a similar problem as in here:
But I wasn’t able to understand how should I proceed in my case.
In the internet, everyone is applying the Spring Boot plugins using “subprojects{}” that I know is not recommended (and for good reasons). I would like to use the convention plugins, so that I can apply those selected plugins explicitly to selected modules. I feel it’s a ubiquitous problem and there is some obvious solution I’m missing…
Not your question, but you should either way stop using the Spring Dependency Management plugin. It is a relict from times when Gradle did not support BOMs natively, by now does more harm than good, and even the maintainer of that plugin recommends to not use it anymore but instead the built-in BOM support using platform(...).
Also not your question, but I highly recommend switching to Kotlin DSL. By now it is the default DSL, you immediately get type-safe build scripts, actually helpful error messages if you mess up the syntax, and amazingly better IDE support if you use a good IDE like IntelliJ IDEA or Android Studio.
Regarding your question, if you have a plugin with apply false in the plugins block, then - as the option name suggests - the plugin is not actually applied. It is only added to the classpath. If you have a convention plugin, this is built in a separate build. so to do the same there, you just add a dependency to the build building the convention plugin.
I would like to thank you very much for such a quick and detailed help!
I will do as you suggested and stop using Spring Dependency Management plugin. In the last days, I read multiple sources and it was difficult for me to choose the proper option, but using native BOM support in Gradles definitely makes much more sense.
In short, using native BOM support in Gradle (in comparison to Spring Dependency Management plugin) is more consistent with Gradle and the only downside I see, is that overriding versions in that way takes a few more lines of code. On the other hand, it solves many other issues, especially related to sharing build configuration and using convention plugins.