fix(build): migrate kotlinOptions to compilerOptions DSL for KGP 2.3 compatibility#111
Open
bwised wants to merge 1 commit into
Open
fix(build): migrate kotlinOptions to compilerOptions DSL for KGP 2.3 compatibility#111bwised wants to merge 1 commit into
bwised wants to merge 1 commit into
Conversation
…compatibility
When this adapter is consumed by a Kotlin Gradle Plugin 2.3+ build (such
as the monorepo it is included in), the legacy `kotlinOptions { jvmTarget
= "17" }` block fails to evaluate — KGP 2.3 raises that DSL from a
deprecation warning to a compile-time error. Standalone builds on the
pinned KGP 1.9.21 are unaffected today but would inherit the same error
on any future bump.
Migrate to the project-level `kotlin { compilerOptions { jvmTarget.set(
JVM_17) } }` block, which has been available since KGP 1.9.0 and produces
identical bytecode. The existing `compileOptions { … VERSION_17 }` block
inside `android {}` is unchanged.
Also add a guarded `publishing { singleVariant("remoteRelease") {} }`
block to satisfy KGP 2.3's new publication-configuration check, which
warns when a `MavenPublication` (the existing `register<MavenPublication>
("remoteRelease")` block) references a variant without a corresponding
`singleVariant(...)` declaration. The
`if (productFlavors.any { it.name == "remote" })` guard ensures
source-consuming forkers who strip the `remote` flavor are not broken at
configuration time — the block is a no-op for them and only opts in when
the variant actually exists.
No change to the published AAR contents, POM, AAR metadata, or
consumer-facing toolchain requirements beyond the KGP 1.9.0 floor implied
by the new DSL (the adapter's own pinned KGP is already 1.9.21, so this
floor is already in effect for source consumers today).
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
When this adapter is consumed by a Kotlin Gradle Plugin 2.3+ build (such as the monorepo it is included in), the legacy
kotlinOptions { jvmTarget = "17" }block fails to evaluate — KGP 2.3 raises that DSL from a deprecation warning to a compile-time error. Standalone builds on the pinned KGP 1.9.21 are unaffected today but would inherit the same error on any future bump.Migrate to the project-level
kotlin { compilerOptions { jvmTarget.set( JVM_17) } }block, which has been available since KGP 1.9.0 and produces identical bytecode. The existingcompileOptions { … VERSION_17 }block insideandroid {}is unchanged.Also add a guarded
publishing { singleVariant("remoteRelease") {} }block to satisfy KGP 2.3's new publication-configuration check, which warns when aMavenPublication(the existingregister<MavenPublication> ("remoteRelease")block) references a variant without a correspondingsingleVariant(...)declaration. Theif (productFlavors.any { it.name == "remote" })guard ensures source-consuming forkers who strip theremoteflavor are not broken at configuration time — the block is a no-op for them and only opts in when the variant actually exists.No change to the published AAR contents, POM, AAR metadata, or consumer-facing toolchain requirements beyond the KGP 1.9.0 floor implied by the new DSL (the adapter's own pinned KGP is already 1.9.21, so this floor is already in effect for source consumers today).