pom.xml

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>

    <!-- Use your verified namespace -->
    <groupId>io.github.beehive-lab</groupId>
    <artifactId>jitllm</artifactId>
    <version>${revision}${jdk.version.suffix}</version>

    <name>jitllm</name>
    <description>LLM inference and serving for the JVM, GPU-accelerated with TornadoVM</description>
    <url>https://github.com/beehive-lab/jitllm</url>

    <licenses>
        <license>
            <name>MIT License</name>
            <url>https://opensource.org/licenses/MIT</url>
            <distribution>repo</distribution>
        </license>
    </licenses>

    <developers>
        <developer>
            <id>mikepapadim</id>
            <name>Michalis Papadimitriou</name>
            <url>https://github.com/mikepapadim</url>
        </developer>
    </developers>

    <scm>
        <connection>scm:git:git://github.com/beehive-lab/jitllm.git</connection>
        <developerConnection>scm:git:ssh://github.com/beehive-lab/jitllm.git</developerConnection>
        <tag>HEAD</tag>
        <url>https://github.com/beehive-lab/jitllm</url>
    </scm>

    <properties>
        <!-- CI-friendly version: resolved by flatten-maven-plugin at build time -->
        <revision>1.0.2</revision>
        <!-- Floor is >= 5.2.0, for two independent reasons: BFloat16Array lands in 5.2.0
                 (FP8Array in 5.1.0), along with deterministic generated kernel source and the
                 graph-sized interpreter bytecode buffer; and the packed-half2 split-KV
                 attention needs KernelContext.allocateHalf2LocalArray, which 5.0.0 lacks.

                 Pinned to 6.0.0 rather than the 5.2.0 floor because 5.2.0's interpreter cannot
                 run batched prefill at all. consumeFromDevice(producer, ...) resolved its source
                 against the *previously executed* graph instead of the named one, and imported
                 that graph's device buffer unconditionally — so in a plan that revisits graphs
                 (prefill layers -> decodeActivation -> decode layers -> logits -> decodeActivation
                 -> ...) the second decode pass imported a null buffer and the next ALLOC
                 dereferenced it:
                   NullPointerException: XPUDeviceBufferState.getXPUBuffer() is null
                     at TornadoVMInterpreter.executeAlloc
                 Fixed upstream in beehive-lab/TornadoVM 8603a9fa2d ("Fix consumeFromDevice
                 silently reading a stale buffer when the named producer is not the previously
                 executed graph", PR #996), released in 6.0.0. The path is backend-independent —
                 reproduced here on Metal, and CI recorded the same NPE on its cuda and opencl
                 legs. 6.0.0 also carries the sketch-phase fix for the LambdaForm hidden-class
                 reader, which took out every F16 family on OpenCL.
                 See docs/architecture/metal/SESSION-2026-09-04.md §1.

                 DEVELOPMENT builds depend on TornadoVM develop, whose artifacts are
                 <base>-jdk21-dev / <base>-jdk22plus-dev and are not on Maven Central: they come
                 from a local build of the chosen develop commit (scripts/tornadovm-dev.sh, which is
                 also what CI runs), and that build is what says which version it produced. The
                 values below are the development DEFAULT so that a plain ./mvnw works once the
                 environment is prepared; scripts/tornadovm-dev.sh build and CI pass the produced
                 version explicitly (-Dtornadovm.version=...) and CI fails if the two disagree,
                 which is the signal to update tornadovm.base.version when develop moves on.

                 The kernels on this branch need what develop carries since 65f06c5d162c36022f9d5724
                 dd38b9784d85cfcc (2026-09-19): PRs #1091-#1094, #1098, #1099, #1101 (signed
                 int-to-float conversion, private array zero-init, FP16 header selection,
                 HalfFloat(short) bit reinterpretation, float-to-half value conversion, in-kernel
                 reads of MMA accumulator elements, byte-offset int8 fragment loads).

                 RELEASE builds (-P release) depend on a published TornadoVM release instead:
                 tornadovm.release.version, set by the release workflows, replaces the base version
                 and drops the -dev qualifier, and the enforcer below refuses a release build that
                 has no such version or still resolves to -dev coordinates. A release also fails to
                 compile if the chosen TornadoVM release lacks the APIs above: TornadoVM 7.0.0 is the
                 first release that carries them, so it is the minimum a jitllm release can use. -->
        <tornadovm.base.version>6.1.1</tornadovm.base.version>
        <!-- The published TornadoVM release that -P release builds against (see prepare-release.yml). -->
        <tornadovm.release.version>7.0.1</tornadovm.release.version>
        <!-- The qualifier TornadoVM's own develop builds carry; emptied by the release profile. -->
        <tornadovm.dev.qualifier>-dev</tornadovm.dev.qualifier>
        <archunit.version>1.4.2</archunit.version>
        <jdk.version.suffix>-jdk21</jdk.version.suffix>
        <!-- TornadoVM's own JDK suffix, a separate property from jdk.version.suffix above
                 (which names *this* project's published artifact). Both lines currently match
                 TornadoVM's: -jdk21 and -jdk22plus. -->
        <tornadovm.jdk.suffix>-jdk21</tornadovm.jdk.suffix>
        <!-- CUDA backend is only available after 5.0.0 TornadoVM version -->
        <tornadovm.version>${tornadovm.base.version}${tornadovm.jdk.suffix}${tornadovm.dev.qualifier}</tornadovm.version>
        <!-- Compiler defaults (overridden by JDK profiles below) -->
        <maven.compiler.source>22</maven.compiler.source>
        <maven.compiler.target>22</maven.compiler.target>
        <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
        <maven.javadoc.skip>true</maven.javadoc.skip>
        <gpg.skip>true</gpg.skip>
    </properties>

    <dependencies>
        <dependency>
            <groupId>junit</groupId>
            <artifactId>junit</artifactId>
            <version>4.13.2</version>
            <scope>test</scope>
        </dependency>
        <!-- Architecture rules (M1 guardrails). Test scope only: must never
                 reach the published jar. See docs/architecture/architecture.md -->
        <dependency>
            <groupId>com.tngtech.archunit</groupId>
            <artifactId>archunit-junit4</artifactId>
            <version>${archunit.version}</version>
            <scope>test</scope>
        </dependency>
        <!-- Every TornadoVM artifact is provided: the TornadoVM SDK supplies it at runtime as a
             named module, through the module path in $TORNADOVM_HOME/tornado-argfile, together
             with everything it depends on (Graal collections, log4j, JMH, jopt-simple,
             commons-math3, snmp4j, ASM). A second copy on the class path is not harmless: a
             container with its own class loader (Quarkus's RunnerClassLoader) loads the copy
             while tornado.graal still comes from the SDK, and the first request fails with a
             loader constraint violation on org.graalvm.collections.UnmodifiableEconomicMap
             (issue #176). So the published jar carries this project's classes only, and the
             enforcer rule ban-runtime-dependencies below keeps the dependency graph that way. -->
        <dependency>
            <groupId>io.github.beehive-lab</groupId>
            <artifactId>tornado-api</artifactId>
            <version>${tornadovm.version}</version>
            <scope>provided</scope>
        </dependency>
        <!-- The vendor-library bindings the batched prefill path compiles against: cuBLAS for
             the four projections, cuDNN for the first chunk's fused attention. Both use the same
             prepared SDK version and Maven repository as the API. -->
        <dependency>
            <groupId>io.github.beehive-lab</groupId>
            <artifactId>tornado-cublas</artifactId>
            <version>${tornadovm.version}</version>
            <scope>provided</scope>
        </dependency>
        <dependency>
            <groupId>io.github.beehive-lab</groupId>
            <artifactId>tornado-cudnn</artifactId>
            <version>${tornadovm.version}</version>
            <scope>provided</scope>
        </dependency>
        <dependency>
            <groupId>io.github.beehive-lab</groupId>
            <artifactId>tornado-runtime</artifactId>
            <version>${tornadovm.version}</version>
            <scope>provided</scope>
        </dependency>
    </dependencies>

    <build>
        <plugins>
            <!-- The Vector API is an incubator module on both supported JDKs (JEP 508 in
                     JDK 25), so add-modules is required to compile against it. enable-preview is
                     added by the JDK 21 profile only: java.lang.foreign was a preview API in 21
                     and final from 22, so the JDK 22+ artifact carries no preview class file and
                     is therefore not pinned to one JDK version. -->
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-compiler-plugin</artifactId>
                <version>3.11.0</version>
                <configuration>
                    <compilerArgs>
                        <arg>--add-modules</arg>
                        <arg>jdk.incubator.vector</arg>
                    </compilerArgs>
                </configuration>
            </plugin>

            <!-- Class A gates only by default: `mvn test` must never need a model file,
                     a TornadoVM installation or an accelerator. The Class B tests are named
                     *AccelTest and run under -Paccel-tests. See verification-gates.md -->
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-surefire-plugin</artifactId>
                <version>3.2.2</version>
                <configuration>
                    <excludes>
                        <exclude>**/*AccelTest.java</exclude>
                    </excludes>
                    <!-- Class A tests reference TornadoVM API types and this project's
                             foreign-memory tensors, which are preview class files on JDK 21. No
                             accelerator, model or TornadoVM installation is implied — those stay
                             exclusive to -Paccel-tests, whose argLine replaces this one. -->
                    <argLine>--enable-preview --add-modules jdk.incubator.vector</argLine>
                </configuration>
            </plugin>

            <!-- JDK 21 and JDK 22+ each publish their own artifact. Without this, a JDK
                     older than 21 activates neither profile and the build silently produces a
                     -jdk21 artifact compiled by, and linked against, something else. Fail at
                     validate instead. -->
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-enforcer-plugin</artifactId>
                <version>3.5.0</version>
                <executions>
                    <execution>
                        <id>enforce-supported-jdk</id>
                        <goals>
                            <goal>enforce</goal>
                        </goals>
                        <phase>validate</phase>
                        <configuration>
                            <rules>
                                <requireJavaVersion>
                                    <version>[21,)</version>
                                    <message>jitllm builds on JDK 21 or newer. JDK 21 produces jitllm:*-jdk21 against tornado *-jdk21; JDK 22+ produces jitllm:*-jdk22plus (Java 22 bytecode) against tornado *-jdk22plus.</message>
                                </requireJavaVersion>
                            </rules>
                            <fail>true</fail>
                        </configuration>
                    </execution>
                    <!-- The library has no dependency a consumer inherits at runtime: TornadoVM and
                             everything it needs come from the SDK (provided), the rest is test
                             scope. A compile- or runtime-scope dependency, direct or transitive,
                             would reach consumers' class paths next to the SDK's modules, which is
                             issue #176 again. -->
                    <execution>
                        <id>ban-runtime-dependencies</id>
                        <goals>
                            <goal>enforce</goal>
                        </goals>
                        <phase>validate</phase>
                        <configuration>
                            <rules>
                                <bannedDependencies>
                                    <excludes>
                                        <exclude>*:*:*:*:compile</exclude>
                                        <exclude>*:*:*:*:runtime</exclude>
                                    </excludes>
                                    <message>jitllm must not have compile- or runtime-scope dependencies: the TornadoVM SDK supplies TornadoVM and its dependencies at runtime (declare them provided), and a bundled or inherited copy collides with the SDK's modules (issue #176).</message>
                                </bannedDependencies>
                            </rules>
                            <fail>true</fail>
                        </configuration>
                    </execution>
                </executions>
            </plugin>

            <!-- Flatten: resolves ${revision}${jdk.version.suffix} in the published POM -->
            <plugin>
                <groupId>org.codehaus.mojo</groupId>
                <artifactId>flatten-maven-plugin</artifactId>
                <version>1.6.0</version>
                <configuration>
                    <updatePomFile>true</updatePomFile>
                    <flattenMode>resolveCiFriendliesOnly</flattenMode>
                </configuration>
                <executions>
                    <execution>
                        <id>flatten</id>
                        <goals>
                            <goal>flatten</goal>
                        </goals>
                        <phase>process-resources</phase>
                    </execution>
                    <execution>
                        <id>flatten.clean</id>
                        <goals>
                            <goal>clean</goal>
                        </goals>
                        <phase>clean</phase>
                    </execution>
                </executions>
            </plugin>

            <!-- The published jar is a plain library jar: this project's classes and service files,
                     nothing bundled (see the TornadoVM dependencies above). It is also what the
                     jitllm/jitllm4j launchers run, because they start the JVM from the SDK's argfile,
                     which already puts TornadoVM and its dependencies on the module path; so the
                     manifest still names the CLI entry point. -->
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-jar-plugin</artifactId>
                <version>3.4.2</version>
                <configuration>
                    <archive>
                        <manifest>
                            <mainClass>org.beehive.jitllm.JitllmApp</mainClass>
                        </manifest>
                        <manifestEntries>
                            <Automatic-Module-Name>org.beehive.jitllm</Automatic-Module-Name>
                        </manifestEntries>
                    </archive>
                </configuration>
            </plugin>
        </plugins>
    </build>

    <!-- Profiles for optional/conditional builds -->
    <profiles>

        <!-- ─── Class B: accelerator qualification gates ─────────────────────────
                 Opt-in: `mvn verify -Paccel-tests`. Needs TORNADOVM_HOME, a device, and
                 the pinned model fixtures (JITLLM_TEST_MODELS or ~/.jitllm/test-models).
                 On a machine without them the tests skip with an explicit marker — a skip
                 is recorded, never reported as a pass.

                 recover.bailout=False is mandatory (capability C4): with the default TRUE a
                 failed kernel silently falls back to sequential Java, which would produce a
                 wrong golden instead of an error.

                 The device memory budget is 20GB, raised from 16GB when T7.4 added the batched
                 engine plan: the Class B suite stands up several GPU plans in one JVM (goldens,
                 parity, compiled-program identity, metrics, façade parity, and now a B-wide
                 batched decode plan whose padded logits buffer alone is tens of megabytes), and
                 each plan holds its own device copy of the weights until its owner is closed.
                 A budget sized for one plan fails the last test to run, not the one that is
                 wrong — which is exactly how this was noticed, twice.

                 The backend is pinned to CUDA because the goldens are recorded on it. An SDK
                 built with several backends otherwise defaults to OpenCL, which is a different
                 tuple, and the golden test then degrades itself to comparing token ids only —
                 passing while asserting almost nothing. The priorities are harmless on an
                 OpenCL-only SDK, where the CUDA backend simply is not present.
            ─────────────────────────────────────────────────────────────────────── -->
        <profile>
            <id>accel-tests</id>
            <build>
                <plugins>
                    <plugin>
                        <groupId>org.apache.maven.plugins</groupId>
                        <artifactId>maven-surefire-plugin</artifactId>
                        <configuration>
                            <excludes combine.self="override"/>
                            <includes>
                                <include>**/*AccelTest.java</include>
                            </includes>
                            <useModulePath>false</useModulePath>
                            <!-- One JVM per test class. Device memory a closed session frees
                                     is returned to TornadoVM's buffer provider but not to the
                                     driver, and the provider only recycles it under budget
                                     pressure - measured: five sequential load/session/close cycles
                                     grow resident device memory by ~2.1 GiB each and never shrink,
                                     on the legacy path and the lowered one alike. A shared JVM
                                     therefore exhausts the device after a handful of classes,
                                     whichever tests those are. Process exit is what actually
                                     releases it. -->
                            <reuseForks>false</reuseForks>
                            <!-- -da:tornado.graal... — assertions OFF inside TornadoVM's
                                     vendored Graal only, and nowhere else.

                                     TornadoVM's OpenCL backend registers an invocation plugin for
                                     `set(int, <storage array>)` on every vector type
                                     (OCLVectorPlugins.registerVectorPlugins), but the vector types
                                     declare only set(int, <element>) and set(<vector>). Graal's
                                     InvocationPlugins$Checks.checkResolvable notices, and it runs
                                     only when assertions are enabled — so backend initialisation
                                     dies before any test does:
                                       ExceptionInInitializerError: NoSuchMethodError:
                                       Float2.set(ILuk/.../FloatArray;)
                                     TornadoCoreRuntime.loadBackends initialises EVERY installed
                                     backend, so on an SDK built with metal,opencl this takes out
                                     the Metal tests too.

                                     The mismatch is long-standing and identical in 5.2.1-dev; what
                                     changed at 6.0.0 is the Graal *packaging*. 5.x shipped it as
                                     jdk.internal.vm.compiler, a platform module that plain -ea does
                                     not cover; 6.0.0 vendors it as the ordinary module
                                     tornado.graal, which -ea does cover. So this surfaced as a
                                     version bump without any behaviour changing.

                                     Scoped to that package prefix rather than surefire's
                                     enableAssertions=false, which would also silence assertions in
                                     this project's own code. Remove once TornadoVM's registration
                                     and its vector types agree. -->
                            <argLine>@${env.TORNADOVM_HOME}/tornado-argfile
                                    --add-modules jdk.incubator.vector
                                    -da:tornado.graal...
                                    -Dtornado.recover.bailout=False
                                    -Djitllm.deviceSample=false
                                    -Dtornado.device.memory=20GB
                                    -Dtornado.cuda.priority=100
                                    -Dtornado.opencl.priority=0</argLine>
                        </configuration>
                    </plugin>
                </plugins>
            </build>
        </profile>

        <!-- ─── JDK 21 ───────────────────────────────────────────────────────────
                 Auto-activates on JDK 21.
                 Publishes: jitllm:${revision}-jdk21
                 TornadoVM: ${tornadovm.base.version}-jdk21
            ─────────────────────────────────────────────────────────────────────── -->
        <profile>
            <id>jdk21</id>
            <activation>
                <jdk>[21,22)</jdk>
            </activation>
            <properties>
                <maven.compiler.source>21</maven.compiler.source>
                <maven.compiler.target>21</maven.compiler.target>
                <jdk.version.suffix>-jdk21</jdk.version.suffix>
                <tornadovm.jdk.suffix>-jdk21</tornadovm.jdk.suffix>
                <tornadovm.version>${tornadovm.base.version}${tornadovm.jdk.suffix}${tornadovm.dev.qualifier}</tornadovm.version>
            </properties>
            <build>
                <plugins>
                    <plugin>
                        <groupId>org.apache.maven.plugins</groupId>
                        <artifactId>maven-compiler-plugin</artifactId>
                        <configuration>
                            <!-- java.lang.foreign (GGUF mapping, the tensor classes) is a
                                     preview API on JDK 21, and the TornadoVM 21 line's array
                                     types are compiled against it too. -->
                            <compilerArgs combine.children="append">
                                <arg>--enable-preview</arg>
                            </compilerArgs>
                        </configuration>
                    </plugin>
                </plugins>
            </build>
        </profile>

        <!-- ─── JDK 22+ ──────────────────────────────────────────────────────────
                 Auto-activates on JDK 22 and newer (CI builds it on JDK 25).
                 Publishes: jitllm:${revision}-jdk22plus, compiled with release 22
                 TornadoVM: ${tornadovm.base.version}-jdk22plus${tornadovm.dev.qualifier}
                 Mirrors TornadoVM, which since 6.0.0 ships one jdk22plus line for JDK 22 and up.
            ─────────────────────────────────────────────────────────────────────── -->
        <profile>
            <id>jdk22plus</id>
            <activation>
                <jdk>[22,)</jdk>
            </activation>
            <properties>
                <maven.compiler.source>22</maven.compiler.source>
                <maven.compiler.target>22</maven.compiler.target>
                <maven.compiler.release>22</maven.compiler.release>
                <jdk.version.suffix>-jdk22plus</jdk.version.suffix>
                <tornadovm.jdk.suffix>-jdk22plus</tornadovm.jdk.suffix>
                <tornadovm.version>${tornadovm.base.version}${tornadovm.jdk.suffix}${tornadovm.dev.qualifier}</tornadovm.version>
            </properties>
        </profile>

        <profile>
            <id>release</id>
            <properties>
                <maven.javadoc.skip>false</maven.javadoc.skip>
                <gpg.skip>false</gpg.skip>
                <!-- A release depends on a published TornadoVM release: the base version becomes
                         the chosen release and the -dev qualifier goes. This profile is listed after
                         the JDK profiles, so these take precedence over their defaults. -->
                <tornadovm.base.version>${tornadovm.release.version}</tornadovm.base.version>
                <tornadovm.dev.qualifier/>
            </properties>
            <build>
                <plugins>
                    <!-- Refuse a release that has no concrete published TornadoVM release, or
                             that would still resolve development coordinates. Whether the chosen
                             release is actually published (and carries the APIs this branch needs)
                             is checked by the release workflows, which build with an empty local
                             repository so nothing can be satisfied by a local -dev install. -->
                    <plugin>
                        <groupId>org.apache.maven.plugins</groupId>
                        <artifactId>maven-enforcer-plugin</artifactId>
                        <version>3.5.0</version>
                        <executions>
                            <execution>
                                <id>enforce-release-tornadovm</id>
                                <goals>
                                    <goal>enforce</goal>
                                </goals>
                                <phase>validate</phase>
                                <configuration>
                                    <rules>
                                        <requireProperty>
                                            <property>tornadovm.release.version</property>
                                            <regex>[0-9]+\.[0-9]+\.[0-9]+</regex>
                                            <regexMessage>tornadovm.release.version must be a published TornadoVM release X.Y.Z; a release cannot depend on a local develop build (-dev). Set it with -Dtornadovm.release.version=X.Y.Z (prepare-release.yml does).</regexMessage>
                                        </requireProperty>
                                        <requireProperty>
                                            <property>tornadovm.version</property>
                                            <regex>[0-9]+\.[0-9]+\.[0-9]+-jdk(21|22plus)</regex>
                                            <regexMessage>A release must resolve TornadoVM release coordinates (X.Y.Z-jdk21 or X.Y.Z-jdk22plus), not development ones.</regexMessage>
                                        </requireProperty>
                                    </rules>
                                    <fail>true</fail>
                                </configuration>
                            </execution>
                        </executions>
                    </plugin>
                    <!-- Sources -->
                    <plugin>
                        <groupId>org.apache.maven.plugins</groupId>
                        <artifactId>maven-source-plugin</artifactId>
                        <version>3.3.1</version>
                        <executions>
                            <execution>
                                <id>attach-sources</id>
                                <goals>
                                    <goal>jar-no-fork</goal>
                                </goals>
                            </execution>
                        </executions>
                    </plugin>

                    <!-- add-modules jdk.incubator.vector for the same reason the compiler
                             needs it: the Vector API is still an incubator module on both
                             supported JDKs. -->
                    <plugin>
                        <groupId>org.apache.maven.plugins</groupId>
                        <artifactId>maven-javadoc-plugin</artifactId>
                        <version>3.6.3</version>
                        <configuration>
                            <source>${maven.compiler.source}</source>
                            <release>${maven.compiler.source}</release>
                            <additionalJOptions>
                                <additionalJOption>--add-modules</additionalJOption>
                                <additionalJOption>jdk.incubator.vector</additionalJOption>
                            </additionalJOptions>
                            <additionalOptions>
                                <additionalOption>--add-modules jdk.incubator.vector</additionalOption>
                            </additionalOptions>
                            <failOnError>false</failOnError>
                            <failOnWarnings>false</failOnWarnings>
                            <doclint>none</doclint>
                        </configuration>
                        <executions>
                            <execution>
                                <id>attach-javadocs</id>
                                <goals>
                                    <goal>jar</goal>
                                </goals>
                                <phase>package</phase>
                            </execution>
                        </executions>
                    </plugin>

                    <!-- GPG Signing -->
                    <plugin>
                        <groupId>org.apache.maven.plugins</groupId>
                        <artifactId>maven-gpg-plugin</artifactId>
                        <version>3.2.4</version>
                        <executions>
                            <execution>
                                <id>sign-artifacts</id>
                                <goals>
                                    <goal>sign</goal>
                                </goals>
                                <phase>verify</phase>
                            </execution>
                        </executions>
                    </plugin>

                    <!-- Central Publishing -->
                    <plugin>
                        <groupId>org.sonatype.central</groupId>
                        <artifactId>central-publishing-maven-plugin</artifactId>
                        <version>0.8.0</version>
                        <extensions>true</extensions>
                        <configuration>
                            <publishingServerId>central</publishingServerId>
                            <autoPublish>true</autoPublish>
                        </configuration>
                    </plugin>
                </plugins>
            </build>
        </profile>
        <!-- Spotless: Code formatting and style checking (Optional)
                 Usage: mvn -Pspotless spotless:check     (to check violations)
                        mvn -Pspotless spotless:apply     (to apply fixes)
            -->
        <profile>
            <id>spotless</id>
            <build>
                <plugins>
                    <plugin>
                        <groupId>com.diffplug.spotless</groupId>
                        <artifactId>spotless-maven-plugin</artifactId>
                        <version>2.44.4</version>
                        <configuration>
                            <!-- Only check files changed since main branch (smart incremental checking) -->
                            <ratchetFrom>origin/main</ratchetFrom>

                            <!-- Java files formatting -->
                            <java>
                                <includes>
                                    <include>src/main/java/**/*.java</include>
                                    <include>src/test/java/**/*.java</include>
                                </includes>
                                <excludes>
                                    <exclude>**/target/**</exclude>
                                </excludes>
                                <!-- Google Java Format (AOSP style) -->
                                <googleJavaFormat>
                                    <version>1.19.2</version>
                                    <style>AOSP</style>
                                </googleJavaFormat>
                                <!-- Ensure newline at end of file -->
                                <endWithNewline/>
                                <!-- Remove trailing whitespace -->
                                <trimTrailingWhitespace/>
                            </java>

                            <!-- XML files formatting -->
                            <pom>
                                <includes>
                                    <include>pom.xml</include>
                                </includes>
                                <sortPom>
                                    <nrOfIndentSpace>4</nrOfIndentSpace>
                                    <expandEmptyElements>false</expandEmptyElements>
                                </sortPom>
                            </pom>

                            <!-- Markdown files -->
                            <markdown>
                                <includes>
                                    <include>**/*.md</include>
                                </includes>
                                <excludes>
                                    <exclude>**/target/**</exclude>
                                </excludes>
                            </markdown>

                            <!-- Properties files -->
                            <format>
                                <name>props</name>
                                <includes>
                                    <include>src/**/*.properties</include>
                                </includes>
                                <excludes>
                                    <exclude>**/target/**</exclude>
                                </excludes>
                                <trimTrailingWhitespace/>
                                <endWithNewline/>
                            </format>
                        </configuration>
                    </plugin>
                </plugins>
            </build>
        </profile>
    </profiles>
</project>