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

    <parent>
        <groupId>eu.exeris</groupId>
        <artifactId>exeris-sdk-parent</artifactId>
        <version>0.12.0</version>
        <relativePath>../exeris-sdk-parent</relativePath>
    </parent>

    <artifactId>exeris-sdk-annotations</artifactId>
    <packaging>jar</packaging>

    <name>Exeris SDK :: Annotations</name>
    <description>
        Pure annotation API for Entity-First development on the Exeris platform.
        Zero runtime dependencies. The annotations describe domain shape, actions,
        validation, security, and system fields; they are consumed at compile time
        by exeris-tooling processors and generators.
    </description>

    <properties>
        <!-- Outside the semver gate, which the root pom's `semver` profile otherwise binds for
             every jar module. Why, at the foot of this file. -->
        <japicmp.skip>true</japicmp.skip>
    </properties>

    <dependencies>
        <!-- Test-only: contract test for SOURCE retention + @Target invariants.
             No runtime/compile dependencies are added to this jar — the
             published artifact remains pure annotations. -->
        <dependency>
            <groupId>org.junit.jupiter</groupId>
            <artifactId>junit-jupiter</artifactId>
            <scope>test</scope>
        </dependency>
        <dependency>
            <groupId>org.assertj</groupId>
            <artifactId>assertj-core</artifactId>
            <scope>test</scope>
        </dependency>
        <!-- Reads the generated annotation catalog back in AnnotationCatalogContractTest.
             Test scope only: it is absent from the published jar's dependency tree, which
             the enforcer rule below continues to prove. -->
        <dependency>
            <groupId>tools.jackson.core</groupId>
            <artifactId>jackson-databind</artifactId>
            <scope>test</scope>
        </dependency>
    </dependencies>

    <build>
        <plugins>
            <!-- The annotation catalog is generated from THIS module's own sources, by a
                 processor on the javac processor path. That path is not this project's
                 dependency tree: the published jar stays dependency-free, and the enforcer
                 rule below still proves it. -->
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-compiler-plugin</artifactId>
                <executions>
                    <execution>
                        <id>default-compile</id>
                        <configuration>
                            <annotationProcessorPaths>
                                <path>
                                    <groupId>eu.exeris</groupId>
                                    <artifactId>exeris-sdk-annotation-catalog</artifactId>
                                    <version>${project.version}</version>
                                </path>
                            </annotationProcessorPaths>
                            <compilerArgs>
                                <arg>-Aexeris.catalog.sdkVersion=${project.version}</arg>
                            </compilerArgs>
                        </configuration>
                    </execution>
                    <execution>
                        <id>default-testCompile</id>
                        <configuration>
                            <!-- The catalog describes the published surface. Running the
                                 processor again over the tests would reopen the same output
                                 file and fail, and a catalog that included test fixtures
                                 would be describing something nobody ships. -->
                            <proc>none</proc>
                        </configuration>
                    </execution>
                </executions>
            </plugin>
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-source-plugin</artifactId>
                <executions>
                    <execution>
                        <id>attach-sources</id>
                        <goals><goal>jar-no-fork</goal></goals>
                    </execution>
                </executions>
            </plugin>
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-javadoc-plugin</artifactId>
                <configuration>
                    <!-- These modules carry no javadoc warning at all, so the cheapest possible
                         gate is the real one: any new undocumented public member fails the build
                         here rather than shipping to Maven Central undocumented. exeris-sdk-source-model
                         cannot use this — its builder setters are deliberately undocumented (their
                         components carry the prose) — and is gated by JavadocCompletenessTest instead. -->
                    <failOnWarnings>true</failOnWarnings>
                </configuration>
                <executions>
                    <execution>
                        <id>attach-javadocs</id>
                        <goals><goal>jar</goal></goals>
                    </execution>
                </executions>
            </plugin>

            <!-- ADR-037 zero-coupling guard: fail the build if JavaParser ever
                 reaches this module's dependency tree. It belongs in
                 exeris-sdk-source-model-io only; the annotations jar must stay
                 dependency-free. The review skill catches it pre-merge; this
                 enforces it in CI. -->
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-enforcer-plugin</artifactId>
                <executions>
                    <execution>
                        <id>ban-javaparser-zero-coupling</id>
                        <phase>verify</phase>
                        <goals><goal>enforce</goal></goals>
                        <configuration>
                            <rules>
                                <bannedDependencies>
                                    <excludes>
                                        <exclude>com.github.javaparser</exclude>
                                    </excludes>
                                    <message>ADR-037: JavaParser must stay in exeris-sdk-source-model-io only — it must not appear on this module's dependency tree (zero runtime coupling).</message>
                                </bannedDependencies>
                            </rules>
                        </configuration>
                    </execution>
                </executions>
            </plugin>

            <!-- No japicmp here, on purpose (japicmp.skip above keeps the root pom's opt-in
                 `semver` profile off this module). These annotations are
                 @Retention(SOURCE): they have no runtime presence in a consumer's
                 image, so japicmp's binary-compatibility model answers a question
                 nobody is asking. Worse, it answers the real one wrongly — it
                 reports a new annotation element as METHOD_ABSTRACT_ADDED_TO_CLASS
                 whether or not the element declares a `default`, and that
                 distinction is the whole compatibility story for an annotation: an
                 element with a default leaves every existing usage compiling, one
                 without it breaks all of them.

                 AnnotationSurfaceContractTest gates this module instead, on the
                 three rules that actually hold here: no element removed, no
                 element retyped, and any new element must declare a default. -->
        </plugins>
    </build>
</project>
