Description

<dependency>
    <groupId>io.github.demchaav</groupId>
    <artifactId>graph-compose-core</artifactId>
    <version>2.4.0</version>
</dependency>

<?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>

    <groupId>io.github.demchaav</groupId>
    <artifactId>graph-compose-core</artifactId>
    <version>2.4.0</version>

    <name>GraphCompose Core</name>
    <description>A declarative layout engine for programmatic document generation, implemented primarily in Java. This is the lean engine coordinate; depend on the `graph-compose` artifact for the drop-in, PDF-capable install.</description>
    <url>https://github.com/DemchaAV/GraphCompose</url>

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

    <developers>
        <developer>
            <id>DemchaAV</id>
            <name>Artem Demchyshyn</name>
            <email>demchishynartem@gmail.com</email>
            <url>https://github.com/DemchaAV</url>
            <roles>
                <role>Lead Developer</role>
                <role>Architect</role>
            </roles>
            <timezone>UTC 0</timezone>
        </developer>
    </developers>

    <scm>
        <connection>scm:git:https://github.com/DemchaAV/GraphCompose.git</connection>
        <developerConnection>scm:git:ssh://git@github.com/DemchaAV/GraphCompose.git</developerConnection>
        <url>https://github.com/DemchaAV/GraphCompose/tree/main</url>
    </scm>

    <properties>
        <!-- Toolchain -->
        <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
        <maven.compiler.release>17</maven.compiler.release>

        <!-- Runtime / library dependencies -->
        <flexmark.version>0.64.8</flexmark.version>
        <logback.version>1.6.3</logback.version>
        <lombok.version>1.18.48</lombok.version>
        <slf4j.version>2.0.19</slf4j.version>

        <!-- Test dependencies -->
        <assertj.version>3.27.7</assertj.version>
        <junit.bom.version>6.1.3</junit.bom.version>
        <mockito.version>5.23.0</mockito.version>
        <byteBuddy.version>1.18.13</byteBuddy.version>
        <archunit.version>1.5.0</archunit.version>
        <jqwik.version>1.10.1</jqwik.version>

        <!-- Bundled fonts / emoji, pulled in at test scope only. Pinned to the
             independent 1.0.0 line (not bumped in engine lockstep); keep in step
             with bundle/pom.xml's graphcompose.fonts.version. -->
        <graphcompose.fonts.version>1.1.0</graphcompose.fonts.version>
        <graphcompose.emoji.version>1.0.0</graphcompose.emoji.version>

        <!-- Build plugins -->
        <central.publishing.plugin.version>0.11.0</central.publishing.plugin.version>
        <maven.compiler.plugin.version>3.16.0</maven.compiler.plugin.version>
        <maven.enforcer.plugin.version>3.6.3</maven.enforcer.plugin.version>
        <maven.gpg.plugin.version>3.2.8</maven.gpg.plugin.version>
        <maven.jar.plugin.version>3.5.1</maven.jar.plugin.version>
        <maven.javadoc.plugin.version>3.12.0</maven.javadoc.plugin.version>
        <maven.source.plugin.version>3.4.0</maven.source.plugin.version>
        <maven.surefire.plugin.version>3.6.0</maven.surefire.plugin.version>
        <jacoco.plugin.version>0.8.15</jacoco.plugin.version>

        <!--
            Empty default for the surefire argLine. JaCoCo's prepare-agent
            prepends its javaagent to this property; declaring it empty here means
            surefire's `@{argLine}` resolves to empty (not the literal `@{argLine}`,
            which the JVM would treat as an argfile) when coverage is skipped
            (-Djacoco.skip=true) or prepare-agent otherwise does not run.
        -->
        <argLine></argLine>

        <!-- Minimum toolchain (enforced by maven-enforcer-plugin) -->
        <enforcer.requireMavenVersion>3.8.0</enforcer.requireMavenVersion>
        <enforcer.requireJavaVersion>17</enforcer.requireJavaVersion>

        <!-- Binary compatibility baseline (japicmp profile) -->
        <japicmp.version>0.26.2</japicmp.version>
        <!-- 2.x binary-compatibility baseline: the published graph-compose-core on
             Maven Central. The 2.0 major transition is complete, so the gate
             enforces binary compatibility against 2.0.0 (see the japicmp profile)
             — proven: 2.0.1-SNAPSHOT + a reduced-access public method fails with
             METHOD_LESS_ACCESSIBLE. It must stay STRICTLY OLDER than the working
             version, which VersionConsistencyGuardTest enforces: a baseline equal
             to the version being built is NOT a no-op — japicmp resolves it to this
             build's own artifact and reports no differences, so the gate passes
             having compared the release with itself (measured on a simulated 3.0.0
             cut). Moving this pin onto a new major therefore waits until that
             major's first release is on Central; docs/api-stability.md (Opening a
             major) records how the templates gate handles that cycle, and this one
             needs the same decision when 3.0 opens. -->
        <japicmp.baseline>2.0.0</japicmp.baseline>

        <!--
            GPG signing — opted in via -Dgpg.skip=false (the publish
            workflow does this on tag pushes). Default true so a
            maintainer running `mvn -P release package` locally does
            not need a configured GPG key.
        -->
        <gpg.skip>true</gpg.skip>
    </properties>

    <dependencyManagement>
        <dependencies>
            <dependency>
                <groupId>org.junit</groupId>
                <artifactId>junit-bom</artifactId>
                <version>${junit.bom.version}</version>
                <type>pom</type>
                <scope>import</scope>
            </dependency>
        </dependencies>
    </dependencyManagement>

    <dependencies>
        <!-- Main dependencies -->
        <dependency>
            <groupId>org.projectlombok</groupId>
            <artifactId>lombok</artifactId>
            <version>${lombok.version}</version>
            <scope>provided</scope>
        </dependency>

        <dependency>
            <groupId>org.slf4j</groupId>
            <artifactId>slf4j-api</artifactId>
            <version>${slf4j.version}</version>
        </dependency>

        <!--
            Flexmark markdown parser. F3 (v1.6.7) narrowed `flexmark-all`
            down to the modules actually referenced by
            `com.demcha.compose.engine.text.markdown.MarkDownParser`:
            - `flexmark`           — Parser + `com.vladsch.flexmark.ast.*`
                                     (Heading, ListItem, Emphasis, etc.)
            - `flexmark-util-ast`  — Node, NodeVisitor, VisitHandler
            - `flexmark-util-data` — MutableDataSet
            No extension modules (tables, footnotes, gfm) are used.
        -->
        <dependency>
            <groupId>com.vladsch.flexmark</groupId>
            <artifactId>flexmark</artifactId>
            <version>${flexmark.version}</version>
        </dependency>
        <dependency>
            <groupId>com.vladsch.flexmark</groupId>
            <artifactId>flexmark-util-ast</artifactId>
            <version>${flexmark.version}</version>
        </dependency>
        <dependency>
            <groupId>com.vladsch.flexmark</groupId>
            <artifactId>flexmark-util-data</artifactId>
            <version>${flexmark.version}</version>
        </dependency>

        <!-- Test dependencies -->
        <!--
            The bundled Google fonts and colour-emoji glyphs live in the sibling
            graph-compose-fonts / graph-compose-emoji modules and are pulled in at
            TEST scope so the engine's visual / snapshot / emoji suites render with
            the real binaries. Test scope is not transitive, so the engine's own
            published jar stays fonts-free — an engine consumer never drags these
            in. A reactor build satisfies them from the just-built siblings; a
            standalone `-f core/pom.xml` build resolves them from the local repository,
            so a fonts version that is not published yet needs `mvn install -pl fonts`.
        -->
        <dependency>
            <groupId>io.github.demchaav</groupId>
            <artifactId>graph-compose-fonts</artifactId>
            <version>${graphcompose.fonts.version}</version>
            <scope>test</scope>
        </dependency>
        <dependency>
            <groupId>io.github.demchaav</groupId>
            <artifactId>graph-compose-emoji</artifactId>
            <version>${graphcompose.emoji.version}</version>
            <scope>test</scope>
        </dependency>

        <dependency>
            <groupId>ch.qos.logback</groupId>
            <artifactId>logback-classic</artifactId>
            <version>${logback.version}</version>
            <scope>test</scope>
        </dependency>

        <dependency>
            <groupId>org.junit.jupiter</groupId>
            <artifactId>junit-jupiter</artifactId>
            <scope>test</scope>
        </dependency>
        <dependency>
            <groupId>org.assertj</groupId>
            <artifactId>assertj-core</artifactId>
            <version>${assertj.version}</version>
            <scope>test</scope>
        </dependency>
        <dependency>
            <groupId>org.mockito</groupId>
            <artifactId>mockito-core</artifactId>
            <version>${mockito.version}</version>
            <scope>test</scope>
            <exclusions>
                <exclusion>
                    <groupId>net.bytebuddy</groupId>
                    <artifactId>byte-buddy</artifactId>
                </exclusion>
            </exclusions>
        </dependency>
        <dependency>
            <groupId>net.bytebuddy</groupId>
            <artifactId>byte-buddy</artifactId>
            <version>${byteBuddy.version}</version>
            <scope>test</scope>
        </dependency>
        <dependency>
            <groupId>org.mockito</groupId>
            <artifactId>mockito-junit-jupiter</artifactId>
            <version>${mockito.version}</version>
            <scope>test</scope>
        </dependency>

        <!--
            ArchUnit drives the structural architecture guards (bytecode-level,
            location-independent) that complement the text-scanning guards in
            com.demcha.documentation. Test scope only; never on the published
            engine's compile/runtime classpath.
        -->
        <dependency>
            <groupId>com.tngtech.archunit</groupId>
            <artifactId>archunit</artifactId>
            <version>${archunit.version}</version>
            <scope>test</scope>
        </dependency>

        <!--
            jqwik drives the property-based layout-invariant tests: pure
            engine functions (tokenization reconstruction, z-order permutation,
            row-weight guards) checked against generated inputs. Test scope only.
        -->
        <dependency>
            <groupId>net.jqwik</groupId>
            <artifactId>jqwik</artifactId>
            <version>${jqwik.version}</version>
            <scope>test</scope>
        </dependency>

        <!--
            Benchmark-only comparison dependencies (iText, openHTMLToPDF,
            JasperReports) live in the sibling `benchmarks/` Maven module
            so the main project's test classpath stays free of foreign
            comparison libraries that are not part of GraphCompose. Run
            benchmarks via `mvnw -f benchmarks/pom.xml ...` or the
            scripts/run-benchmarks.ps1 wrapper.
        -->
    </dependencies>

    <build>
        <testResources>
            <!--
                Default test resources only. The bundled Google fonts and
                colour-emoji glyphs are no longer copied in from the sibling
                source dirs — they reach the test classpath via the
                graph-compose-fonts / graph-compose-emoji test-scope artifacts
                (see <dependencies> above), which package the same
                src/main/resources layout, so classpath lookups are unchanged.
            -->
            <testResource>
                <directory>src/test/resources</directory>
            </testResource>
        </testResources>

        <!--
            Pin the default-lifecycle plugins (clean / install / site /
            resources / deploy) so requirePluginVersions in the enforcer
            block below has nothing to flag. Versions match what Maven
            3.9.x currently resolves out-of-the-box; the explicit pin
            stops a future Maven upgrade from silently shifting the
            plugin set we build against.
        -->
        <pluginManagement>
            <plugins>
                <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-install-plugin</artifactId>
                    <version>3.1.4</version>
                </plugin>
                <plugin>
                    <groupId>org.apache.maven.plugins</groupId>
                    <artifactId>maven-site-plugin</artifactId>
                    <version>3.22.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-deploy-plugin</artifactId>
                    <version>3.1.4</version>
                </plugin>
            </plugins>
        </pluginManagement>

        <plugins>
            <!--
                Build-time precondition enforcement. Three rules:
                * requireJavaVersion: blocks builds on JDK < 17 (the
                  declared baseline). Catches "works on my Java 21,
                  silently breaks on the JDK 17 CI matrix" drift.
                * requireMavenVersion: blocks Maven < 3.8.0 — the
                  oldest version that fully supports the resolver
                  features the central-publishing plugin (Track D3)
                  needs to ship Maven Central artefacts.
                * requirePluginVersions: every plugin must declare an
                  explicit <version>. Stops the inherited "latest" or
                  reactor-default drift that broke the v1.6.0 release
                  (cf. PR-7.1 exec-plugin lesson). Tracked as 1.6.6 E2.
            -->
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-enforcer-plugin</artifactId>
                <version>${maven.enforcer.plugin.version}</version>
                <executions>
                    <execution>
                        <id>enforce-toolchain-and-plugin-versions</id>
                        <phase>validate</phase>
                        <goals>
                            <goal>enforce</goal>
                        </goals>
                        <configuration>
                            <rules>
                                <requireMavenVersion>
                                    <version>[${enforcer.requireMavenVersion},)</version>
                                    <message>GraphCompose requires Maven ${enforcer.requireMavenVersion} or newer.</message>
                                </requireMavenVersion>
                                <requireJavaVersion>
                                    <version>[${enforcer.requireJavaVersion},)</version>
                                    <message>GraphCompose requires JDK ${enforcer.requireJavaVersion} or newer.</message>
                                </requireJavaVersion>
                                <requirePluginVersions>
                                    <banLatest>true</banLatest>
                                    <banRelease>true</banRelease>
                                    <banSnapshots>true</banSnapshots>
                                    <message>Every plugin must declare an explicit non-LATEST/RELEASE version. See PR-7.1 (exec-plugin drift) for the lesson.</message>
                                </requirePluginVersions>
                            </rules>
                            <fail>true</fail>
                        </configuration>
                    </execution>
                </executions>
            </plugin>

            <!-- Java compilation -->
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-compiler-plugin</artifactId>
                <version>${maven.compiler.plugin.version}</version>
                <configuration>
                    <release>${maven.compiler.release}</release>
                    <annotationProcessorPaths>
                        <path>
                            <groupId>org.projectlombok</groupId>
                            <artifactId>lombok</artifactId>
                            <version>${lombok.version}</version>
                        </path>
                    </annotationProcessorPaths>
                </configuration>
            </plugin>

            <!-- Test execution -->
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-surefire-plugin</artifactId>
                <version>${maven.surefire.plugin.version}</version>
                <configuration>
                    <!--
                        @{argLine} is the late-evaluated `argLine` property JaCoCo's
                        prepare-agent prepends its javaagent to; keeping it here (rather
                        than a bare literal) lets the coverage agent attach alongside the
                        Mockito inline-mock agent instead of one clobbering the other. It
                        resolves to the empty <argLine> default in <properties> when
                        coverage is skipped, so the Mockito-only run still works.
                    -->
                    <argLine>@{argLine} -javaagent:${settings.localRepository}/org/mockito/mockito-core/${mockito.version}/mockito-core-${mockito.version}.jar</argLine>
                </configuration>
            </plugin>

            <!--
                Coverage agent. prepare-agent sets the `argLine` property (picked
                up by surefire above) so each test run writes target/jacoco.exec;
                the per-module HTML report is a convenience. The cross-module
                aggregate that counts the qa suites' coverage of the engine lives
                in the dedicated `graph-compose-coverage` module (report-aggregate).
            -->
            <plugin>
                <groupId>org.jacoco</groupId>
                <artifactId>jacoco-maven-plugin</artifactId>
                <version>${jacoco.plugin.version}</version>
                <executions>
                    <execution>
                        <id>jacoco-prepare-agent</id>
                        <goals>
                            <goal>prepare-agent</goal>
                        </goals>
                    </execution>
                    <execution>
                        <id>jacoco-report</id>
                        <phase>test</phase>
                        <goals>
                            <goal>report</goal>
                        </goals>
                    </execution>
                </executions>
            </plugin>

            <!--
                Build a tests-classifier jar so the sibling `benchmarks/`
                module can reuse the test-only fixtures (com.demcha.mock.*,
                etc.) without duplicating them. The artifact is
                graph-compose-core-${version}-tests.jar in the local repository
                after `mvn install`. It is a LOCAL build aid only: the
                `release` profile disables this execution (phase=none) so the
                tests jar is never attached and therefore never deployed to
                Maven Central. See the release profile below.
            -->
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-jar-plugin</artifactId>
                <version>${maven.jar.plugin.version}</version>
                <executions>
                    <execution>
                        <id>attach-test-jar</id>
                        <goals>
                            <goal>test-jar</goal>
                        </goals>
                        <!--
                            No <excludes> needed: the bundled fonts / emoji are no
                            longer copied into test-classes (they come from the
                            graph-compose-fonts / graph-compose-emoji test-scope
                            artifacts), so the tests-jar naturally carries only the
                            engine's own fixtures (e.g. com.demcha.mock) that the
                            benchmarks module consumes.
                        -->
                    </execution>
                </executions>
            </plugin>

            <!--
                Javadoc validation for the module.

                The scope is the whole of `com.demcha.compose`, root package
                included. It was `com.demcha.compose.document`, which left
                `GraphCompose` — the entry point every README snippet starts
                from — as the one public class nothing linted; it had carried a
                doclint error since the layout move without anything reporting
                it, because the published Javadoc jar is built with
                `doclint=none` and cannot report one either.

                This also pulls in `com.demcha.compose.engine`, the `@Internal`
                surface. That is a consequence rather than a goal: with
                `subpackages` set, `excludePackageNames` does not take effect
                here (tried both `a.b.engine:a.b.engine.*` and `a.b.engine*` —
                the package is emitted either way). It costs warnings, not
                failures, since `failOnError` fails on errors only.
            -->
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-javadoc-plugin</artifactId>
                <version>${maven.javadoc.plugin.version}</version>
                <configuration>
                    <doclint>all</doclint>
                    <failOnError>true</failOnError>
                    <show>public</show>
                    <quiet>true</quiet>
                    <subpackages>com.demcha.compose</subpackages>
                </configuration>
            </plugin>
        </plugins>
    </build>

    <profiles>
        <!--
            Maven Central / release-publishing artefacts. Activated
            with `-P release`. Produces the `*-sources.jar` and
            `*-javadoc.jar` Maven Central requires alongside the main
            `.jar`. Activated by `cut-release.ps1` (when the
            central-publishing plugin lands in Track D3) and by the
            publish workflow (Track D4); never activated by the default
            local build so a maintainer's everyday `mvnw verify` does
            not pay the extra ~30 s of source / javadoc packaging.
            Tracked in v1.6.6 stabilization (Track D1).
        -->
        <profile>
            <id>release</id>
            <build>
                <plugins>
                    <!--
                        Keep the tests-classifier jar OUT of the published
                        artifact set. The default build attaches a
                        graph-compose-core-${version}-tests.jar (for the local
                        benchmarks module); on a release `deploy` that jar
                        would otherwise be uploaded to Maven Central, where it
                        is pure dead weight (test classes + heavy golden
                        snapshot / visual-baseline resources). Re-declaring the
                        same execution id bound to phase=none unbinds it, so
                        the release build never produces or attaches it.
                    -->
                    <plugin>
                        <groupId>org.apache.maven.plugins</groupId>
                        <artifactId>maven-jar-plugin</artifactId>
                        <version>${maven.jar.plugin.version}</version>
                        <executions>
                            <execution>
                                <id>attach-test-jar</id>
                                <phase>none</phase>
                            </execution>
                        </executions>
                    </plugin>
                    <plugin>
                        <groupId>org.apache.maven.plugins</groupId>
                        <artifactId>maven-source-plugin</artifactId>
                        <version>${maven.source.plugin.version}</version>
                        <executions>
                            <execution>
                                <id>attach-sources</id>
                                <phase>package</phase>
                                <goals>
                                    <goal>jar-no-fork</goal>
                                </goals>
                            </execution>
                        </executions>
                    </plugin>
                    <plugin>
                        <groupId>org.apache.maven.plugins</groupId>
                        <artifactId>maven-javadoc-plugin</artifactId>
                        <version>${maven.javadoc.plugin.version}</version>
                        <executions>
                            <execution>
                                <id>attach-javadocs</id>
                                <phase>package</phase>
                                <goals>
                                    <goal>jar</goal>
                                </goals>
                                <configuration>
                                    <!--
                                        Lombok-generated members and the
                                        `@Internal` engine surface are not
                                        part of the public Javadoc; skip
                                        anything that would fail to resolve
                                        rather than blocking the publish.
                                    -->
                                    <doclint>none</doclint>
                                    <failOnError>false</failOnError>
                                    <quiet>true</quiet>
                                </configuration>
                            </execution>
                        </executions>
                    </plugin>
                    <!--
                        GPG signing of the four published artefacts
                        (main jar + sources + javadoc + pom). Maven
                        Central rejects unsigned uploads.

                        Local default: `<gpg.skip>true</gpg.skip>` (set
                        in <properties>) so `mvn -P release package`
                        works without a configured GPG key. The publish
                        workflow (Track D4) flips it with
                        -Dgpg.skip=false.

                        The `gpgArguments` pinentry-mode=loopback is
                        required for non-interactive runs (CI), where
                        the passphrase arrives via
                        MAVEN_GPG_PASSPHRASE / -Dgpg.passphrase and
                        there is no TTY for gpg-agent to prompt on.
                    -->
                    <plugin>
                        <groupId>org.apache.maven.plugins</groupId>
                        <artifactId>maven-gpg-plugin</artifactId>
                        <version>${maven.gpg.plugin.version}</version>
                        <executions>
                            <execution>
                                <id>sign-artifacts</id>
                                <phase>verify</phase>
                                <goals>
                                    <goal>sign</goal>
                                </goals>
                                <configuration>
                                    <skip>${gpg.skip}</skip>
                                    <gpgArguments>
                                        <arg>--pinentry-mode</arg>
                                        <arg>loopback</arg>
                                    </gpgArguments>
                                </configuration>
                            </execution>
                        </executions>
                    </plugin>
                    <!--
                        Sonatype central-publishing-maven-plugin: the
                        modern replacement for the old `nexus-staging-maven-plugin`
                        + manual staging-repository flow. Uploads the
                        signed artefacts (main + sources + javadoc + pom)
                        to the namespace verified at central.sonatype.com.

                        Configuration:
                          publishingServerId=central — matches the
                            <server id="central"> entry the publish
                            workflow (Track D4) writes into
                            ~/.m2/settings.xml from the CENTRAL_USERNAME
                            / CENTRAL_TOKEN repo secrets.
                          autoPublish=false — uploads to the validation
                            queue but does NOT auto-release. The
                            maintainer flips the switch on
                            central.sonatype.com after a sanity check
                            on the first publish; subsequent releases
                            can flip this to true in the workflow when
                            we are confident.
                          waitUntil=validated — block the Maven build
                            until Sonatype's validator confirms the
                            upload meets the Central requirements
                            (signed artefacts, sources/javadoc jars,
                            valid POM metadata, etc.). Surfaces errors
                            inside the workflow run rather than
                            silently leaving a stuck upload.
                          <extensions>true</extensions> — required so
                            the plugin participates in the build
                            lifecycle as a packaging extension.

                        Requires (configured by Track D4 workflow):
                          - CENTRAL_USERNAME / CENTRAL_TOKEN secrets
                          - namespace `io.github.demchaav` verified on
                            central.sonatype.com (one-time, via GitHub
                            auth or DNS TXT record).
                    -->
                    <plugin>
                        <groupId>org.sonatype.central</groupId>
                        <artifactId>central-publishing-maven-plugin</artifactId>
                        <version>${central.publishing.plugin.version}</version>
                        <extensions>true</extensions>
                        <configuration>
                            <publishingServerId>central</publishingServerId>
                            <autoPublish>false</autoPublish>
                            <waitUntil>validated</waitUntil>
                        </configuration>
                    </plugin>
                </plugins>
            </build>
        </profile>

        <!--
            Binary-compatibility gate. Activated with `-P japicmp`. Resolves the
            baseline artifact (the published graph-compose-core pinned by the
            japicmp.baseline property) from Maven Central — no extra repository, so
            consumers inherit nothing. The baseline is the current major's floor
            (2.0.0 for the whole 2.x line), advancing only at the next major, so the
            gate holds every 2.x build binary-compatible with the 2.0.0 public
            surface. Fails the build on any binary-incompatible modification to the
            public surface; source-incompatible changes are reported but do not fail
            (yet) so the policy can be phased in.
        -->
        <profile>
            <id>japicmp</id>
            <build>
                <plugins>
                    <plugin>
                        <groupId>com.github.siom79.japicmp</groupId>
                        <artifactId>japicmp-maven-plugin</artifactId>
                        <version>${japicmp.version}</version>
                        <executions>
                            <execution>
                                <id>japicmp-against-baseline</id>
                                <phase>verify</phase>
                                <goals>
                                    <goal>cmp</goal>
                                </goals>
                            </execution>
                        </executions>
                        <configuration>
                            <oldVersion>
                                <dependency>
                                    <groupId>io.github.demchaav</groupId>
                                    <artifactId>graph-compose-core</artifactId>
                                    <version>${japicmp.baseline}</version>
                                </dependency>
                            </oldVersion>
                            <newVersion>
                                <file>
                                    <path>${project.build.directory}/${project.build.finalName}.jar</path>
                                </file>
                            </newVersion>
                            <parameter>
                                <onlyModified>true</onlyModified>
                                <!--
                                    2.x binary-compatibility gate. The 2.0 major transition is
                                    complete and 2.0.0 is the published baseline, so binary breaks
                                    now FAIL the build — an accidental incompatible change to the
                                    public surface can no longer ship in a 2.x minor/patch. (Proven:
                                    on a 2.0.1-SNAPSHOT working version, reducing a public method's
                                    access fails with METHOD_LESS_ACCESSIBLE.) Source incompatibilities
                                    stay report-only for now — a source break that is binary-compatible
                                    (e.g. adding a default interface method) is documented in the report
                                    without failing CI; tighten to true when the 2.x source-compat
                                    policy is finalized.
                                -->
                                <breakBuildOnBinaryIncompatibleModifications>true</breakBuildOnBinaryIncompatibleModifications>
                                <breakBuildOnSourceIncompatibleModifications>false</breakBuildOnSourceIncompatibleModifications>
                                <includeSynthetic>false</includeSynthetic>
                                <reportOnlyFilename>true</reportOnlyFilename>
                                <skipPomModules>true</skipPomModules>
                                <!--
                                    Exclude the complete Internal surface, exactly as
                                    docs/api-stability.md defines it: the two package trees marked
                                    @Internal at the package level — com.demcha.compose.engine.** (the
                                    engine, incl. text/markdown/measurement helpers and the render
                                    handoff payloads) and com.demcha.compose.document.layout.** (the
                                    compiler, NodeDefinitionSupport, placement/measure/split contracts,
                                    and the layout.payloads DTOs) — plus any element carrying the
                                    per-element @Internal marker anywhere else. These carry no
                                    binary-compatibility promise (§ 1), so the gate must not fail on
                                    them; only the Stable public surface (document.api/dsl/node/style,
                                    chart/svg/font, GraphCompose) is enforced. The `.**` suffix matches
                                    the package and all sub-packages. (The former 1.x transitional
                                    excludes — TextMeasurementSystem, ConfigLoader — are gone: those
                                    removals predate the 2.0.0 baseline, so it no longer contains them.)
                                -->
                                <excludes>
                                    <exclude>com.demcha.compose.engine.**</exclude>
                                    <exclude>com.demcha.compose.document.layout.**</exclude>
                                    <exclude>@com.demcha.compose.document.api.Internal</exclude>
                                </excludes>
                            </parameter>
                        </configuration>
                    </plugin>
                </plugins>
            </build>
        </profile>
    </profiles>
</project>