Okay, I finally got a working project with version...
# gradle
a
Okay, I finally got a working project with version catalogs and precompiled scripts plugins for my personal projects. There were some weird things though: • when adding the plugins in the
buildSrc
, because I needed them in the precompiled scripts, I needed to add them to the
implementation
block. However this resulted in the fact that they were on the classpath in the other projects as well and there I only needed to apply them when needed. This felt a bit weird, but writing it out it makes sense I think.... but it is not something I did before. Normally I would define the plugins in the root
build.gradle.kts
with the
apply
set to
false
• IntelliJ IDE autocomplete and code-highlighting is terribly broken in the plugins. The only cure was restarting the IDE a lot of times. This made development a bit hard. I have the latest IDE. • Getting the plugins from the version-catalog in the
implementation
of the the
buildSrc
I had to do weird string interpolation and separate getting of the plugin-id and plugin-version. However, I learned a lot I think, but Gradle is still a very complicated powerful beast for me. I have the working repository here: https://github.com/avwie/kotlinx Maybe if some people have some comments on how to do it better I'd like to know.
👍 1
p
The definition of the Plugins in the build.gradle.kts of the buildSrc is really not the straight forward way. In my projects I add the necessary plugins in the [library] section of the libs.versions.toml to not need to do the string operations when defining them. What is the reason to not migrate the convention plugins to own submodule?
a
I thought so. The reason to not migrate is just not knowing that that is the convention. That's why I ask it here 😉
a
defining plugin versions in
buildSrc/build.gradle.kts
this is my preferred way of defining plugins! It means that I can apply the plugins in convention plugins, or directly in projects, without versions - and they will always be aligned.
IntelliJ IDE autocomplete and code-highlighting is terribly broken in the plugins
it’s gotten better recently, but yes, it still fails a lot. Could you add a link to your project to this ticket so it can be investigated? https://youtrack.jetbrains.com/issue/KTIJ-19446
Getting the plugins from the version-catalog in the
implementation
of the the
buildSrc
I prefer defining the Maven coordinates of a plugin, not the plugin ID, in
libs.versions.toml
- it’s much more simple. the
[plugins]
block isn’t so useful for buildSrc
p
this is my preferred way of defining plugins! It means that I can apply the plugins in convention plugins, or directly in projects, without versions - and they will always be aligned.
The same you can do if defining the convention plugin in submodule and include by "includeBuild(...)" in your settings.build.gradle.kts
a
What would be the benefit of this?
buildSrc
is just the default
includeBuild
.
p
As to the documentation it's planed to make buildSrc an included build, but not done yet (see https://docs.gradle.org/current/userguide/composite_builds.html).
a
there’s some sort of drawback where if you make a change in buildSrc, then buildSrc must be recompiled, and then Gradle must do a full rebuild of all the build config. In theory an included-build is more isolated, so that full rebuild isn’t required. I think it’s a pretty tenuous reason to convert from buildSrc to included-build. How often does buildSrc change? Not a lot. And even if a full rebuild is required, for most projects it’s usually not a heavy hit. Meanwhile, included-build plugins are slightly less well supported by IntelliJ, and can be much more fiddly to set up, which is much more annoying than a slower build. If you’ve got a Gradle project with 10's of subprojects, and lots of different conventions, and everyone’s very Gradle-savvy… then maybe it’s worth it?
a
Well, I tried refactoring it and it was easy. TBH it looks a bit cleaner now as well.
p
Absolutely true, moving the convention plugins to own module is just an other option, als already mentioned it does not give me that game changing advantage.
229 Views