Skip to content

Publish releases from macOS so iOS targets resolve - #52

Open
kdroidFilter wants to merge 1 commit into
mainfrom
fix/publish-ios-targets-from-macos
Open

Publish releases from macOS so iOS targets resolve#52
kdroidFilter wants to merge 1 commit into
mainfrom
fix/publish-ios-targets-from-macos

Conversation

@kdroidFilter

Copy link
Copy Markdown
Collaborator

Problem

dev.nucleusframework:composewebview:1.0.0 cannot be resolved by any KMP project with Apple targets (#51):

> Could not find composewebview:webview-compose-iosarm64:unspecified.

The publish job ran on ubuntu-latest, where iosArm64 / iosSimulatorArm64 are disabled. Kotlin still emits their variants in the root Gradle module metadata, but with Gradle's default project coordinates instead of the publication's. The shipped composewebview-1.0.0.module therefore contains:

"available-at": {
  "group": "composewebview",
  "module": "webview-compose-iosarm64",
  "version": "unspecified"
}

while every other target correctly points at dev.nucleusframework:composewebview-*:1.0.0. The iOS klibs were never published at all.

Fix

  • publish now runs on macos-15, reusing the Xcode selection from the iOS jobs in pr-build-check.yml. Natives keep coming from the build-natives matrix artifacts, so nothing else about the job changes.
  • New :webview-compose:verifyPublicationCoordinates reads the generated root module.json and fails if any available-at entry falls outside the group/version being published. It is wired as a dependency of every AbstractPublishToMaven task, so a wrong publish host can never ship a dangling module again.

Verification

1. Guard rejects the broken release — fed the real composewebview-1.0.0.module from Maven Central:

> Root module metadata points at modules outside this publication:
    iosArm64ApiElements-published -> composewebview:webview-compose-iosarm64:unspecified
    ... (8 entries)
  Expected dev.nucleusframework:*:1.0.0.

and passes on a macOS publish: Publication coordinates OK: 20 variants under dev.nucleusframework:*:0.1.0-SNAPSHOT.

2. Consumer project, issue reproduced then fixed. A scratch KMP module with iosArm64 + iosSimulatorArm64 calling rememberWebViewState / WebView from commonMain:

dependency :shared:compileKotlinIosArm64
composewebview:1.0.0 (Maven Central) Could not find composewebview:webview-compose-iosarm64:unspecified
composewebview:1.0.1-e2e (published from macOS)

With the fixed publication, :shared:dependencies --configuration iosArm64CInterop — the exact configuration from the issue — resolves to dev.nucleusframework:composewebview-iosarm64:1.0.1-e2e, and :shared:linkDebugFrameworkIosSimulatorArm64 links shared.framework successfully.

3. No regression./gradlew :e2e-desktop:run on macOS: SUITE_FINISHED passed=true (full visual suite, real WKWebView).

Closes #51

The Maven Central job ran on ubuntu-latest, where iosArm64 and
iosSimulatorArm64 are disabled. Kotlin still writes their variants into the
root module metadata, but with Gradle's default project coordinates, so
1.0.0 shipped pointing at composewebview:webview-compose-iosarm64:unspecified
and no iOS consumer could resolve it.

Move the publish job to macos-15 (with the same Xcode selection as the iOS
CI jobs) and add :webview-compose:verifyPublicationCoordinates, which fails
every publish task when an available-at entry in the root module metadata
falls outside the group and version being published.

Fixes #51
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.

iOS targets fail to resolve in KMP project after adding v1.0.0

1 participant