-
Notifications
You must be signed in to change notification settings - Fork 419
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Move plugin version management to buildSrc/build.gradle.kts #1321
Conversation
repositories { | ||
exclusiveContent { | ||
forRepository { | ||
gradlePluginPortal() | ||
} | ||
filter { | ||
pluginVersions.forEach { includeVersion(it.group!!, it.name, it.version!!) } | ||
} | ||
} | ||
jcenter() | ||
maven("https://dl.bintray.com/kotlin/kotlin-eap/") { | ||
content { | ||
includeGroupByRegex("^org\\.jetbrains\\.(anko|dokka|kotlin|kotlinx)(\\..+)?$") | ||
} | ||
} | ||
maven("https://dl.bintray.com/kotlin/kotlin-dev/") { | ||
content { | ||
includeGroupByRegex("^org\\.jetbrains\\.(anko|dokka|intellij|kotlin|kotlinx)(\\..+)?$") | ||
} | ||
} | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here, I added an exclusiveContent
rule for the plugins to only be taken from gradlePluginPortal()
and some regex rules for kotlin-eap
and kotlin-dev
to avoid unnecessary requests to those repos.
This could be replaced by some more elaborate logic in buildSrc/src/main/kotlin
that could then be reused in any other Gradle buildscript in the project (except buildSrc/buildSrc/build.gradle.kts
).
de135ce
to
4397c96
Compare
Thank you for the effort! Sorry it hasn't been addressed properly. I'll close this PR in favour of #2704, there's quite a bit of refactoring, including the move of plugin version management to buildSrc. |
While researching a similar issue, I recently came across gradle/gradle#11090 (comment) (cc @sellmair ) about how the
pluginManagement{}
block insettings.gradle.kts
can't access logic defined inbuildSrc
.So I thought I'd share how I'm trying to solve that problem in some of my projects. Just in case this could be useful for this project, too.
There are two parts to this solution:
There is a second
buildSrc
project inside the existingbuildSrc
project. It only contains a shortbuild.gradle.kts
script and just compiles the sources of the firstbuildSrc
project one additional time, so those classes are on the classpath ofbuildSrc/build.gradle.kts
.At the moment this is not utilized in this pull request, but you could then add build logic to
buildSrc/src/main/kotlin
that can be reused in the buildscript ofbuildSrc
for e.g. plugin version management.This may sound like a hack, but in my experience this works pretty reliably.
The plugin versions are defined in
buildSrc/build.gradle.kts
asdependencies.implementation("‹…›")
instead of using thepluginManagement{}
block insettings.gradle.kts
.This gets rid of version inconsistencies like
dokka/settings.gradle.kts
Line 31 in b19ce3c
dokka/buildSrc/build.gradle.kts
Line 11 in b19ce3c
Also subprojects can then no longer declare conflicting plugin versions like
dokka/settings.gradle.kts
Line 32 in b19ce3c
dokka/runners/gradle-plugin/build.gradle.kts
Line 6 in b19ce3c
Plugin request for plugin already on the classpath must not include a version
.