Skip to content

fix(logger): publish com.onesignal:logger as a Maven artifact#7

Merged
abdulraqeeb33 merged 1 commit into
mainfrom
fix/publish-logger-maven-artifact
Jul 23, 2026
Merged

fix(logger): publish com.onesignal:logger as a Maven artifact#7
abdulraqeeb33 merged 1 commit into
mainfrom
fix/publish-logger-maven-artifact

Conversation

@abdulraqeeb33

@abdulraqeeb33 abdulraqeeb33 commented Jul 23, 2026

Copy link
Copy Markdown
Collaborator

This PR makes the published com.onesignal:logger artifact resolvable and traceable.

1. Publish com.onesignal:logger as a Maven artifact

:core in the Android SDK declares a runtime dependency on this module, so its published POM lists com.onesignal:logger:<version> as a runtime dependency. This module had no publishing configuration, so that coordinate never lands on Maven Central — the next Android SDK release would be unresolvable for every Maven consumer (Could not resolve com.onesignal:logger).

Flagged in Android PR review: OneSignal/OneSignal-Android-SDK#2687 (review 4757150755).

Fix: wire up a vanniktech Kotlin Multiplatform publication (mirroring :otel/:core) so com.onesignal:logger — plus its logger-android release variant — is published alongside the other SDK modules.

  • Guarded on -PSDK_VERSION, present only in the Android host build (which also supplies the vanniktech plugin + group/version). The standalone KMP build skips publishing and stays self-contained.
  • vanniktech types referenced by fully-qualified name (no top-level import) so the script still compiles in this repo.
  • publishLibraryVariants('release'); signs only when credentials are present.

No Android-repo code changes needed

:core already depends on :logger, and the Android release runs ./gradlew publishAndReleaseToMavenCentral at the root — which now includes :logger automatically once this lands and the submodule pointer is bumped. The only Android-side change is the submodule pointer bump.

2. Stamp KMP provenance into the artifact

Because the logger is republished under the host SDK's version (com.onesignal:logger:5.9.x), the artifact alone gives no hint of which KMP source produced it. Generate a LoggerBuildInfo.KMP_VERSION constant from git describe --tags --always --dirty against this module's checkout and compile it into commonMain (every published variant).

  • Regenerated each build; falls back to "unknown" when git is unavailable.
  • Generated file lives under build/ (excluded from Spotless).
  • Tagged release commit → e.g. v0.2.0; untagged/dirty → short SHA (e.g. bb9436f-dirty).

3. Emit ossdk.kmp_version on every payload

Surface that provenance on the wire: LogFieldsTopLevel now adds ossdk.kmp_version (= LoggerBuildInfo.KMP_VERSION) to the OTLP resource attributes, right next to ossdk.sdk_base_version. So every log/crash record is traceable to the exact shared-logger source from the backend, without needing the Android git history. Static value → resource scope (fetched once).

Full traceability now: SDK version → submodule SHA → KMP tag (git), shipped artifact → KMP version (baked constant), and any backend record → KMP version (ossdk.kmp_version).

Verification

Maven-local consumer build resolves cleanly:

com.onesignal:core:9.9.9-local
  +--- com.onesignal:otel:9.9.9-local
  +--- com.onesignal:logger:9.9.9-local
  |    \--- com.onesignal:logger-android:9.9.9-local
BUILD SUCCESSFUL

Also: standalone ./gradlew :logger:tasks has no publish tasks (guard works); spotlessCheck, :logger:testDebugUnitTest, and :logger:iosSimulatorArm64Test all pass; generated LoggerBuildInfo.kt compiles into both Android and iOS targets.

Note

KMP publishing also uploads the iOS klib artifacts (logger-iosarm64, logger-iosx64, logger-iossimulatorarm64). Only logger + logger-android are needed by Android consumers; the iOS ones are harmless but publicly visible. Can be restricted to Android-only if preferred.

Make the shared multiplatform module resolvable for SDK consumers and
traceable back to its source, and consolidate it into a single umbrella
module.

Publishing
- Wire up com.vanniktech.maven.publish so the module publishes as
  com.onesignal:kmp (Android release variant + root Gradle metadata),
  which :core's POM references. Without this, an SDK release is
  unresolvable for Maven consumers.
- Gate publishing (and iOS target registration) on an explicit,
  host-agnostic opt-in flag `onesignalPublishSharedKmp` instead of a
  host-specific value like Android's SDK_VERSION, so iOS/future hosts
  control it the same documented way. The standalone KMP build never
  publishes.
- Sign only when signing credentials are present, so publishToMavenLocal
  and the standalone build work unsigned.

Provenance
- Generate LoggerBuildInfo.KMP_VERSION from `git describe` at build time
  and compile it into commonMain, so any shipped artifact records the
  exact KMP tag/commit it was built from (independent of the host SDK
  version it is republished under). Fetch tags first so shallow submodule
  checkouts still resolve vX.Y.Z.
- Emit it on the wire as the `ossdk.kmp_version` OTLP resource attribute.
- Refuse to publish unless provenance is a clean, tagged KMP version
  (vX.Y.Z); escape hatch -PALLOW_UNTAGGED_LOGGER_KMP=true for local runs.

Module rename
- Rename the Gradle module and artifact from `logger` to the umbrella
  `:kmp` (git mv logger/ -> kmp/, coordinates 'kmp'). The logger stays as
  the com.onesignal.logger package inside it; future shared features
  (common, notifications, ...) are added as sibling packages, not new
  Gradle modules, so iOS links a single framework.
- Update settings.gradle, CI/release workflows (:kmp:* tasks + artifact
  paths), README, and the shared-module authoring rule accordingly.

Co-authored-by: Cursor <cursoragent@cursor.com>
@abdulraqeeb33
abdulraqeeb33 force-pushed the fix/publish-logger-maven-artifact branch from 4045f7e to 8218d25 Compare July 23, 2026 19:33
@abdulraqeeb33
abdulraqeeb33 merged commit aae38ac into main Jul 23, 2026
1 check passed
@abdulraqeeb33
abdulraqeeb33 deleted the fix/publish-logger-maven-artifact branch July 23, 2026 19:40
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.

1 participant