<?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>com.assisi</groupId>
    <artifactId>assisi-service-parent</artifactId>
    <version>1.0.0</version>
    <relativePath/>
  </parent>

  <artifactId>assisi-outbox</artifactId>
  <version>1.0.1</version>
  <packaging>jar</packaging>

  <description>
    Transactional outbox MECHANISM for assisi services (CONVENTIONS §F, §I.6, §H.2).
    Ships the shared event envelope, a same-transaction write helper, a leader-elected
    publisher that marks rows published only after broker ack, per-key ordering, bounded
    retry with a DLQ, retention purge, and staleness detection.

    Ships NO event payload types and NO consumer abstraction — both are per-service
    concerns by design (see README "What this deliberately does not do").
  </description>

  <!-- Resolves the parent (and this artifact, for consumers) from the org-level Forgejo
       Maven registry. Verified in 01-06: this block in the POM being resolved IS
       sufficient for that POM's own parent, and the registry reads anonymously, so no
       credential and no settings.xml entry is required. -->
  <repositories>
    <repository>
      <id>forgejo</id>
      <url>https://git.databasedetective.pro/api/packages/database-detective/maven</url>
    </repository>
  </repositories>

  <properties>
    <!-- ShedLock is managed by NEITHER the Spring Boot 4.1.0 BOM nor Spring Cloud
         2025.1.2 (verified: zero occurrences in both), so its version must live here.
         6.6.0 is built against Spring Framework 6.2.6 while this project runs Spring
         Framework 7 — that mismatch was TESTED, not assumed: a probe on Boot 4.1.0
         started clean on SpringVersion 7.0.8 with @EnableSchedulerLock active and the
         @SchedulerLock-guarded method executing. See 02-01-AUDIT.md §5. -->
    <shedlock.version>6.6.0</shedlock.version>
  </properties>

  <dependencies>
    <!-- JDBC, not JPA. JdbcTemplate/JdbcClient join the caller's ambient transaction through
         DataSourceUtils, so §I.6 holds exactly — while the library contributes no entity scan and
         no repository scan, and so imposes no ORM choice on consumers. Using JPA required
         @EntityScan, which REPLACES the consuming app's entity scan; that was reproduced during
         apply as UnknownEntityTypeException on the host's own entity. -->
    <dependency>
      <groupId>org.springframework.boot</groupId>
      <artifactId>spring-boot-starter-jdbc</artifactId>
    </dependency>

    <!-- TEST-ONLY JPA: the test application is a JPA-using service, which is how the library
         proves it does not disturb a consumer's persistence unit. Not a runtime dependency. -->
    <dependency>
      <groupId>org.springframework.boot</groupId>
      <artifactId>spring-boot-starter-data-jpa</artifactId>
      <scope>test</scope>
    </dependency>

    <!-- Flyway. spring-boot-flyway is required SEPARATELY from flyway-core: Boot 4 split
         autoconfiguration into per-technology modules, and flyway-core alone does not
         provide FlywayAutoConfiguration (verified). The library needs it on the classpath
         to interoperate correctly with the consuming service's own Flyway. -->
    <dependency>
      <groupId>org.flywaydb</groupId>
      <artifactId>flyway-core</artifactId>
    </dependency>
    <dependency>
      <groupId>org.flywaydb</groupId>
      <artifactId>flyway-database-postgresql</artifactId>
    </dependency>
    <dependency>
      <groupId>org.springframework.boot</groupId>
      <artifactId>spring-boot-flyway</artifactId>
    </dependency>

    <!-- Jackson for envelope serialisation. Boot 4.1.0 manages **Jackson 3**
         (tools.jackson, jackson-bom 3.1.4); com.fasterxml.jackson is now the legacy path
         behind spring-boot-jackson2. spring-boot-starter-data-jpa does NOT bring Jackson,
         so the starter is required explicitly. -->
    <dependency>
      <groupId>org.springframework.boot</groupId>
      <artifactId>spring-boot-starter-jackson</artifactId>
    </dependency>

    <!-- Kafka producer for the publish side. spring-boot-kafka is needed alongside spring-kafka
         for the SAME reason spring-boot-flyway is needed alongside flyway-core: Boot 4 splits
         autoconfiguration into per-technology modules, and the plain library jar carries none of it.
         It is also where KafkaProperties lives, which is how the library inherits the service's
         bootstrap-servers and TLS settings instead of inventing its own. -->
    <dependency>
      <groupId>org.springframework.kafka</groupId>
      <artifactId>spring-kafka</artifactId>
    </dependency>
    <dependency>
      <groupId>org.springframework.boot</groupId>
      <artifactId>spring-boot-kafka</artifactId>
    </dependency>

    <!-- Leader election so exactly one instance drains the outbox (§H.2, §F.4). -->
    <dependency>
      <groupId>net.javacrumbs.shedlock</groupId>
      <artifactId>shedlock-spring</artifactId>
      <version>${shedlock.version}</version>
    </dependency>
    <dependency>
      <groupId>net.javacrumbs.shedlock</groupId>
      <artifactId>shedlock-provider-jdbc-template</artifactId>
      <version>${shedlock.version}</version>
    </dependency>

    <!-- Metrics. Optional at runtime: a service without a MeterRegistry still works, it
         just publishes no instruments (the autoconfiguration takes an ObjectProvider).
         Every failure mode of this library is invisible from the request path, so the
         instruments are what make the DLQ, staleness and purge observable at all. -->
    <dependency>
      <groupId>io.micrometer</groupId>
      <artifactId>micrometer-core</artifactId>
    </dependency>

    <!-- Postgres driver is the CONSUMING SERVICE's runtime concern; needed here only to
         run this library's own tests against a real database. -->
    <dependency>
      <groupId>org.postgresql</groupId>
      <artifactId>postgresql</artifactId>
      <scope>test</scope>
    </dependency>

    <dependency>
      <groupId>org.springframework.boot</groupId>
      <artifactId>spring-boot-starter-test</artifactId>
      <scope>test</scope>
    </dependency>
    <dependency>
      <groupId>com.tngtech.archunit</groupId>
      <artifactId>archunit-junit5</artifactId>
      <scope>test</scope>
    </dependency>

    <!-- Testcontainers 2.x RENAMED its modules: org.testcontainers:kafka and :postgresql
         do NOT exist at 2.0.5 (verified). The BOM manages testcontainers-kafka and
         testcontainers-postgresql, so both stay versionless here. -->
    <dependency>
      <groupId>org.testcontainers</groupId>
      <artifactId>testcontainers-postgresql</artifactId>
      <scope>test</scope>
    </dependency>
    <dependency>
      <groupId>org.testcontainers</groupId>
      <artifactId>testcontainers-kafka</artifactId>
      <scope>test</scope>
    </dependency>
    <dependency>
      <groupId>org.testcontainers</groupId>
      <artifactId>testcontainers-junit-jupiter</artifactId>
      <scope>test</scope>
    </dependency>
  </dependencies>

  <build>
    <plugins>
      <!-- Versions come from the parent's pluginManagement. spring-boot-maven-plugin is
           deliberately ABSENT: this is a library, and the parent binds `repackage` to that
           plugin. Declaring it would produce an executable Boot fat jar with nested
           BOOT-INF/ — the exact wrong artifact to publish for consumption, and the 19 MB
           mistake 01-06 excluded smoke-test for. -->
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-compiler-plugin</artifactId>
      </plugin>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-surefire-plugin</artifactId>
      </plugin>
    </plugins>
  </build>

  <!-- Same registry, same anonymous-read posture as the parent (01-06). Publishing needs a
       write:package token in ~/.m2/settings.xml under <server><id>forgejo</id>; resolving
       needs nothing.

       <snapshotRepository> deliberately ABSENT, exactly as in the parent: §M.3 forbids
       SNAPSHOT dependencies on main, and omitting the element makes a SNAPSHOT deploy fail
       loudly instead of quietly publishing one. 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>
