Skip to content
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

build config: Gradle Version Catalog + type-safe project dependencies #2884

Merged
merged 13 commits into from
Mar 17, 2023

Conversation

aSemy
Copy link
Contributor

@aSemy aSemy commented Feb 22, 2023

Depends on #2652

@aSemy aSemy marked this pull request as ready for review February 22, 2023 10:08
Copy link
Contributor

@Goooler Goooler left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good to see! We can migrate to type-safe project accessors in next PR.

kotlin-plugin = "213-1.8.10-release-430-IJ6777.52"
kotlinx-coroutines = "1.6.3"
kotlinx-html = "0.7.5"
jsoup = "1.15.3"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can inline these once-use versions.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it's best to define all the versions at the top, because it's consistent, it's easier to scan the top to see the versions, and if any versions do need to be re-used then then it's less work (personally I find editing libs.versions.toml a bit fiddly, so I try to avoid it).

Copy link
Contributor

@Goooler Goooler Mar 15, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can easy to know which versions are reused after inlining unnecessary ones, but either way.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it should be consistent - either all versions are at the top, or all of the versions are inlined, otherwise it might eventually lead to chaos. At the moment, I personally don't have any preference, so I'm fine with either approach 👍

integration-tests/build.gradle.kts Outdated Show resolved Hide resolved
kotlin-analysis/intellij-dependency/build.gradle.kts Outdated Show resolved Hide resolved
plugins/base/base-test-utils/build.gradle.kts Outdated Show resolved Hide resolved
@IgnatBeresnev IgnatBeresnev added the infrastructure Everything related to builds tools, CI configurations and project tooling label Feb 22, 2023
Copy link
Member

@IgnatBeresnev IgnatBeresnev left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Had a glance - looking good, thanks!

I'll have a closer look once #2704 gets merged and this PR is rebased onto it

gradle/libs.versions.toml Outdated Show resolved Hide resolved
kotlin-analysis/intellij-dependency/build.gradle.kts Outdated Show resolved Hide resolved
@aSemy aSemy marked this pull request as draft February 23, 2023 08:39
@IgnatBeresnev
Copy link
Member

Since there are a bunch of conflicts, proposing to merge #2652 first, it's been waiting for a while :) Hopefully shouldn't take as long

@aSemy
Copy link
Contributor Author

aSemy commented Mar 8, 2023

Since there are a bunch of conflicts, proposing to merge #2652 first, it's been waiting for a while :) Hopefully shouldn't take as long

Agreed, sounds good!

@IgnatBeresnev
Copy link
Member

The PR is ready to be rebased :) Looking forward to it!

Please, if you can, try to address copy-pasted versions that I mentioned in #2912 (comment), I assumed that we'd have the actual version strings in the toml only

@aSemy aSemy force-pushed the feat/gradle_version_catalog branch from d59d0eb to 4f49425 Compare March 14, 2023 18:36
rootProject.name = "dokka"

pluginManagement {
includeBuild("build-logic")
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I moved includeBuild into the plugins block as recommended

You may also use the includeBuild mechanism outside pluginManagement to include plugin builds. However, this does not support all use cases and including plugin builds like that might be deprecated in a future Gradle version.

I also moved the repository definitions to be above plugins block, since logically the repos should be defined before plugins are resolved - but that's not important and I can revert if you want.

Copy link
Contributor

@Goooler Goooler Mar 15, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I moved it out cause I noticed detekt/detekt#5690.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hm. We don't use configuration cache in this project, do we? So we don't have the warning yet, but it might resurface one day

I don't mind leaving it as is, we can deal with the warning when we get it, but if you do move it out - please add a comment why

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Make sense.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think the warning in detekt/detekt#5690 is about configuration cache, it's about the (configuration of) build cache.

https://github.com/detekt/detekt/blob/b07acae2b5ce2d5c8e8216a4e3e022f89c5fa67f/settings.gradle.kts#L71-L84

But Dokka doesn't have that (JetBrains really should set up a Gradle Build Cache server though!)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

JetBrains really should set up a Gradle Build Cache server though!

JFYI we actually have a JetBrains instance for Gradle Enterprise (ge.jetbrains.com), but it didn't look like it using it would benefit us in any way compared to what we have now. If there's some really cool things that can be done with it that will work with Dokka, we can switch to it, no problem

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If there's public, read-only access to the JetBrains Gradle build cache server then that would definitely help! It means that everyone's builds would be faster.

https://docs.gradle.org/current/userguide/build_cache.html#sec:build_cache_configure_remote

@aSemy aSemy marked this pull request as ready for review March 14, 2023 19:53
@aSemy aSemy requested review from Goooler and IgnatBeresnev and removed request for IgnatBeresnev and Goooler March 14, 2023 19:58
Copy link
Contributor

@Goooler Goooler left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good to see this, both version catalog and type-safe project accessors!
We can rename this PR's title to something like "Migrate to type-safe dependency accessors"?

kotlin-plugin = "213-1.8.10-release-430-IJ6777.52"
kotlinx-coroutines = "1.6.3"
kotlinx-html = "0.7.5"
jsoup = "1.15.3"
Copy link
Contributor

@Goooler Goooler Mar 15, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can easy to know which versions are reused after inlining unnecessary ones, but either way.

Copy link
Member

@IgnatBeresnev IgnatBeresnev left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great to see, as always!

The main integration tests are failing, could you please fix it? I'll run longer integration tests after that

runners/gradle-plugin/build.gradle.kts Outdated Show resolved Hide resolved
@aSemy aSemy changed the title build config: define dependency versions in Gradle Version Catalog build config: Gradle Version Catalog + type-safe project dependencies Mar 16, 2023
# Conflicts:
#	gradle.properties
#	runners/maven-plugin/build.gradle.kts
- re-use Maven versions from version-catalog
- update naming to be more consistent

compileOnly("org.jetbrains.kotlin:kotlin-gradle-plugin")
compileOnly("com.android.tools.build:gradle:4.0.1")
compileOnly(gradleKotlinDsl())
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I removed compileOnly(gradleKotlinDsl()) because it's added by the kotlin-dsl plugin

@IgnatBeresnev
Copy link
Member

IgnatBeresnev commented Mar 16, 2023

Triggered teamcity integration tests, can be merged once they pass

upd: some failed :(

aSemy and others added 3 commits March 16, 2023 17:31
helps with compatibility with older Kotlin versions, probably not needed once support for Kotlin 1.4 is dropped

Co-authored-by: Ignat Beresnev <[email protected]>
@IgnatBeresnev
Copy link
Member

Looks like all the tests passed, merging it now 🎉

Thank you for this huge amount of work!

@IgnatBeresnev IgnatBeresnev merged commit 8bb4f4a into Kotlin:master Mar 17, 2023
@aSemy aSemy deleted the feat/gradle_version_catalog branch April 17, 2023 13:32
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
infrastructure Everything related to builds tools, CI configurations and project tooling
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants