<?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>com.assisi</groupId>
  <artifactId>assisi-service-parent</artifactId>
  <version>1.0.2</version>
  <packaging>pom</packaging>

  <description>
    Shared Maven parent for every assisi backend service (CONVENTIONS §M.2).
    Owns the Spring Boot / Spring Cloud BOMs, plugin versions, and any dependency
    used by two or more services. Services declare managed dependencies WITHOUT
    versions and pin one exact version of this parent, upgrading deliberately.
  </description>

  <!-- The smoke-test module is an in-repo build-verification fixture, not a
       service. Real services live in their own repos and are never added here;
       they reference this parent by version instead (see README). -->
  <modules>
    <module>smoke-test</module>
  </modules>

  <properties>
    <java.version>25</java.version>
    <maven.compiler.release>25</maven.compiler.release>
    <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
    <spring-boot.version>4.1.0</spring-boot.version>
    <spring-cloud.version>2025.1.2</spring-cloud.version>
    <archunit.version>1.4.2</archunit.version>
    <testcontainers.version>2.0.5</testcontainers.version>
    <assisi-outbox.version>1.0.1</assisi-outbox.version>
  </properties>

  <!-- NO LOMBOK — deliberate, permanent (CONVENTIONS §I.5). Java records cover
       DTOs/events/value objects; the remainder is written explicitly. Do not add
       it here "just for one module": it drags an annotation processor and an IDE
       plugin dependency across every service repo, and generated members don't
       appear in the source under review. -->

  <dependencyManagement>
    <dependencies>
      <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-dependencies</artifactId>
        <version>${spring-boot.version}</version>
        <type>pom</type>
        <scope>import</scope>
      </dependency>
      <dependency>
        <groupId>org.springframework.cloud</groupId>
        <artifactId>spring-cloud-dependencies</artifactId>
        <version>${spring-cloud.version}</version>
        <type>pom</type>
        <scope>import</scope>
      </dependency>
      <dependency>
        <groupId>org.testcontainers</groupId>
        <artifactId>testcontainers-bom</artifactId>
        <version>${testcontainers.version}</version>
        <type>pom</type>
        <scope>import</scope>
      </dependency>
      <dependency>
        <groupId>com.tngtech.archunit</groupId>
        <artifactId>archunit-junit5</artifactId>
        <version>${archunit.version}</version>
      </dependency>
      <!-- Shared libraries are managed here so services declare them WITHOUT a version (§M.2).
           The parent only MANAGES the version — it must never depend on assisi-outbox, which
           would be a cycle (outbox inherits this parent) and a coordinated-redeploy trap. -->
      <dependency>
        <groupId>com.assisi</groupId>
        <artifactId>assisi-outbox</artifactId>
        <version>${assisi-outbox.version}</version>
      </dependency>
    </dependencies>
  </dependencyManagement>

  <build>
    <pluginManagement>
      <plugins>
        <!-- Every plugin version is pinned EXPLICITLY. spring-boot-dependencies
             imported via dependencyManagement supplies NO pluginManagement (only
             spring-boot-starter-parent as a real <parent> does, and this POM is
             deliberately standalone per §M.2). Unpinned, Maven falls back to
             super-POM defaults: compiler 3.1 (2013) targets source/target 1.5 and
             fails the build; surefire 2.12.4 (2012) has no JUnit 5 provider and
             reports "Tests run: 0" with BUILD SUCCESS — silently skipping every
             test including the ArchUnit boundary rules. Both failure modes were
             reproduced empirically before this file was written (01-02-AUDIT.md). -->
        <plugin>
          <groupId>org.apache.maven.plugins</groupId>
          <artifactId>maven-compiler-plugin</artifactId>
          <version>3.14.0</version>
          <configuration>
            <release>25</release>
          </configuration>
        </plugin>
        <plugin>
          <groupId>org.apache.maven.plugins</groupId>
          <artifactId>maven-surefire-plugin</artifactId>
          <version>3.5.2</version>
        </plugin>
        <!-- Pinned because this project already hit the unpinned-plugin trap twice
             (compiler 3.1 failing the build, surefire 2.12.4 silently running zero
             tests). Measured before pinning: unpinned, `mvn deploy` resolved
             maven-deploy-plugin 2.7 and maven-install-plugin 2.4 — 2011-era
             super-POM defaults. `deploy` runs the full lifecycle through `install`,
             so both halves of the path need pinning, not just the last step. -->
        <plugin>
          <groupId>org.apache.maven.plugins</groupId>
          <artifactId>maven-deploy-plugin</artifactId>
          <version>3.1.4</version>
        </plugin>
        <plugin>
          <groupId>org.apache.maven.plugins</groupId>
          <artifactId>maven-install-plugin</artifactId>
          <version>3.1.4</version>
        </plugin>
        <plugin>
          <groupId>org.springframework.boot</groupId>
          <artifactId>spring-boot-maven-plugin</artifactId>
          <version>${spring-boot.version}</version>
          <!-- Without an explicit repackage binding, `mvn package` yields a plain
               ~4 KB jar, not a runnable Boot jar (also reproduced empirically). -->
          <executions>
            <execution>
              <goals>
                <goal>repackage</goal>
              </goals>
            </execution>
          </executions>
        </plugin>
      </plugins>
    </pluginManagement>
  </build>

  <!-- Forgejo's package registry. Three things must be exact:
       - <id> matches the <server><id> in ~/.m2/settings.xml, or Maven deploys
         anonymously and fails on 401.
       - /api/packages/ is the Maven wire protocol; /api/v1/packages/ is the
         management API and fails confusingly.
       - Org-level (database-detective), so all services share one namespace.

       <snapshotRepository> is deliberately ABSENT. CONVENTIONS §M.3 forbids
       SNAPSHOT dependencies on main; omitting the element makes a SNAPSHOT deploy
       fail loudly rather than quietly publish one. That is the convention
       enforcing itself. Do not "fix" this by adding it. -->
  <distributionManagement>
    <repository>
      <id>forgejo</id>
      <name>Forgejo Maven registry (database-detective)</name>
      <url>https://git.databasedetective.pro/api/packages/database-detective/maven</url>
    </repository>
  </distributionManagement>
</project>
