desktop - support prebuilt JNI binaries via Maven Central to skip C++ build

[jamesarich]

Implements the "prebuilt binaries" suggestion from @sargunv in sargunv/maplibre-native#2 (comment) to improve the desktop contributor experience.

Problem

Contributing to the desktop JVM target currently requires a full C++ build of maplibre-native (~20 min, needs cmake/ninja/bazelisk). This is a friction point for contributors making Kotlin-only changes.

Solution

Add a prebuiltJniVersion Gradle property. When set, the build downloads the pre-built maplibre-native-bindings-jni artifact from Maven Central instead of compiling the C++ submodule.

Usage — add to your ~/.gradle/gradle.properties:

prebuiltJniVersion=0.12.1

Then ./gradlew :demo-app:run works without any C++ toolchain.

Changes

• settings.gradle.kts: conditionally excludes :lib:maplibre-native-bindings-jni when prebuiltJniVersion is set
• lib/maplibre-native-bindings/build.gradle.kts: makes the KSP header output path conditional — writes to own build dir in prebuilt mode (no C++ compilation), or to the jni project build dir in source mode (current behavior)
• demo-app/build.gradle.kts: switches the runtimeOnly dependency between project(...) and Maven coordinates based on the property; emits a logger.warn in prebuilt mode as an ABI safety reminder
• gradle.properties: documents the option with a commented-out example

Safety

Prebuilt mode is only safe when your changes are outside lib/maplibre-native-bindings and lib/maplibre-native-bindings-jni (i.e., no JNI interface changes). The build emits a warning to that effect. The property is intentionally documented as a personal ~/.gradle/gradle.properties setting to avoid it being accidentally committed.

[sargunv]

How did you validate these changes? On which platforms?

[sargunv]

Oh, we don't want to build against the prebuilt JNI adapter -- we want to build our JNI module against the prebuilt MapLibre Native.