Open felixscheinost opened 7 months ago
While I acknowledge what you are saying, I'm not sure that having these dependencies on the compile classpath of all downstream projects is the correct way to solve this.
Also, I believe the springboot
version you are referring to is not actually the one defined in the version of grails
you are using but the one defined in grails-gradle-plugin
which at the moment could be different versions.
A better way, would perhaps be if these dependencies were added to grails-bom
(or a new grails-build-bom
). Then the versions could be imported by both grails-gradle-plugin
and any grails
project that would like to use them with synced-up versions.
Regarding the change in patch release version, these dependencies were (to my understanding) never meant to be exposed, but it could not be prevented with previous versions of Gradles compile
scope and then it got changed to the unnecessarily open api
when upgrading to Gradle 7.
I don't understand the reasoning behind https://github.com/grails/grails-gradle-plugin/commit/42ba793ca27f2a6c751e53630d3d1e1313fea3e8
(Besides, this was done in a patch version of Grails and broke my build, that shouldn't happen)
My thinking:
buildSrc
.buildSrc
, it is idiomatic to have some references to e.g.org.springframework.boot.gradle.plugin.SpringBootPlugin
, e.g. for dependency managementorg.springframework.boot:spring-boot-gradle-plugin
needs to be on the compile classpath ofbuildSrc
6.1.2
, whereorg.springframework.boot:spring-boot-gradle-plugin
was stillapi
, I could do the following:I didn't have to specify versions for the other two plugins.