Description

<dependency>
    <groupId>ai.ctxmesh</groupId>
    <artifactId>ctxmesh</artifactId>
    <version>0.1.0-beta.8</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>ai.ctxmesh</groupId>
  <artifactId>ctxmesh</artifactId>
  <version>0.1.0-beta.8</version>
  <packaging>jar</packaging>

  <name>ctxmesh</name>
  <description>Java SDK for ctxmesh, the Kubernetes-native control plane for AI agents. Typed clients for memory, knowledge, skills, feedback, delegation and agent-to-agent calls. Reads its endpoints from the environment the platform injects, so your code never holds credentials. Source, docs and issues: https://github.com/ctxmesh/ctxmesh</description>
  <url>https://ctxmesh.github.io</url>

  <licenses>
    <license>
      <name>Apache License, Version 2.0</name>
      <url>https://www.apache.org/licenses/LICENSE-2.0.txt</url>
    </license>
  </licenses>

  <developers>
    <developer><name>ctxmesh</name><url>https://github.com/ctxmesh</url></developer>
  </developers>

  <scm>
    <connection>scm:git:https://github.com/ctxmesh/ctxmesh.git</connection>
    <url>https://github.com/ctxmesh/ctxmesh</url>
  </scm>

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

  <!-- No runtime dependencies, deliberately. The plane is JSON over localhost HTTP; java.net.http
       and a small hand-rolled JSON reader cover it. A Jackson dependency in an SDK is a version
       conflict in every application that already has one. -->
  <dependencies>
    <dependency>
      <groupId>org.junit.jupiter</groupId>
      <artifactId>junit-jupiter</artifactId>
      <version>5.11.3</version>
      <scope>test</scope>
    </dependency>
  </dependencies>

  <build>
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-surefire-plugin</artifactId>
        <version>3.5.2</version>
      </plugin>
    </plugins>
  </build>

  <!-- Publishing only. Central REJECTS a bundle without sources, javadoc and a GPG signature,
       and it rejects it after upload — so a release that skipped these would fail at the last
       step, with the images already published. Kept in a profile so a normal `mvn test` does
       not pay for javadoc or need a signing key. -->
  <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.11.2</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.7</version>
            <executions>
              <execution>
                <id>sign-artifacts</id>
                <phase>verify</phase>
                <goals><goal>sign</goal></goals>
                <configuration>
                  <!-- The key has no TTY in CI; the passphrase arrives as a property. -->
                  <gpgArguments>
                    <arg>--pinentry-mode</arg>
                    <arg>loopback</arg>
                  </gpgArguments>
                </configuration>
              </execution>
            </executions>
          </plugin>
          <plugin>
            <groupId>org.sonatype.central</groupId>
            <artifactId>central-publishing-maven-plugin</artifactId>
            <!-- 0.11.0, not 0.7.0. Central's API gained a `warnings` field that 0.7.0's response
                 model does not know and does not ignore, so it threw
                 UnrecognizedPropertyException while parsing a RESPONSE — after the upload
                 attempt, which is the worst place to discover a version skew. -->
            <version>0.11.0</version>
            <extensions>true</extensions>
            <configuration>
              <publishingServerId>central</publishingServerId>
              <!-- Upload and release in one step. A manual release step would leave a bundle
                   sitting in the portal after a green workflow, which reads as published. -->
              <autoPublish>true</autoPublish>
              <!-- validated, NOT published. `published` blocks until Central finishes releasing,
                   which is queue-depth dependent and not ours to predict: beta.4 took 14 minutes and
                   beta.5 was still waiting at 25, where the job timeout killed it — after the bundle
                   had uploaded fine. Waiting on someone else's queue makes the release a coin flip
                   and reports a successful upload as a failure.

                   `validated` still fails on everything that is our fault: a bad signature, a
                   missing javadoc or sources jar, a malformed POM. Publication then happens on
                   Central's own schedule, because autoPublish is true. That it actually LANDED is
                   asserted by the acceptance gate, which queries repo1 for the version — so a
                   bundle that validates and never publishes is caught, not assumed. -->
              <waitUntil>validated</waitUntil>
            </configuration>
          </plugin>
        </plugins>
      </build>
    </profile>
  </profiles>
</project>