build(native-cpu): add publishing config + register in BOM#576
Merged
michalharakal merged 1 commit intodevelopfrom Apr 29, 2026
Merged
build(native-cpu): add publishing config + register in BOM#576michalharakal merged 1 commit intodevelopfrom
michalharakal merged 1 commit intodevelopfrom
Conversation
Layers the publishing setup that PR 1 of the native-FFM rollout deliberately deferred (#571) onto the now-shipped scaffolding + kernels. Lets downstream consumers pull the native provider through the same coordinate-driven path the rest of the SKaiNET libraries use, and lets a composite-build consumer (e.g. SKaiNET-transformers via includeBuild) substitute the published coordinates with a local project ref. Changes: - skainet-backends/skainet-backend-native-cpu/build.gradle.kts: add `alias(libs.plugins.vanniktech.mavenPublish)` to the plugins block. The vanniktech plugin auto-derives Maven coordinates from the root group (`sk.ainet.core`), version (`VERSION_NAME` — currently 0.22.0-SNAPSHOT), and the new gradle.properties below. - skainet-backends/skainet-backend-native-cpu/gradle.properties: NEW. POM_ARTIFACT_ID=skainet-backend-native-cpu and POM_NAME mirroring the convention every other publishable module uses. - skainet-bom/build.gradle.kts: add `api(project(":skainet-backends:skainet-backend-native-cpu"))` alongside the existing backend-api / backend-cpu constraints, so consumers depending on the BOM get a constrained version of the native module without adding a separate version pin. Verification: - ./gradlew :skainet-backends:skainet-backend-native-cpu:publishToMavenLocal -PRELEASE_SIGNING_ENABLED=false -PsignAllPublications=false publishes sk.ainet.core:skainet-backend-native-cpu-jvm:0.22.0-SNAPSHOT to ~/.m2 alongside the existing backend artifacts. - ./gradlew publishToMavenLocal (full repo) — green, no regressions in the existing modules' publish tasks. The native module's JAR carries the host-arch shared library at native/<os>-<arch>/libskainet_kernels.{so|dylib|dll}, so a JAR published from this build host (linux-x86_64 here) only carries the linux-x86_64 .so. Multi-arch fat-JAR aggregation across the PR 4 cross-arch CI matrix runners is still deferred — consumers on other arches cleanly fall back to the priority-50 Panama provider when the native lib doesn't load. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This was referenced Apr 29, 2026
Merged
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.
Summary
Layers the publishing setup that PR 1 of the native-FFM rollout (#571) deliberately deferred onto the now-shipped scaffolding + kernels. Downstream consumers (e.g. SKaiNET-transformers via composite build) can now substitute the published coordinates with a local project ref through the same path every other SKaiNET module uses.
Changes
skainet-backend-native-cpu/build.gradle.kts— addalias(libs.plugins.vanniktech.mavenPublish)to the plugins block. Auto-derivessk.ainet.core:skainet-backend-native-cpucoordinates from the root group + version + newgradle.properties.skainet-backend-native-cpu/gradle.properties(new) —POM_ARTIFACT_ID=skainet-backend-native-cpu,POM_NAME=skainet native (FFM) CPU kernel provider. Mirrors the convention every other publishable module uses.skainet-bom/build.gradle.kts— addapi(project(":skainet-backends:skainet-backend-native-cpu"))alongside the existing backend-api / backend-cpu constraints so BOM consumers get a constrained version without a separate pin.Test plan
./gradlew :skainet-backends:skainet-backend-native-cpu:publishToMavenLocal -PRELEASE_SIGNING_ENABLED=false -PsignAllPublications=false— publishessk.ainet.core:skainet-backend-native-cpu-jvm:0.22.0-SNAPSHOTto~/.m2./gradlew publishToMavenLocal(full repo) — green, no regressionsNote on multi-arch packaging
The published JAR carries only the host-arch shared library at
native/<os>-<arch>/libskainet_kernels.{so|dylib|dll}— i.e. a JAR published from a Linux x86_64 host has only the.so. Multi-arch fat-JAR aggregation across the PR 4 CI matrix runners is still the deferred follow-up. Consumers on other arches cleanly fall through to Panama priority-50 when the native lib doesn't load.🤖 Generated with Claude Code