AFAIK the Gradle build itself is not a project. I...
# community-support
a
AFAIK the Gradle build itself is not a project. I.e. I can't run
gradlew buildscript:classes
to compile it. There is no classes output dir for the build files, no sourceSetContainer for the input files. I can't run plugins like checkstyle on the build files because there are no sourcesets. I was just wondering why that is - surely it would be easier on Gradle if build file compilation operated in the same way as project compilation? And easier on IDEs to extract all that info. Users could even modify this meta-build to ensure things like JDK 8 compatibility, treat warnings as errors etc.
v
surely it would be easier on Gradle if build file compilation operated in the same way as project compilation?
I doubt that this is the case. Especially as the build scripts are not normal Kotlin files, but Kotlin Script files with special Gradle support and so on. The files are compiled and the
class
files kept somewhere, but that is more an implementation detail. If you want to suggest improvements there, I suggest you open a feature request on GitHub to see what the Gradle folks think about it, but to be honest, I doubt this will change. Things like "JDK 8 compatibility" and so on are not something you should care about, as it is Gradle's responsibility that this works properly with all Java versions it supports. Btw. specifying compiler options for buildscript compilation is requested at https://github.com/gradle/gradle/issues/24221 Treating warnings as errors should already be available since 8.2 explicitly added by https://github.com/gradle/gradle/issues/24530 so to get that, just add
org.gradle.kotlin.dsl.allWarningsAsErrors=true
to your
gradle.properties
if you are on Gradle 8.2+.
a
Thanks Vampire. I was more just curious about why the design is like it is. Other build tools I've seen treat the build as just another project they have to build. In terms of "JDK 8 compatibility" - I can change the build script on a JDK 21 machine so it would use JDK methods that don't exist on JDK 8, then it would fail on a CI machine that used JDK 8 and I can't see a way to prevent that. I don't think I can specify toolchain JDK 21 for the build script? On another note, do you see (eventually) a complete move away from kotlin and groovy build scripts towards declarative Gradle where all non-declarative needs are taken care of by plugin conventions? Just asking because plugin
buildSrc
code is in a normal Gradle project with all the java/kotlin compile options and classes output dirs etc. which would almost satisfy what I was wanting.
v
On another note, do you see (eventually) a complete move away from kotlin and groovy build scripts towards declarative Gradle where all non-declarative needs are taken care of by plugin conventions?
It is already idiomatic to have the actual buildscripts as declarative as possible and have non-declarative parts in
buildSrc
or (what I prefer) an included build, it is just not enforced. But there is also the "Declarative Gradle" project which works towards a forced-declarative syntax in the buildscripts itself: https://declarative.gradle.org/
As to why design decisions were done like they were done, I have no idea, that you would ask the Gradle folks about. Maybe if Kotlin would be there from the start it would have been different, maybe not. In the beginning, there was only Groovy DSL buildscripts.
a
Hadn't thought of putting the buildSrc in an included build - presumably to share common code across all your projects - thanks for the tip.