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

Modernize build #678

Merged
merged 47 commits into from Feb 4, 2023
Merged

Modernize build #678

merged 47 commits into from Feb 4, 2023

Conversation

ZacSweers
Copy link
Collaborator

@ZacSweers ZacSweers commented Jan 13, 2023

Highlights

  • Gradle 7.6
  • Switch to using version catalogs
  • Modernize gradle build bits using things like pluginManagement, dependencyResolutionManagement, etc.
  • Use Java 11 for integration and samples
    • Necessary because of Dagger using the Java 11+ Generated annotation even though the release target is 8. Figure this is more or less ok but lmk if you want to do something different.
  • Compile/target SDK 33
  • Use plugins {} syntax in gradle
  • Update Actions CI for new override pattern. Overrides are set from env vars in settings.gradle files.
  • Update maven publishing plugin
  • Testing previews requires the anvil.allowSnapshots gradle property.

@ZacSweers ZacSweers changed the title Modernize build (WIP) Modernize build Jan 13, 2023
@ZacSweers ZacSweers marked this pull request as ready for review January 13, 2023 22:22
build.gradle Show resolved Hide resolved
gradle/wrapper/gradle-wrapper.properties Show resolved Hide resolved
.github/workflows/ci.yml Outdated Show resolved Hide resolved
gradle/libs.versions.toml Show resolved Hide resolved
versionCatalogs {
libs {
// TODO remove this once the dirs aren't symlinked anymore
Copy link
Member

Choose a reason for hiding this comment

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

Does this mean remove the commented out from(files line, the if (System.getenv("DEP_OVERRIDES") == "true") block, or something else? Could use a little more explicitness on the comment.

Also, are we not able to remove the symlinks now?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

ah no it means uncomment it and use that instead of symlinks. Wanted to reduce churn in this PR though, but I can give it a try if you want

Copy link
Collaborator

Choose a reason for hiding this comment

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

Why do the symlinks need to be removed? I don't want to manage the gradle wrapper twice.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

With version catalogs you could actually start using Renovate and let it handle updates like that for you. Gradle in general really doesn't like symlinks. I can leave it in place and remove the comment if you want though

build.gradle Show resolved Hide resolved
settings.gradle Outdated Show resolved Hide resolved
integration-tests/library/build.gradle Show resolved Hide resolved
gradle-plugin/build.gradle Outdated Show resolved Hide resolved
@@ -136,7 +136,6 @@ internal open class AnvilPlugin : KotlinCompilerPluginSupportPlugin {
if (variant.variantFilter.syncGeneratedSources) {
val isIdeSyncProvider = project.providers
.systemProperty("idea.sync.active")
.forUseAtConfigurationTime()
Copy link
Member

Choose a reason for hiding this comment

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

Does this not need to be replaced by a new api call?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Nope, this API was deprecated and there is no replacement necessary. Gradle implemented a different solution for tracking these because frankly this API sucked

Copy link
Collaborator

Choose a reason for hiding this comment

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

This change has a side-effect. You now require all consuming projects to use the latest Gradle version. That's why it stayed there for so long.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

It was deprecated in Gradle 7.4 though, which is quite old now. Does that seem ok?

Copy link
Member

Choose a reason for hiding this comment

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

If it's deprecated and there's not equivalent replacement or workaround from Gradle then removing it seems reasonable. But we should verify the new behavior and add a note in the changelog if that new restriction exists now.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

There's no replacement necessary. Little bit of background - to support configuration cache, Gradle wanted to capture used system properties as a part of the cache key. Initially, they made this work by requiring any properties read at configuration-time to use forUseAtConfigurationTime() to make that explicit to gradle. This was super awkward and tedious for users though, so gradle deprecated this API and instead now tracks this automatically via internal mechanism rather than needing explicit opt-in like that API.

Copy link
Collaborator

@vRallev vRallev left a comment

Choose a reason for hiding this comment

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

This PR is much bigger than I anticipated. I'm really not a fan of mixing the migration to a .toml file with upgrading AGP and Gradle. This should have been a separate PR for each. Now, if all these commits are squashed it's not possible to revert one or the other anymore. Would it be possible to separate these things? I'm almost afraid to say that almost every bullet point from the PR message should have been a separate PR. At the moment I can't tell if something will break, there are just too many changes at once.

Other than it's unclear to me how the overrides now work. I asked this with a comment inline as well.

build.gradle Outdated Show resolved Hide resolved
//
// Caused by: groovy.lang.MissingPropertyException: Could not set unknown property 'jvmTarget' for object of type org.jetbrains.kotlin.gradle.tasks.internal.KotlinMultiplatformCommonOptionsCompat.
jvmTarget = JavaVersion.VERSION_1_8
tasks.withType(KotlinCompile).configureEach {
Copy link
Collaborator

Choose a reason for hiding this comment

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

I hate imports in build.gradle files. Often enough when the import is not needed anymore it stays around. I liked the old way better.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

wait does spotless not clear unused imports in your build files?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I guess this project doesn't have spotless enabled for groovy files

build.gradle Outdated Show resolved Hide resolved
build.gradle Show resolved Hide resolved
build.gradle Show resolved Hide resolved
gradle/libs.versions.toml Show resolved Hide resolved
gradle/libs.versions.toml Outdated Show resolved Hide resolved
@@ -0,0 +1 @@
kotlin.mpp.androidSourceSetLayoutVersion=2
Copy link
Collaborator

Choose a reason for hiding this comment

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

Nice!

gradle/libs.versions.toml Show resolved Hide resolved
.github/workflows/ci.yml Outdated Show resolved Hide resolved
buildSrc/settings.gradle Outdated Show resolved Hide resolved
@ZacSweers
Copy link
Collaborator Author

Updated per our chat in kotlin-lang, now it uses system props and you can override by using the -Doverride_{toml version}=<version> syntax

./gradlew tasks -Doverride_kotlin=1.7.22

# false, then we run each test with one annotation instead of all options. We also skip tests
# that run the Dagger annotation processor (KAPT is slow).
config-fullTestRun = "true"
config-generateDaggerFactoriesWithAnvil = "true"
Copy link
Member

Choose a reason for hiding this comment

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

It looks like there are two more references to the old property for this that need to be updated, in compare_size.sh

Copy link
Member

@JoelWilcox JoelWilcox left a comment

Choose a reason for hiding this comment

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

:bless:

@@ -6,6 +6,9 @@

### Changed

- Raise minimum AGP version to 7.1.0.
- The Kotlin Gradle Plugin (both the core plugin and the API artifact) are no longer a dependency of the Anvil Gradle Plugin. Instead, it's now a `compileOnly` dependency, allowing the plugin to defer to whatever version the user already has. If you were accidentally depending on KGP through Anvil, you'll need to explicitly add the plugin yourself now.

Copy link
Collaborator

Choose a reason for hiding this comment

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

👍🏻

| api deps.dagger2.dagger
| kapt deps.dagger2.compiler
| api libs.dagger2
| kapt libs.dagger2.compiler
Copy link
Collaborator

Choose a reason for hiding this comment

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

I'd still like to change this.

plugins {
alias(libs.plugins.kotlin.jvm)
alias(libs.plugins.mavenPublish)
id 'java-test-fixtures'
Copy link
Collaborator

Choose a reason for hiding this comment

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

In general with Gradle, this is painful to read 😅


// So Gradle stops complaining about the missing dependency
tasks.named("runKtlintCheckOverTestSourceSet").configure {
it.dependsOn generateBuildProperties
Copy link
Collaborator

Choose a reason for hiding this comment

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

I believe a mustRunAfter is good enough here. The benefit is that it doesn't make the other task run unnecessarily, but still teaches Gradle about the ordering.

@vRallev vRallev merged commit 66e3155 into square:main Feb 4, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants