Description

<dependency>
    <groupId>com.envpit</groupId>
    <artifactId>envpit-sdk</artifactId>
    <version>0.1.0</version>
</dependency>

<?xml version="1.0" encoding="UTF-8"?>
<!--
  envpit-sdk (Java) — Phase 1 SDK, bd:envpit-0t2z.3 (last of the 3 new languages, follows
  Node/Python/Go). Java 17, ZERO runtime dependencies — java.net.http.HttpClient + a hand-rolled
  internal JSON parser (Sara SPEC-envpit-0t2z-3-1a-architecture.md §2.3, ADR-S3-02/ADR-S3-05).
  JUnit 5 is a TEST-scope-only dependency (does not ship with the published artifact) — matches
  Python's pytest / Node's vitest being dev-only; Go's stdlib `testing` needed no such dependency
  at all, the one place Java's ecosystem forces a test-only exception to the zero-dep posture.
-->
<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.envpit</groupId>
  <artifactId>envpit-sdk</artifactId>
  <version>0.1.0</version>
  <packaging>jar</packaging>

  <name>envpit-sdk</name>
  <description>EnvPit configuration management SDK for Java — zero runtime dependencies.</description>
  <url>https://github.com/ShoDeBiz/envpit-community</url>

  <!--
    The three blocks below (licenses / developers / scm) are REQUIRED by Maven Central and are
    rejected at validation time if absent — they are not documentation. Central also requires
    signed artifacts plus -sources and -javadoc jars; those come from the `release` profile at
    the bottom of this file. Namespace `com.envpit` is verified via a DNS TXT record on
    envpit.com (Sonatype Central Portal, 2026-07-29).
  -->
  <licenses>
    <license>
      <name>MIT License</name>
      <url>https://opensource.org/licenses/MIT</url>
      <distribution>repo</distribution>
    </license>
  </licenses>

  <developers>
    <developer>
      <id>shodebiz</id>
      <name>ShoDe</name>
      <url>https://github.com/ShoDeBiz</url>
    </developer>
  </developers>

  <scm>
    <connection>scm:git:https://github.com/ShoDeBiz/envpit-community.git</connection>
    <developerConnection>scm:git:git@github.com:ShoDeBiz/envpit-community.git</developerConnection>
    <url>https://github.com/ShoDeBiz/envpit-community</url>
    <tag>HEAD</tag>
  </scm>

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

  <dependencies>
    <!-- TEST-scope only — never shipped with the published artifact (mvn dependency:tree on the
         compile/runtime scope must show zero entries; verified by security_gates_test.go's
         analogue, ZeroRuntimeDependenciesTest). -->
    <dependency>
      <groupId>org.junit.jupiter</groupId>
      <artifactId>junit-jupiter</artifactId>
      <version>${junit.version}</version>
      <scope>test</scope>
    </dependency>
  </dependencies>

  <build>
    <!-- Ship the licence text inside the jar, not just as pom metadata. Maven Central only
         validates the <licenses> block above, but a consumer who has the jar and not the pom
         (vendored, shaded, or pulled out of a lockfile cache) would otherwise have no licence
         at all — and code with no licence is all-rights-reserved by default. -->
    <resources>
      <resource>
        <directory>${project.basedir}</directory>
        <includes><include>LICENSE</include></includes>
        <targetPath>META-INF</targetPath>
      </resource>
    </resources>

    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-compiler-plugin</artifactId>
        <version>3.13.0</version>
        <configuration>
          <release>17</release>
          <compilerArgs>
            <arg>-Xlint:all,-serial</arg>
          </compilerArgs>
        </configuration>
      </plugin>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-surefire-plugin</artifactId>
        <version>3.2.5</version>
        <configuration>
          <!-- Some conformance/leak tests spin real background threads and sockets; keep them
               serialized within this module (fine — the suite runs in a few seconds). -->
          <parallel>none</parallel>
        </configuration>
      </plugin>
    </plugins>
  </build>

  <!--
    Release-only, so an ordinary `mvn test` stays fast and needs no GPG key. Everything Maven
    Central demands beyond the metadata above lives here:
      - sources + javadoc jars (rejected without them)
      - a detached PGP signature per artifact
      - the Central Portal upload endpoint
    Run with `mvn -Prelease deploy`. `central-publishing-maven-plugin` authenticates against the
    `<server><id>central</id>` entry in ~/.m2/settings.xml (a Central Portal USER TOKEN — not the
    portal login), which is why publishingServerId below must match that id exactly.
  -->
  <profiles>
    <profile>
      <id>release</id>
      <build>
        <plugins>
          <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.6.3</version>
            <executions>
              <execution>
                <id>attach-javadocs</id>
                <goals><goal>jar</goal></goals>
              </execution>
            </executions>
          </plugin>
          <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>
                <!-- No gpgArguments on purpose. Forcing gpg's loopback pinentry mode here would
                     make gpg ask the CALLER for the passphrase instead of gpg-agent, which breaks
                     the local flow: the agent's own pinentry (pinentry-mac, configured in
                     ~/.gnupg/gpg-agent.conf) is exactly what should prompt, so the passphrase is
                     typed into a native dialog and never reaches a command line, a script or a
                     build log. For unattended CI, add loopback mode plus MAVEN_GPG_PASSPHRASE as
                     a secret there; it is a CI concern, not something to hardcode into every
                     local release. -->
              </execution>
            </executions>
          </plugin>
          <plugin>
            <groupId>org.sonatype.central</groupId>
            <artifactId>central-publishing-maven-plugin</artifactId>
            <version>0.5.0</version>
            <extensions>true</extensions>
            <configuration>
              <publishingServerId>central</publishingServerId>
              <!-- Upload and validate, but DO NOT release to the public index automatically.
                   A Central release is PERMANENT — a published version can never be deleted or
                   overwritten. Leaving this false means the deployment lands in the portal for a
                   human to inspect and press Publish, which is the right amount of friction for
                   an irreversible action. -->
              <autoPublish>false</autoPublish>
            </configuration>
          </plugin>
        </plugins>
      </build>
    </profile>
  </profiles>
</project>