Introduce a BOM (Bill of Materials) for SmallRye GraphQL

[velo]

Motivation

Currently, users who depend on multiple SmallRye GraphQL artifacts must explicitly specify the version for each dependency, as shown in the example below:

<dependency>
  <groupId>io.smallrye</groupId>
  <artifactId>smallrye-graphql-api</artifactId>
  <version>${smallrye-graphql.version}</version>
</dependency>
<dependency>
  <groupId>io.smallrye</groupId>
  <artifactId>smallrye-graphql-cdi</artifactId>
  <version>${smallrye-graphql.version}</version>
</dependency>
...

This approach introduces unnecessary complexity, especially when integrating SmallRye GraphQL via frameworks like Quarkus. If a user needs to override the SmallRye GraphQL version, they must do so for each individual artifact.
Solution

I have a list of 11 dependencies to make sure a override it all from quarkus graphql client.

This PR introduces a Bill of Materials (BOM) for SmallRye GraphQL, allowing users to manage all SmallRye GraphQL dependencies with a single import:

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

With this change, users can:

• add SmallRye GraphQL dependencies without explicitly specifying versions:

<dependency>
  <groupId>io.smallrye</groupId>
  <artifactId>smallrye-graphql-client</artifactId>
</dependency>

• override smallrye-graphql version with a single entry on dependencyManagement

This simplifies version management and improves maintainability, making it easier to update SmallRye GraphQL across projects.

Impact

Reduces the number of explicit version declarations needed in projects using SmallRye GraphQL.
Simplifies dependency management for Quarkus users relying on quarkus-smallrye-graphql-client.
Improves maintainability by centralizing version management in a BOM.

Let me know if you need any adjustments! 🚀

[jmartisk]

Thanks, I think this is an awesome idea that we should have implemented earlier. I'm just worried a bit about the impact on the release automation, but hopefully it won't be much of a trouble (we won't know until we actually perform a release though)

[jmartisk]

Please extract this to a property, like all other dependency versions

[jmartisk]

We should exclude test-related modules (smallrye-graphql-integration-tests, smallrye-graphql-client-generator-test, smallrye-graphql-maven-plugin-tests, smallrye-graphql-tck, smallrye-graphql-client-tck) and also smallrye-graphql-documentation, so maybe it would be better to explicitly list the modules to include (without a wildcard)

[jmartisk]

Looking at this, I've also noticed that after moving to the new release process, our test-related modules have started being published too (see for example https://repo1.maven.org/maven2/io/smallrye/smallrye-graphql-integration-tests/2.12.1/) - CC @radcortez and @gastaldi - how do I avoid that? The modules set skipNexusStagingDeployMojo=true which doesn't seem to work anymore

[gastaldi]

@jmartisk you just put the modules in a profile and disable them during the release.
See https://github.com/quarkiverse/quarkus-ironjacamar/blob/main/pom.xml#L79-L90

[jmartisk]

Thanks @gastaldi, I've created #2272 for that