pom.xml

<!--
SPDX-FileCopyrightText: 2026 Bernard Ladenthin <bernard.ladenthin@gmail.com>

SPDX-License-Identifier: Apache-2.0
-->

<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
         https://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>

    <groupId>net.ladenthin</groupId>
    <artifactId>srcmorph-parent</artifactId>
    <version>1.3.0-SNAPSHOT</version>
    <packaging>pom</packaging>

    <name>${project.groupId}:${project.artifactId}</name>
    <description>Reactor parent for srcmorph: a prompt-driven source-tree transformer using local llama.cpp models, and its Maven plugin.</description>
    <!--
        child.project.url.inherit.append.path stops Maven appending each module's artifactId when it
        inherits these. Without it every published module POM resolves .../srcmorph/srcmorph and
        .../srcmorph/srcmorph-cli - URLs that do not exist. It affects rendered metadata and SBOM
        external references rather than resolution, which is why it survived unnoticed through 1.1.1.
        The same applies to <scm> below, with its own three inherit flags.
    -->
    <url child.project.url.inherit.append.path="false">https://github.com/bernardladenthin/srcmorph</url>

    <licenses>
        <license>
            <name>Apache License 2.0</name>
            <url>https://www.apache.org/licenses/LICENSE-2.0.txt</url>
            <distribution>repo</distribution>
        </license>
    </licenses>

    <developers>
        <developer>
            <name>Bernard Ladenthin</name>
            <organization>ladenthin.net</organization>
        </developer>
    </developers>

    <scm child.scm.connection.inherit.append.path="false"
         child.scm.developerConnection.inherit.append.path="false"
         child.scm.url.inherit.append.path="false">
        <connection>scm:git:https://github.com/bernardladenthin/srcmorph.git</connection>
        <developerConnection>scm:git:https://github.com/bernardladenthin/srcmorph.git</developerConnection>
        <url>https://github.com/bernardladenthin/srcmorph</url>
    </scm>

    <issueManagement>
        <system>GitHub Issues</system>
        <url>https://github.com/bernardladenthin/srcmorph/issues</url>
    </issueManagement>

    <distributionManagement>
        <snapshotRepository>
            <id>central</id>
            <url>https://central.sonatype.com/repository/maven-snapshots/</url>
        </snapshotRepository>
    </distributionManagement>

    <properties>
        <!--
            SonarCloud requires sonar.organization on the project the scanner actually analyzes.
            The SonarCloud scan runs at THIS reactor root (.github/workflows/sonarqube.yml calls
            `mvn ... sonar:sonar` with no -f, so the analyzed project is this parent POM), and a
            parent POM never sees its children's <properties>. Declaring it only in the child
            modules therefore left the root scan without it, failing with
            "You must define the following mandatory properties for '<projectKey>': sonar.organization".
            Kept in the child modules too (harmless) so a per-module scan would also carry it.
        -->
        <sonar.organization>bernardladenthin</sonar.organization>
        <!--
            Defined here (not only in srcmorph-cli/pom.xml) because this parent's own
            <dependencyManagement> below references it: child properties are never visible to a
            parent POM, so the version used by both jackson dependencyManagement entries must live
            at this level. srcmorph-cli/pom.xml does not redeclare it.
        -->
        <jackson.version>2.22.4</jackson.version>
        <!--
            SonarCloud requires sonar.organization on the project the scanner executes, which is
            this reactor root (srcmorph-parent) — child-module properties are not visible to the
            parent POM. The child modules also declare it for standalone/module-scoped runs; the
            projectKey stays a workflow -D argument (see .github/workflows/sonarqube.yml).
        -->
        <sonar.organization>bernardladenthin</sonar.organization>
    </properties>

    <!--
        Reactor modules. `srcmorph` is the extracted core library (config/document/indexer/prompt/
        provider/support — framework-free, no Maven plugin API); `srcmorph-cli` is the standalone
        JSON/YAML-driven CLI (fat jar deliverable) built on top of it; `srcmorph-maven-plugin`
        depends on the core library too and supplies only the Mojo entry points (renamed from
        `llamacpp-ai-index-maven-plugin` in the migration — goal prefix `srcmorph`, package
        `net.ladenthin.maven.srcmorph.mojo`, properties `srcmorph.*`).

        A fourth module, a minimal relocation-stub POM for the retired
        `net.ladenthin:llamacpp-ai-index-maven-plugin` coordinates (no <parent>, version-pinned at
        1.0.4, only a <distributionManagement><relocation> pointing at srcmorph-maven-plugin:1.1.1),
        was published to Maven Central and then removed from this reactor — the published artifact
        is permanent on Central regardless of what this repo's module list contains, and the
        relocation was verified working end-to-end (a clean-repo Maven resolution of the old
        coordinates correctly redirects to the new ones) before removal. There is nothing left for
        that module to do: it will never be re-released, so keeping it in the active reactor (and
        the `versions:set -Dexcludes=...` footgun that came with it) served no further purpose.
    -->
    <modules>
        <module>srcmorph</module>
        <module>srcmorph-cli</module>
        <module>srcmorph-maven-plugin</module>
    </modules>

    <dependencyManagement>
        <dependencies>
            <!--
                Converge slf4j-api: the llama dependency brings slf4j-api directly AND
                transitively (via logback-classic, which requests an older patch). Pin the
                higher version so maven-enforcer DependencyConvergence is satisfied.
            -->
            <dependency>
                <groupId>org.slf4j</groupId>
                <artifactId>slf4j-api</artifactId>
                <version>2.0.20</version>
            </dependency>
            <!--
                The SLF4J binding shipped inside srcmorph-cli's fat jar. It is slf4j-simple, not
                logback, because every logback release from 1.4.0 on is Java 11 bytecode (class-file
                major 55) while this reactor's production code targets Java 8: SLF4J's ServiceLoader
                finds LogbackServiceProvider at startup and an unpatched Java 8 JVM then dies with
                UnsupportedClassVersionError before a single log line is written. The Java 8 logback
                line (1.3.x) is end-of-life and its CVEs are fixed only in 1.5.x/1.6.x with no
                backport, so it is not an alternative. slf4j-simple is six classes from the same
                release train as slf4j-api, all major 52, with no configuration or socket layer.
                Pinned here so the direct declaration in srcmorph-cli and whatever
                net.ladenthin:llama brings transitively stay converged for maven-enforcer.
                .github/verify-bytecode-version.sh enforces the class-file floor on the built jars.
            -->
            <dependency>
                <groupId>org.slf4j</groupId>
                <artifactId>slf4j-simple</artifactId>
                <version>2.0.20</version>
            </dependency>
            <!--
                Pin logback-classic for the TEST scope only: AiFieldGenerationSupportTest attaches a
                logback ListAppender to capture log output, and LogCaptor-style capture needs logback
                specifically. Test scope never reaches a published artifact or the fat jar, so its
                Java 11 bytecode is harmless here. The managed version wins over whatever the llama
                dependency brings transitively, satisfying maven-enforcer's DependencyConvergence.
            -->
            <dependency>
                <groupId>ch.qos.logback</groupId>
                <artifactId>logback-classic</artifactId>
                <version>1.6.5</version>
            </dependency>
            <!--
                JSON/YAML binding for srcmorph-cli's CConfiguration. Both artifacts are pinned to the
                SAME jackson.version (declared in srcmorph-cli/pom.xml) because they ship from the same
                jackson release train and each transitively pulls jackson-core/jackson-annotations at a
                matching version — pinning them together here keeps maven-enforcer's
                dependencyConvergence rule satisfied without needing a separate jackson-core/
                jackson-annotations/snakeyaml pin (nothing else in the reactor depends on jackson or
                snakeyaml, so there is no other version to converge against).
            -->
            <dependency>
                <groupId>com.fasterxml.jackson.core</groupId>
                <artifactId>jackson-databind</artifactId>
                <version>${jackson.version}</version>
            </dependency>
            <dependency>
                <groupId>com.fasterxml.jackson.dataformat</groupId>
                <artifactId>jackson-dataformat-yaml</artifactId>
                <version>${jackson.version}</version>
            </dependency>
            <!--
                Converge jspecify: declared directly (compile scope) in every child module while
                net.ladenthin:llama brings 1.0.0 transitively, also at compile scope — this is the
                pair that broke maven-enforcer's DependencyConvergence in Dependabot PR #169
                (merged despite a red Build check). Pin the higher version so it wins everywhere.
            -->
            <dependency>
                <groupId>org.jspecify</groupId>
                <artifactId>jspecify</artifactId>
                <version>1.0.1</version>
            </dependency>
            <!--
                COMPILE-ONLY, and that is the whole point. checker-qual is class-file major 55 from
                4.0.0 on, its annotations are @Retention(RUNTIME), and anything that reflects over an
                annotated element (Jackson does, and srcmorph-cli binds its whole configuration with
                Jackson) loads them — so a copy inside the fat jar is an UnsupportedClassVersionError
                waiting for a Java 8 consumer.

                Pinning the SHIPPED copy to the last Java 8 line (3.55.1) does not work and was
                reverted: the Nullness Checker resolves its own qualifiers through javac's symbol
                table, i.e. the COMPILE CLASSPATH, so a 3.x checker-qual under the 4.x processor
                fails every build with "Could not load type:
                org.checkerframework.framework.qual.DoesNotUnrefineReceiver". Processor and
                qualifiers must share a major version.

                Scope `provided` satisfies both constraints at once: 4.3.0 on the compile classpath
                where the checker needs it, and excluded from consumers' transitive graph AND from
                the fat jar (jar-with-dependencies takes scope runtime), so no checker-qual class of
                any version reaches a consumer's JVM. <optional>true</optional> alone would not have
                been enough — that descriptor filters on scope only. Safe because no source in this
                reactor imports org.checkerframework.

                It doubles as the convergence pin (same shape as jspecify above): net.ladenthin:llama
                brings checker-qual transitively. .github/verify-bytecode-version.sh enforces the
                resulting class-file floor on the built jars.
            -->
            <dependency>
                <groupId>org.checkerframework</groupId>
                <artifactId>checker-qual</artifactId>
                <version>4.3.1</version>
                <scope>provided</scope>
            </dependency>
        </dependencies>
    </dependencyManagement>

    <build>
        <pluginManagement>
            <plugins>
                <!--
                    Bound by the clean and default lifecycles (clean, resources, install, deploy) or invoked by prefix
                    (mvn dependency:...) and configured nowhere else, so their versions came from whichever Maven ran the
                    build: Maven 3.10.0 binds clean 3.5.0, resources 3.5.0, install 3.2.0 and deploy 3.2.0 and manages no
                    dependency plugin (dependency:... then takes the newest release); Maven 3.9 binds clean 3.2.0, resources
                    3.3.1, install and deploy 3.1.x and manages dependency 3.7.0. Stated here so the build does not depend on
                    the Maven that runs it, and so check-versions.py compares them across the repositories.
                -->
                <plugin>
                    <groupId>org.apache.maven.plugins</groupId>
                    <artifactId>maven-clean-plugin</artifactId>
                    <version>3.5.0</version>
                </plugin>
                <plugin>
                    <groupId>org.apache.maven.plugins</groupId>
                    <artifactId>maven-resources-plugin</artifactId>
                    <version>3.5.0</version>
                </plugin>
                <plugin>
                    <groupId>org.apache.maven.plugins</groupId>
                    <artifactId>maven-install-plugin</artifactId>
                    <version>3.2.0</version>
                </plugin>
                <plugin>
                    <groupId>org.apache.maven.plugins</groupId>
                    <artifactId>maven-deploy-plugin</artifactId>
                    <version>3.2.0</version>
                </plugin>
                <plugin>
                    <groupId>org.apache.maven.plugins</groupId>
                    <artifactId>maven-dependency-plugin</artifactId>
                    <version>3.11.0</version>
                </plugin>
            </plugins>
        </pluginManagement>
    </build>

    <profiles>
        <!--
            Signs and publishes every reactor module in one `mvn -P release deploy` (the
            java-llama.cpp reactor pattern). GPG signing at verify + Central Portal publishing;
            autoPublish completes the deployment once portal validation passes.
        -->
        <profile>
            <id>release</id>
            <build>
                <plugins>
                    <plugin>
                        <groupId>org.apache.maven.plugins</groupId>
                        <artifactId>maven-gpg-plugin</artifactId>
                        <!-- No parent pluginManagement above this pom to inherit a default version
                             from; must match the pin in the plugin module's own pluginManagement. -->
                        <version>3.2.8</version>
                        <executions>
                            <execution>
                                <id>sign-artifacts</id>
                                <phase>verify</phase>
                                <goals><goal>sign</goal></goals>
                                <configuration>
                                    <keyname>${gpg.keyname}</keyname>
                                    <gpgArguments>
                                        <arg>--pinentry-mode</arg>
                                        <arg>loopback</arg>
                                    </gpgArguments>
                                </configuration>
                            </execution>
                        </executions>
                    </plugin>

                    <plugin>
                        <groupId>org.sonatype.central</groupId>
                        <artifactId>central-publishing-maven-plugin</artifactId>
                        <!-- No parent pluginManagement above this pom to inherit a default version
                             from; must match the pin in the plugin module's own pluginManagement. -->
                        <version>0.12.0</version>
                        <extensions>true</extensions>
                        <configuration>
                            <publishingServerId>central</publishingServerId>
                            <autoPublish>true</autoPublish>
                            <!-- validated: wait only for portal validation (where real errors surface), not the slow server-side publish; autoPublish completes it -->
                            <waitUntil>validated</waitUntil>
                            <!-- seconds; generous headroom for the validation poll (default 1800) -->
                            <waitMaxTime>21600</waitMaxTime>
                        </configuration>
                    </plugin>
                </plugins>
            </build>
        </profile>
    </profiles>
</project>