This message was deleted.
# community-support
s
This message was deleted.
c
I'm attempting to extract publishing configuration, but when I place the code in a
publishing.gradle.kts
I lose access to things like the version catalogue and I'm unable to apply plugins. I'm importing the script by using:
apply(from = "$rootDir/publishing.gradle.kts")
a
easy peasy - convention plugins! 1. create
buildSrc/build.gradle.kts
(example, but the only important bit for you is the
kotlin-dsl
plugin) 2. create
buildSrc/settings.gradle.kts
(example) 3. create a convention plugin for publishing config,
buildSrc/src/main/kotlin/my-publishing-config.gradle.kts
(the name will be the plugin ID, so it helps to pick a distinctive name). You can treat it like a regular
build.gradle.kts
file, and apply the
maven-publish
plugin, and any config you want to re-use 4. now apply the convention plugin in the plugins block of each subproject
Copy code
// my-cool-subproject/build.gradle.kts

plugins {
    `my-publishing-config`
}
c
thank you Adam, I'll verify the peasiness of this solution
🤞 1
hmm I still don't seem to get access to the version catalogue though?
a
there's an open issue for that https://github.com/gradle/gradle/issues/15383, with a workaround Although personally I try to avoid specifying dependencies in convention plugins. It's usually more clear and easier to work with version specified in the build.gradle.kts of each subproject, even if it can be more repetitive.
e
☝🏾 no to repeating the versions across all buildscripts… The easiest for me is still placing the common configuration in the root project… • Adding plugins with
apply false
will bring the types into the script then • subproject { … } to configure the sub projects
a
@efemoney using
subprojects {}
(and
allprojects {}
) is usually discouraged - see the docs here, here, and here. What it boils down to composition vs inheritance.
allprojects {}
and
subprojects {}
makes Gradle configuration inherited, which in principle is fine (after all inheriting build config how Maven works, and that's a strong build tool), but generally it makes Gradle slower, harder to configure, and it's easier to make mistakes.