Description

<dependency>
    <groupId>dev.batchwatch</groupId>
    <artifactId>batchwatch-client</artifactId>
    <version>0.2.2</version>
</dependency>

<?xml version="1.0" encoding="UTF-8"?>
<!--
  Maven build file for a real-world install, WHEN the client is one day
  published. It is NOT required to compile or test: the suite runs on the bare
  JDK with

      javac -d out $(find . -name '*.java')
      java -cp out dev.batchwatch.tests.RunAll

  No dependencies - neither for runtime nor test. HTTP is java.net.http, JSON is
  a small hand-rolled writer/reader, and the test runner is our own.

  PUBLISHING (#163). A plain `mvn verify` builds jar + -sources + -javadoc on the
  bare JDK with NO signing key required. Signing and the Central Portal upload
  live behind the `release` profile (`mvn -Prelease deploy`), which the
  `java` job in .github/workflows/publish.yml activates on a tag. GPG signing and
  the central-publishing-maven-plugin are therefore inert for a normal build.
-->
<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>dev.batchwatch</groupId>
    <artifactId>batchwatch-client</artifactId>
    <version>0.2.2</version>
    <packaging>jar</packaging>

    <name>batchwatch Java client</name>
    <description>Crowdsourced measurement of queue time on LLM batch APIs. No dependencies.</description>
    <url>https://batchwatch.dev</url>

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

    <developers>
        <developer>
            <id>batchwatch</id>
            <name>batchwatch</name>
            <organization>batchwatch</organization>
            <organizationUrl>https://batchwatch.dev</organizationUrl>
        </developer>
    </developers>

    <scm>
        <connection>scm:git:https://github.com/batchwatch/client.git</connection>
        <developerConnection>scm:git:git@github.com:batchwatch/client.git</developerConnection>
        <url>https://github.com/batchwatch/client</url>
    </scm>

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

    <!-- No <dependencies>: the client runs on the bare JDK. -->

    <build>
        <sourceDirectory>src/main/java</sourceDirectory>
        <testSourceDirectory>src/test/java</testSourceDirectory>
        <plugins>
            <!-- Pin the compiler plugin: the Maven-default (3.1) predates the
                 `maven.compiler.release` property and falls back to source/target 5,
                 which no JDK 17 accepts. -->
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-compiler-plugin</artifactId>
                <version>3.13.0</version>
            </plugin>

            <!-- Central requires a -sources.jar in every published bundle. -->
            <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>

            <!-- Central requires a -javadoc.jar in every published bundle. -->
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-javadoc-plugin</artifactId>
                <version>3.7.0</version>
                <executions>
                    <execution>
                        <id>attach-javadocs</id>
                        <goals>
                            <goal>jar</goal>
                        </goals>
                    </execution>
                </executions>
                <configuration>
                    <!-- The hand-rolled client has sparse Javadoc; don't fail the
                         build on missing @param/@return etc. under JDK's doclint. -->
                    <doclint>none</doclint>
                    <quiet>true</quiet>
                </configuration>
            </plugin>
        </plugins>
    </build>

    <profiles>
        <!-- release: signs every artifact and uploads the bundle to the Central
             Portal. Activated only by `mvn -Prelease deploy` (the publish workflow),
             so a plain `mvn verify` needs no GPG key and never contacts Central. -->
        <profile>
            <id>release</id>
            <build>
                <plugins>
                    <!-- Sign the jar, -sources, -javadoc and the POM. Central rejects
                         any unsigned artifact. In CI there is no interactive agent, so
                         the passphrase is read from the MAVEN_GPG_PASSPHRASE environment
                         variable (the plugin's passphraseEnvName default, since 3.2.0)
                         and handed to gpg via loopback pinentry; it is NEVER placed on
                         the mvn command line, because the gpg.passphrase property is
                         deprecated and warned about since 3.2.0 and would leak the
                         secret into the process table. The batch gpg argument keeps gpg
                         fully non-interactive. No key name is configured: the runner
                         keyring holds exactly one secret key, so gpg's default key is
                         unambiguous. -->
                    <plugin>
                        <groupId>org.apache.maven.plugins</groupId>
                        <artifactId>maven-gpg-plugin</artifactId>
                        <version>3.2.4</version>
                        <executions>
                            <execution>
                                <id>sign-artifacts</id>
                                <phase>verify</phase>
                                <goals>
                                    <goal>sign</goal>
                                </goals>
                                <configuration>
                                    <gpgArguments>
                                        <arg>--pinentry-mode</arg>
                                        <arg>loopback</arg>
                                        <arg>--batch</arg>
                                    </gpgArguments>
                                </configuration>
                            </execution>
                        </executions>
                    </plugin>

                    <!-- Sonatype Central Portal publisher. Reads the `central` server
                         creds (username=CENTRAL_USERNAME, password=CENTRAL_TOKEN) from
                         the settings.xml the CI job writes. autoPublish=true releases
                         the deployment automatically once Central's validation passes;
                         set it false to leave the deployment for manual release in the
                         Central Portal UI. -->
                    <plugin>
                        <groupId>org.sonatype.central</groupId>
                        <artifactId>central-publishing-maven-plugin</artifactId>
                        <version>0.5.0</version>
                        <extensions>true</extensions>
                        <configuration>
                            <publishingServerId>central</publishingServerId>
                            <autoPublish>true</autoPublish>
                            <!-- Wait only until the signed bundle is UPLOADED, not until
                                 Central reports it published. Plugin 0.5.0 can't parse the
                                 `warnings` field Central now returns in the published-poll
                                 status response (UnrecognizedPropertyException), so waiting
                                 for `published` fails the job even though autoPublish still
                                 releases the deployment automatically and asynchronously.
                                 `uploaded` greens the job the moment the bundle is up. -->
                            <waitUntil>uploaded</waitUntil>
                        </configuration>
                    </plugin>
                </plugins>
            </build>
        </profile>
    </profiles>
</project>