Description

<dependency>
    <groupId>io.seatlayer</groupId>
    <artifactId>seatlayer-java</artifactId>
    <version>0.2.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.seatlayer</groupId>
  <artifactId>seatlayer-java</artifactId>
  <version>0.2.0</version>
  <packaging>jar</packaging>

  <name>SeatLayer Java SDK</name>
  <description>Official Java server SDK for the SeatLayer reserved-seating API.</description>
  <url>https://docs.seatlayer.io/server-sdk/install/</url>

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

  <developers>
    <developer>
      <name>SeatLayer</name>
      <email>hello@seatlayer.io</email>
      <organization>SeatLayer</organization>
      <organizationUrl>https://seatlayer.io</organizationUrl>
    </developer>
  </developers>

  <scm>
    <connection>scm:git:https://github.com/seatlayer/seatlayer-java.git</connection>
    <developerConnection>scm:git:ssh://git@github.com/seatlayer/seatlayer-java.git</developerConnection>
    <url>https://github.com/seatlayer/seatlayer-java</url>
  </scm>

  <properties>
    <maven.compiler.release>17</maven.compiler.release>
    <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
    <project.reporting.outputEncoding>UTF-8</project.reporting.outputEncoding>
    <!-- Fixed timestamp makes the jars byte-for-byte reproducible, so a rebuild
         of a released tag can be diffed against what is on Central. -->
    <project.build.outputTimestamp>2026-08-04T00:00:00Z</project.build.outputTimestamp>
    <junit.version>5.11.4</junit.version>
  </properties>

  <!--
    No runtime dependencies on purpose. A server SDK that drags in Jackson,
    OkHttp and their transitive trees becomes a supply-chain surface for every
    customer, and forces version conflicts on anyone already using different
    ones. Java 17 ships java.net.http.HttpClient and javax.crypto.Mac; the only
    thing missing is a JSON codec, which is ~200 lines and has no opinions to
    conflict with.
  -->
  <dependencies>
    <dependency>
      <groupId>org.junit.jupiter</groupId>
      <artifactId>junit-jupiter</artifactId>
      <version>${junit.version}</version>
      <scope>test</scope>
    </dependency>
  </dependencies>

  <build>
    <!-- Ship the licence inside the jar, so the terms travel with the artifact
         rather than only with the GitHub repo. -->
    <resources>
      <resource>
        <directory>${project.basedir}</directory>
        <targetPath>META-INF</targetPath>
        <includes>
          <include>LICENSE</include>
        </includes>
      </resource>
    </resources>

    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-surefire-plugin</artifactId>
        <version>3.5.2</version>
      </plugin>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-source-plugin</artifactId>
        <version>3.3.1</version>
        <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>
        <version>3.11.2</version>
        <configuration>
          <!-- Central rejects a release whose javadoc does not build, and the
               doclint groups that are fatal have changed between JDK releases.
               Pin them: `all,-missing` keeps the checks that catch genuinely
               broken javadoc (malformed tags, bad @link targets, invalid HTML)
               and drops only "this member has no comment", which is a style
               opinion and must never fail a release build. CI runs 17 and 21;
               the publish may well happen on something newer. -->
          <doclint>all,-missing</doclint>
          <failOnError>true</failOnError>
          <quiet>true</quiet>
        </configuration>
        <executions>
          <execution>
            <id>attach-javadocs</id>
            <goals><goal>jar</goal></goals>
          </execution>
        </executions>
      </plugin>

      <!--
        The publish path. Sonatype's Central Portal is the only way in for a
        namespace registered today; the old OSSRH/nexus-staging route is closed
        to new projects. `extensions=true` makes this the deploy handler, so
        `mvn deploy` uploads a bundle here instead of looking for a
        distributionManagement repository.
      -->
      <plugin>
        <groupId>org.sonatype.central</groupId>
        <artifactId>central-publishing-maven-plugin</artifactId>
        <!-- 0.7.0 could not parse the Portal's response: Central's API grew a
             "warnings" field that the old model rejected outright, so an upload
             that SUCCEEDED still failed the build on deserialisation. -->
        <version>0.11.0</version>
        <extensions>true</extensions>
        <configuration>
          <!-- Must match a <server><id> in ~/.m2/settings.xml. -->
          <publishingServerId>central</publishingServerId>
          <!--
            Auto-publish: a tag push goes all the way to Central with no human
            step (owner decision, 2026-08-07).

            Know what this gives up. Central is the ONLY registry in this fleet
            where a published version can never be replaced or deleted — PyPI and
            RubyGems allow a yank, NuGet an unlist, Packagist republishes from
            tags. `false` used to hold the deployment in the Portal as the last
            moment a bad build could be dropped; that moment no longer exists.

            What stands in its place is the release workflow's gate: the full
            test suite, a tag-vs-<version> equality check, and GPG signing all
            run BEFORE the upload, and any failure means nothing is sent. Those
            checks are now the only thing between a tag and a permanent artifact,
            so treat them as load-bearing and do not weaken them.

            To go back: set this to false and publishing waits for a human at
            https://central.sonatype.com/publishing/deployments
          -->
          <autoPublish>true</autoPublish>
          <!--
            `published`, not `validated`. With autoPublish on, stopping at
            validated would let `mvn deploy` exit 0 while the publish is still in
            flight — a failure after that point would never reach the build log.
            Blocking until published means the workflow's result is the real
            outcome rather than a promise of one.
          -->
          <waitUntil>published</waitUntil>
        </configuration>
      </plugin>
    </plugins>
  </build>

  <profiles>
    <!--
      Signing lives in a profile so an ordinary `mvn verify` needs no GPG key.
      Central rejects any artifact without a detached .asc signature, so the
      release command must carry -Prelease; RELEASE.md spells that out and the
      pre-flight check there proves the .asc files exist before uploading.
    -->
    <profile>
      <id>release</id>
      <build>
        <plugins>
          <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-gpg-plugin</artifactId>
            <version>3.2.7</version>
            <executions>
              <execution>
                <id>sign-artifacts</id>
                <phase>verify</phase>
                <goals><goal>sign</goal></goals>
                <configuration>
                  <!-- Key and passphrase come from settings.xml properties or
                       the environment (MAVEN_GPG_KEY / MAVEN_GPG_PASSPHRASE),
                       never from this file. Loopback pinentry is what lets gpg
                       take the passphrase non-interactively on gpg 2.1+. -->
                  <gpgArguments>
                    <arg>--pinentry-mode</arg>
                    <arg>loopback</arg>
                  </gpgArguments>
                </configuration>
              </execution>
            </executions>
          </plugin>
        </plugins>
      </build>
    </profile>
  </profiles>
</project>