This message was deleted.
# community-support
s
This message was deleted.
v
dependencyResolutionManagement
can be shared via a settings plugin.
pluginManagement
comes before plugins are applied naturally, so for that you would need a custom init script and thus most probably a custom Gradle distribution. You could try with a script plugin, but I'm not sure if would work.
g
dependencyResolutionManagement
can be shared via a settings plugin
This would mean that I can't share it with itself though right (without hacks)?
You could try with a script plugin, but I'm not sure if would work.
Yeah, I was trying this but unfortunately I didn't manage to make it working
a
I regularly share the repositories with a script plugin. It’s a lot less hassle than trying to set up a settings-plugin Here’s an example using buildSrc, not included builds, but the principle is the same the script plugin: https://github.com/adamko-dev/kotka-streams/blob/main/buildSrc/repositories.settings.gradle.kts and then applied: • https://github.com/adamko-dev/kotka-streams/blob/41d75816d008226767abf8a0b896b2985369c98f/buildSrc/settings.gradle.kts#L3https://github.com/adamko-dev/kotka-streams/blob/41d75816d008226767abf8a0b896b2985369c98f/settings.gradle.kts#L13
g
Ooh I see. Makes sense. Thanks very much to you both!
👍 1
v
I regularly share the repositories with a script plugin. It’s a lot less hassle than trying to set up a settings-plugin
Here’s an example using buildSrc, not included builds, but the principle is the same
the script plugin: https://github.com/adamko-dev/kotka-streams/blob/main/buildSrc/repositories.settings.gradle.kts
That is neither a script plugin, nor less hassle than a settings plugin. It is a precompiled script plugin, that actually is a settings plugin. Please don't confuse this with a script plugin (the things you use with
apply from
) and a the settings plugin implemented as a full-fledged class. When I said "settings plugin" I didn't specify how it is implemented, whether it is via precompiled script plugin, or as class in Kotlin, or Java, or Groovy, or Scala or any other JVM language doesn't matter at all. And when I say script plugin, I really mean script plugins, not precompiled script plugins which are a completely different thing even if called similar and looking similar. 🙂
a
Sorry, I don’t follow…
Please don’t confuse this with a script plugin (the things you use with
apply from
)
but it is applied using
apply(from = ...)
? https://github.com/adamko-dev/kotka-streams/blob/41d75816d008226767abf8a0b896b2985369c98f/buildSrc/settings.gradle.kts#L3 And yes, it is a lot less hassle than a settings plugin. I’ve done that too and it’s a pain because IDE support for includedBuilds is limited and flakey, it requires multiple subprojects and trying to set all the includeBuilds in multiple files to play nicely, and debugging it is a pain because Gradle doesn’t bubble up the full errors. The script plugin I wrote is just one file + two
apply()
lines
v
but it is applied using
apply(from = ...)
?
Ah sorry, didn't look properly and was confused by you saying "in buildSrc not an included build", because those script plugins are not in anything anyway, they are just directly reference files. 🙂
and it’s a pain because IDE support for includedBuilds is limited and flakey
Well, I know that some people still have problems with them in IDE in very special situations. I use them for years and it is long ago I personally had any problem with included builds in the IDE last. 🙂 Script plugins come with their own problems, especially class-loader hassles, no way to use type-safe accessors or
plugins { ... ]
block, ..... Just for the repositories it might be ok, but I try to avoid regular script plugins wherever possible. 🙂
a
no problem - I guess the filename is confusing too. I named them like that to try and get IntelliJ to help out with auto-complete, but it doesn’t, yet... And yeah, I never write build-script plugins. But settings-scripts are usually pretty limited and don’t change much, so they’re ‘allowed’. If Gradle had some sort of pre-configured included-build equivalent for settings-plugins, ‘settingsSrc’, then I definitely wouldn’t use setting-scripts.
v
I named them like that to try and get IntelliJ to help out with auto-complete,
Would so too, and even the Gradle docs recommend that to get IDE support.
but it doesn’t, yet...
That's strange when even the docs suggest it should work. Did you add the script as "standalone script"?
If Gradle had some sort of pre-configured included-build equivalent for settings-plugins, ‘settingsSrc’, then I definitely wouldn’t use setting-scripts.
It used to have, back in time
buildSrc
was built before the settings script was evaluated and you were able to access
buildSrc
stuff from the settings script, but that was changed for some reasons. But why do you need something pre-configured? Just because you don't like composite builds? Because you just need an
includeBuild
in the plugin management block and a trivial build script that applies the
kotlin-dsl
plugin to replicate the same.