Ecosystem follow-up work

[pboothe]

The library builds, CI is green on Java 17, 21, and 25, and Maven Central publishing is configured but has never run. Nothing is tagged and com.triplepat has no namespace on Central as of 2026-09-04. This issue collects the work that puts it into the Java ecosystem. All publishing waits for go-syntheticalert to prove out in production.

Publishing (plan Task 9)

• Claim the com.triplepat namespace on central.sonatype.com, verified with a DNS TXT record on triplepat.com.
• Generate a GPG key for release signing and publish it to a keyserver. PGP is still required by Central; Sigstore bundles are validated but optional.
• Add the four secrets the vanniktech plugin reads: ORG_GRADLE_PROJECT_mavenCentralUsername, ORG_GRADLE_PROJECT_mavenCentralPassword (a Portal user token), ORG_GRADLE_PROJECT_signingInMemoryKey, ORG_GRADLE_PROJECT_signingInMemoryKeyPassword.
• Add a release workflow triggered by a v* tag: ./gradlew publishAndReleaseToMavenCentral, GitHub Release with notes drafted for founder review first. Notes describe the module for a first-time reader.
• Re-check whether Central offers OIDC trusted publishing for Gradle by then; as of 2026-09-04 it does not and there is no official Sonatype Gradle plugin.
• First tag only after the API settles.
• Verify the published artifact resolves from a clean Gradle and a clean Maven project, on the module path and the classpath.
• Add the Maven Central version badge and the javadoc.io badge to the README.

Consumers

• Verify the Micrometer wiring in a real Spring Boot application, registered from a @Bean method, and confirm strongReference(true) keeps the gauge alive across garbage collections there too.
• Add a Kotlin consumer check (a small Kotlin test or sample) that proves @NullMarked makes the Duration parameters non-null types rather than platform types.
• Decide whether a Spring Boot autoconfiguration module is worth having, or whether the three-line README snippet is the right amount of integration. Default: the snippet.

Toolchain

• Error Prone and google-java-format both need a Java 21+ runtime, so the Java 17 CI leg compiles without the lint. Re-check each Error Prone release; if a version regains 17 support or the floor moves to 21, simplify the build.
• Revisit the Error Prone disable list (AddNullMarkedToClass, CanIgnoreReturnValueSuggester, Var, Varifier, Java8ApiChecker) each Error Prone release.
• Consider a Gradle toolchain with the Foojay resolver so local builds do not depend on JAVA_HOME; the runtime check in build.gradle.kts must move with it.

Discoverability

• Submit to the OpenTelemetry Registry as an instrumentation library.
• Ask for a listing on the Prometheus "Exporters and integrations" page, or decide it does not fit.

Housekeeping

• Dependabot or Renovate for the version catalog and GitHub Actions versions.