Repository navigation
KMP/CMP - #318
Merged
Merged
KMP/CMP#318
Conversation
- Bump `compileSdk` and `targetSdk` versions to 37. - Upgrade Gradle Wrapper to 9.6.1. - Update key dependencies, including Kotlin (2.4.0), AGP (9.2.1), Compose Multiplatform (1.11.1), and others. - Replace deprecated OSSRH URLs with new Central Portal endpoints. - Remove iosX64 target due to Compose Multiplatform deprecation. - Enhance GitHub Actions workflows with newer versions and configurations. - Improve JVM arguments and shell scripts for better performance.
- Add iOS simulator tests to build workflow. - Rewrite documentation for Compose Multiplatform. - Improve RGB slider components and add detailed comments. - Introduce Dokka for documentation generation and explicit API mode. - Refactor `TransparencyCheckerboard` and unify theming.
The slider thumb inherited the picked color's alpha, so choosing a fully transparent color made every thumb invisible - including the alpha slider's own, which is the one you need in order to drag back. Opacity is now enforced once in ColorSlider, where every slider and any direct caller passes through. buildHueGradient sampled seven segments, which places no stop on the 60-degree breakpoints where HSL-to-RGB changes slope. Linear interpolation between off-breakpoint stops cut the corners: the drawn track was off by up to 55/255 at hue 180, while the Contextual thumb above it was painted with the true color. Six segments put a stop on every breakpoint and the error goes to zero. ColorSwatch's children used fillMaxSize, which measures to zero under unbounded constraints, so a swatch given no size modifier rendered nothing at all inside a scrolling column or a lazy list. It now falls back to ColorPickerDefaults.SwatchSize, with matchParentSize children so they follow the swatch instead of collapsing it. Tests run under runComposeUiTest. The gradient and RTL cases assert named colors at known pixel positions rather than diffing golden images, so there are no goldens to maintain and a failure names the color it expected. Each test was confirmed to fail against the unfixed code before the fix landed.
version was hardcoded to "1.0.0" while the publish workflow fires on any v* tag, so tagging v1.1.0 would build and upload 1.0.0 again. Maven Central rejects redeploying a released coordinate, and because releases are immutable that mistake cannot be undone. VERSION_NAME in gradle.properties is now the single source of truth, and the workflow refuses to start when the tag and the property disagree rather than discovering it at upload time. sign() was called unconditionally while the key lookup above it was guarded by a null check, so on any machine without signing keys all six sign tasks failed with "no configured signatory". They are dependencies of publishToMavenLocal, which meant a contributor could not smoke-test the library locally at all. Setting isRequired from the same condition skips them instead. CI is unaffected, since it supplies the key.
apiValidation is configured, with klib tracking enabled, but no dump was ever committed - so apiCheck failed on a clean tree with "Expected file with API declarations does not exist" rather than validating anything. Generated with apiDump; the dump records ColorPickerDefaults.SwatchSize, added in the swatch sizing fix. Note that build.yml still does not invoke apiCheck, so the plugin remains inert in CI. Adding it to the build workflow is what would make this baseline do its job.
Uploading to the OSSRH Staging API only *staged* a deployment. Nothing closed or released it, and the build had no task that could — so a tag would have pushed artifacts that sat in the Portal forever without ever reaching Maven Central. com.vanniktech.maven.publish replaces the hand-rolled publishing, signing and javadoc wiring with publishAndReleaseToMavenCentral, which uploads all five publications as one deployment and releases it. Credentials move to the plugin's names, supplied as ORG_GRADLE_PROJECT_* env vars. They must be Central Portal user tokens: Sonatype returns 401 for an OSSRH token, so the old OSSRH_* secrets could not have worked against the Portal endpoint regardless. The javadoc jar now carries the real Dokka HTML (964 KB, 259 pages) rather than the empty jar the previous hand-registered task produced. The release workflow also runs the tests and apiCheck before publishing, since Maven Central is immutable and a bad release cannot be withdrawn. Two smaller things while here: the POM developer id is now the current GitHub handle, and compose.uiTest moves into the version catalog, which clears the two deprecation warnings Compose Multiplatform 1.11 emits for the old accessor.
The binary-compatibility plugin was configured and, since the previous commit, has a committed dump — but no workflow ever ran apiCheck, so public API could drift silently. The build workflow now runs it alongside the tests, which is what makes the baseline mean anything. actions/setup-java was a major version behind at v5; v6 is current. checkout, upload-artifact and gradle/actions were already on their latest majors. Note the setup-java bump has not been exercised on a real runner, only checked against the published releases. Dependabot ran gradle updates daily and ungrouped, which for this project mostly produces PRs that cannot be judged in isolation: Compose Multiplatform carries Kotlin compatibility constraints, so bumping either alone fails for reasons unrelated to the dependency under review. Updates are now weekly and grouped, with Kotlin and Compose moving together, and GitHub Actions collapsed into a single PR.
…eouts Neither workflow declared permissions, so both ran with the default GITHUB_TOKEN scope — far wider than either needs, since the only writes here go to Maven Central using its own credentials. Both are now contents: read. The publish workflow had no concurrency group. Two releases racing is not a recoverable mistake when the registry is immutable, so it now serialises on the ref and never cancels an in-flight run — cancelling a half-finished deployment would be worse than queuing behind it. Job timeouts added so a hung Gradle daemon or a stuck Kotlin/Native link fails in an hour instead of burning a six-hour runner slot. Not adding a wrapper-validation step: gradle/actions/setup-gradle has verified the checksum of every gradle-wrapper.jar since v4, and this repo is on v6, so a separate action would be redundant.
In commonTest these compiled into every target, and failed in two different ways. androidHostTest is host-side JVM with no Android runtime, so runComposeUiTest had nothing to attach to and threw NullPointerException. On iOS the failure was subtler: ui-uikit was already on the main classpath via compose.ui, but nothing had ever instantiated real Compose UI inside a test binary, so Kotlin/Native stripped the UIKit view layer as unreachable. These tests make it reachable, and the linker then needs UIViewLayoutRegion — a symbol the Xcode 16.4 SDK on macos-15 does not have. Moving the tests and the ui-test dependency into jvmTest fixes both at the source. The desktop renderer gives identical coverage: these assert layout measurement and painted pixels, neither of which is platform-specific, and the colour and geometry logic underneath is still covered in commonTest across every target. Also migrated to androidx.compose.ui.test.v2.runComposeUiTest, which Compose Multiplatform 1.11 deprecates the old entry point in favour of. v2 defaults to StandardTestDispatcher; all three tests pass unchanged under it. Verified: jvmTest 332 tests including the three UI tests, testAndroidHostTest 329 with them correctly absent, both zero failures. The iOS link is reasoned about rather than verified — it cannot be exercised from a Windows host.
Follows the repository rename. Updates rootProject.name, the POM name, and the project and SCM URLs, which matter most because they are baked into the published artifact and cannot be corrected after release. Deliberately untouched: the lowercase codes.side:andcolorpicker:0.6.2 coordinate in the migration tables. That is a real artifact still resolvable on Maven Central, so rewriting it would send readers to something that does not exist. Only the project's own name changes; the historical artifact keeps its. The git remote now points at the new URL. GitHub redirects the old one, so this is tidiness rather than a fix.
linkDebugTestIosSimulatorArm64 failed with an undefined _OBJC_CLASS_$_UIViewLayoutRegion, referenced from ui-uikit. macos-15 defaults to Xcode 16.4, whose iOS SDK predates that class; Compose Multiplatform's ui-uikit references it. The image already ships Xcode 26.x, so this selects the newest installed rather than changing runner image. Worth recording why only the test link broke while the framework link passed: the framework is declared isStatic, and a static archive never resolves external symbols, whereas a test executable must. And it is unrelated to which tests exist — Kotlin/Native static caches link whole modules rather than tree-shaking, so CMPLayoutRegion.o is pulled in whatever the test source set contains. An earlier attempt to fix this by moving the Compose UI tests to jvmTest did not help, and the link failed identically afterwards. That move was still correct on its own merits, for the Android host failure. The same step goes into the publish workflow, where allTests reaches the iOS tests on the same runner. Also bundles the dependency bump that prompted this: Kotlin 2.4.10, AGP 9.3.2, Compose Multiplatform 1.12.0, collections-immutable 0.5.2, vanniktech 0.37.0. All build clean locally with tests and apiCheck green.
Verified against the full build: tests, assemble, apiCheck and the sample APK all pass on 9.7.1.
Verified on the full build: tests, assemble, apiCheck and the sample APK all pass, with no new deprecation warnings from the Android plugin.
Maven Central is immutable, so the first real exercise of the Portal token, the signing key and the upload path should not be the run that consumes 1.0.0. A manual dispatch now defaults to publishing a snapshot: the version is overridden on the command line, so gradle.properties is never edited and there is no way to leave a SNAPSHOT version committed or forget to revert it. Snapshots route to the Central Portal snapshot repository, skip validation and release, and are available as soon as the task finishes. Signing is not required for them but still runs when configured, which is what makes this a genuine rehearsal rather than a partial one. A tag push is unaffected and still takes the publishAndReleaseToMavenCentral path.
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
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.
No description provided.