pom.xml

<?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>com.getmcpulse</groupId>
  <artifactId>mcpulse</artifactId>
  <version>0.1.0</version>
  <packaging>jar</packaging>

  <name>mcpulse</name>
  <description>Analytics for MCP servers. One import, one wrap.</description>
  <url>https://getmcpulse.com</url>

  <licenses>
    <license>
      <name>MIT</name>
      <distribution>repo</distribution>
    </license>
  </licenses>

  <!--
    Maven Central rejects a release without these two. Developer email is
    optional and deliberately left out — it is published verbatim in the pom and
    scraped from there.
  -->
  <developers>
    <developer>
      <id>mcpulse</id>
      <name>MCPulse</name>
      <url>https://github.com/getmcpulse</url>
    </developer>
  </developers>

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

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

  <dependencies>
    <!--
      Provided, not compile: the customer already has the MCP SDK, and pinning a
      version inside their application is exactly the conflict this library must
      not cause. There are no other dependencies at all — the JSON reader, the
      HTTP client and the canonicaliser are all deliberately owned here.
    -->
    <dependency>
      <groupId>io.modelcontextprotocol.sdk</groupId>
      <artifactId>mcp-core</artifactId>
      <version>${mcp.version}</version>
      <scope>provided</scope>
    </dependency>

    <!--
      Test scope only, and only to read the conformance fixtures. The library
      itself owns its JSON reading — see Json.java — precisely so that nothing
      it brings can collide with the Jackson a customer's application has
      already settled on.
    -->
    <dependency>
      <groupId>com.fasterxml.jackson.core</groupId>
      <artifactId>jackson-databind</artifactId>
      <version>2.18.2</version>
      <scope>test</scope>
    </dependency>
  </dependencies>
  <!--
    What Maven Central requires beyond an ordinary jar, and why each is here.

    Sources and javadoc jars are mandatory: the repository is read by people
    and by IDEs, and a jar with neither cannot be stepped into or hovered over.
    Signatures are mandatory too — Central will not accept an unsigned artifact,
    which is what makes the GPG key part of the release rather than optional.

    `central-publishing-maven-plugin` replaces the old `nexus-staging` flow.
    `autoPublish` is false on purpose: the upload lands in a staging area and
    has to be released deliberately, so a bad build is a deleted deployment
    rather than a version that exists on Central forever.
  -->
  <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>
        <configuration>
          <!--
            The MCP SDK is a `provided` dependency, so javadoc resolves it and
            links out to types it does not own. `none` keeps a missing external
            link from failing a release; `doclint` off keeps a malformed tag in
            a comment from doing the same. Neither is worth a blocked publish.
          -->
          <detectJavaApiLink>false</detectJavaApiLink>
          <doclint>none</doclint>
          <quiet>true</quiet>
        </configuration>
      </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>
              <!-- No TTY in a script, so the passphrase comes from settings.xml. -->
              <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>
        <version>0.11.0</version>
        <extensions>true</extensions>
        <configuration>
          <!-- Matches the <server><id> in ~/.m2/settings.xml. -->
          <publishingServerId>central</publishingServerId>
          <autoPublish>false</autoPublish>
          <waitUntil>validated</waitUntil>
        </configuration>
      </plugin>
    </plugins>
  </build>

</project>