[NopeCharon]

What

Adds a java-spiffe-bom module, a Bill of Materials published to Maven Central next to the other artifacts. It manages the version of every java-spiffe module: java-spiffe-core, java-spiffe-provider, java-spiffe-helper, grpc-netty-linux, grpc-netty-macos and grpc-netty-macos-aarch64.

Maven:

<dependencyManagement>
  <dependencies>
    <dependency>
      <groupId>io.spiffe</groupId>
      <artifactId>java-spiffe-bom</artifactId>
      <version>${java-spiffe.version}</version>
      <type>pom</type>
      <scope>import</scope>
    </dependency>
  </dependencies>
</dependencyManagement>

Gradle:

implementation platform('io.spiffe:java-spiffe-bom:<version>')
implementation 'io.spiffe:java-spiffe-provider'
runtimeOnly 'io.spiffe:grpc-netty-macos-aarch64'

• java-spiffe-bom/build.gradle applies java-platform and adds a constraint for every other subproject, so a module added later is covered without editing the BOM.
• The root subprojects block is split. Group, version, the shared ext versions and the Maven Central publishing and signing configuration still apply to every subproject, including the BOM. java-library, jacoco and the Java conventions now apply to libraryProjects, all subprojects except the BOM, because java-platform can't be combined with java-library. The aggregate jacocoTestReport iterates libraryProjects too, since the BOM has no test task or source sets.
• README gets a "Bill of Materials (BOM)" section and the changelog an Added entry. The README snippets use the same version as the rest of the README, so they get bumped with the release like the others.

Refs #106. It covers the last part of that issue, a BOM for the java-spiffe modules themselves. Using the gRPC and Netty BOMs inside the build is a separate change.

Why

Users currently have to keep up to six io.spiffe versions in sync by hand. That's easy to get wrong for the platform-specific grpc-netty-* runtime modules: they are added separately from java-spiffe-core (often conditionally, per OS) and have to match its version, because they provide the io.spiffe.workloadapi.internal classes that core loads. With the BOM, they declare one version and the build keeps everything aligned.

Compatibility: this only adds an artifact. The generated pom-default.xml and module.json of all existing modules are byte-identical to the ones main generates. The BOM is published as a signed pom-packaged artifact with a dependencyManagement section, plus Gradle Module Metadata with the platform category. japicmp covers only core and provider and isn't affected.

How tested

• Generated the publications on main and on this branch and diffed them. The existing modules are identical, and the BOM's POM and module metadata list all six modules at the project version.
• Published to a scratch local Maven repository with a throwaway signing key, then resolved a separate consumer project that uses platform('io.spiffe:java-spiffe-bom:0.8.17'), java-spiffe-provider and grpc-netty-macos-aarch64 with no versions. Every io.spiffe module resolved to 0.8.17.
• ./gradlew clean build and ./gradlew test jacocoTestReport (the coverage workflow) on JDK 17.