Replace :core:proto with org.meshtastic:protobufs:2.7.25#5675
Merged
Conversation
99fbb55 to
a99e8cc
Compare
This was referenced May 30, 2026
Merged
Drop the local Wire codegen module in favor of the published KMP protobufs SDK from meshtastic/protobufs. This removes: - The git submodule (core/proto/src/main/proto) - The Wire plugin dependency - All local .proto → Kotlin code generation The TAKPacket-SDK api() export moves to :core:model which already served as the primary transitive provider of proto types. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Update the meshtastic-protobufs dependency from 2.7.25-SNAPSHOT to the 2.7.25 release in the version catalog.
a99e8cc to
3067aa7
Compare
takpacket-sdk 0.5.1 still bundled its own Wire-generated copies of the TAK protos, which collide with org.meshtastic:protobufs:2.7.25 (checkReleaseDuplicateClasses: 'Duplicate class org.meshtastic.proto.* found in protobufs-android and takpacket-sdk-jvm-0.5.1'). 0.5.3 stopped bundling protos — consumers bring their own protobufs SDK — which is exactly the alignment this PR exists for. 0.5.3 also dropped the SDK's iOS klib variants (it publishes JVM-only artifacts now; the conversion pipeline is zstd-jni/xpp3-bound), so the dependency moves from :core:model commonMain to jvmAndroidMain, and the one direct commonMain reference (CotMeshSanitizer in TAKMeshIntegration) now goes through a CotSanitizer expect/actual seam alongside the existing TakSdkCompressor/TakV2Compressor seams: jvmAndroid delegates to the SDK, iOS is a passthrough stub until Swift SDK interop lands. With takpacket out of iOS dependency resolution entirely, the iosMetadataConfigs exclude hack in build-logic (which papered over 0.5.1's missing iOS metadata JARs) is dead — removed. Note: 0.5.3 was built with Kotlin 2.4.0, but JVM-only artifacts are fine under 2.3.21 via the n+1 metadata rule — unlike native klibs (ABI-gated), which is why mqtt-client stays at 0.3.6 until MQTTastic-Client-KMP#55 ships a 2.3.21-built 0.3.8. Also tracks the flatpak platformDependencies compose-desktop pin to the catalog version (1.11.1) — same fix as release/2.8.0 — so the offline aarch64 flatpak verification can resolve desktop-jvm-linux-arm64 again (pre-existing failure on main, surfaced here because this PR triggers the verify-flatpak path filter). Supersedes #5764. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
1 task
jamesarich
added a commit
that referenced
this pull request
Jun 10, 2026
#5275 created :feature:discovery with implementation(projects.core.proto), but main's #5675 replaced the :core:proto submodule with the org.meshtastic:protobufs Maven artifact. Rebasing left a stale module reference. Switched to implementation(libs.meshtastic.protobufs), matching the convention (cf. feature/node). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
jamesarich
added a commit
that referenced
this pull request
Jun 10, 2026
#5275 created :feature:discovery with implementation(projects.core.proto), but main's #5675 replaced the :core:proto submodule with the org.meshtastic:protobufs Maven artifact. Rebasing left a stale module reference. Switched to implementation(libs.meshtastic.protobufs), matching the convention (cf. feature/node). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
jamesarich
added a commit
that referenced
this pull request
Jun 12, 2026
#5275 created :feature:discovery with implementation(projects.core.proto), but main's #5675 replaced the :core:proto submodule with the org.meshtastic:protobufs Maven artifact. Rebasing left a stale module reference. Switched to implementation(libs.meshtastic.protobufs), matching the convention (cf. feature/node). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
jamesarich
added a commit
that referenced
this pull request
Jun 13, 2026
#5275 created :feature:discovery with implementation(projects.core.proto), but main's #5675 replaced the :core:proto submodule with the org.meshtastic:protobufs Maven artifact. Rebasing left a stale module reference. Switched to implementation(libs.meshtastic.protobufs), matching the convention (cf. feature/node). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
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.
The
meshtastic/protobufsKMP SDK landed and 2.7.25 is now a stable release on Maven Central, so we can consume the Wire-generated models as a regular Maven dependency instead of running local codegen from a git submodule.What this does
Replaces the
:core:protomodule (local Wire codegen + git submodule pointing atmeshtastic/protobufs) with the publishedorg.meshtastic:protobufs:2.7.25artifact. This eliminates:core/proto/src/main/proto).proto-> Kotlin code generationwire-runtimecatalog entry (now transitive from the SDK)Approach
projects.core.protonow uselibs.meshtastic.protobufsboxOneOfsMinSize = 5000,makeImmutableCopies = false) so generated types are ABI-compatibletakpacket-sdkis bumped 0.5.1 → 0.5.3 (supersedes chore(deps): update takpacket.sdk to v0.5.3 - autoclosed #5764): 0.5.1 bundled its own copies of the generated TAK protos, which duplicate-class-clash with the protobufs artifact. 0.5.3 stopped bundling and is JVM-only, so the dependency moves to:core:model'sjvmAndroidMainand the one direct commonMain SDK reference goes through a newCotSanitizerexpect/actual seam (jvmAndroid → SDK, iOS → passthrough stub), alongside the existingTakSdkCompressor/TakV2Compressorseams. The 0.5.1-eraiosMetadataConfigsexclude hack in build-logic is now dead and removed.platformDependenciescompose-desktop pin tracks the catalog (1.11.0 → 1.11.1) — same fix asrelease/2.8.0— fixing the pre-existing offline aarch64 flatpak failure that this PR's path filter surfaces.Deliberately NOT bumped
mqtt-clientstays at 0.3.6: 0.3.7 was built with Kotlin 2.4.0 and its klibs carry ABI version 2.4.0, which our Kotlin 2.3.21 toolchain rejects (we're blocked on InsertKoinIO/koin#2431 for the 2.4 upgrade, see #5760). meshtastic/MQTTastic-Client-KMP#55 re-ships 0.3.7's content (incl. the TLS pump crash fix) on a 2.3.21 toolchain as 0.3.8; #5763 will then go green via Renovate. Renovate holds in MQTTastic-Client-KMP and meshtastic/protobufs#944 keep both libraries 2.3-consumable until the app's Kotlin 2.4 upgrade lands.Verification
spotlessApply spotlessCheck detekt assembleDebug test allTests kmpSmokeCompile— 1625 tasks, no failures (incl. iOS compiles of:core:model/:core:takserverproving takpacket is out of iOS resolution, and the golden strip-preservation tests through the new seam).