Publish per-platform Maven CLI artifacts

Start by reviewing the current GitHub release assets and Craft’s existing Maven publishing support, then examine how the Android Gradle Plugin consumes the CLI. Done means per-platform Maven artifacts are published so consumers can resolve only the host-platform binary, with the plugin JAR remaining small; Gradle Module Metadata is preferred when practical.

The Android Gradle Plugin currently bundles every platform binary of the old sentry-cli into one ~46MB artifact. The new CLI’s compressed platform binaries are roughly 4× larger (e.g. linux-arm64 ~34.8MB vs sentry-cli ~8.8MB), so bundling all platforms would push SAGP toward ~180MB. That slows customer builds and would increase Maven Central egress on weekly plugin releases. sentry-fastlane-plugin has the same consumer pattern.

Current behavior

• CLI ships per-platform GitHub release assets only (for example sentry-linux-arm64.gz at 0.42.2).
• SAGP needs a trusted, dependency-cacheable binary path. Downloading arbitrary executables outside Maven bypasses Gradle dependency lock/verification and is a supply-chain concern (gradle/gradle#28530).
• Hosting outside Maven Central is not viable for customers (checksums, signing, custom repo reliability).

Gap

There is no Maven Central package that lets consumers resolve only the host-platform binary, so integrators are stuck bundling every platform or downloading outside the dependency graph.

Proposal

Raised for SAGP / Android packaging:

• Publish per-platform Maven artifacts (for example io.sentry:sentry:<version>:<os-arch>) so Gradle pulls only the host platform.
• Keep the plugin JAR small (~1MB); fresh installs pay one platform binary (~35MB), and plugin bumps that do not change the CLI version would not re-download the binary.
• Prefer Gradle Module Metadata when practical so consumers can declare a dependency without an explicit os/arch classifier; classifiers alone are enough as a first step.
• Reuse Craft’s existing Maven publishing support if that fits the release pipeline.

Related idea: split Node runtime from the app

Also raised in the same discussion:

• Split the shipped CLI into the Node.js runtime and the app payload instead of one fat binary.
• Let Gradle depend on Node as its own Maven artifact, then layer the smaller CLI app on top of that runtime.
• Weekly plugin upgrades would stay smaller when the Node version is unchanged and only the app part needs a bump.

Raised by the Android team during the CLI cutover size discussion.

Requested by bete.

--

View Junior Session [Sentry]