Micronaut platform pom file generates duplicate versions of some modules

[radovanradic]

Issue description

The pom file https://central.sonatype.com/artifact/io.micronaut.platform/micronaut-platform contains entries like this:

...
<micronaut.mongo.version>5.4.0</micronaut.mongo.version>
<micronaut.mongodb.version>5.4.0</micronaut.mongodb.version>
...
<micronaut.oracle.cloud.version>4.2.0</micronaut.oracle.cloud.version>
<micronaut.oraclecloud.version>4.2.0</micronaut.oraclecloud.version>
...
<micronaut.problem.json.version>3.5.0</micronaut.problem.json.version>
<micronaut.problem.version>3.5.0</micronaut.problem.version>
...

This can cause issues when importing micronaut boms since not sure which version will be used by the platform.

[alvarosanchez]

@melix could this be caused by the inlining of other BOMs?

[melix]

Yes, I think it's because of inlining. Ideally such situations shouldn't happen: either one module should be driving the version and the other module should use its catalog, or one module is using the same dependencies but shouldn't manage them. There are actually warnings during the platform generation, but we ignore them. However, it's probably a bug that there are duplicate dependencies, this should issue a warning and no duplication.

[nedelva]

I find Kafka deps particularly confusing:

      <dependency>
        <groupId>org.apache.kafka</groupId>
        <artifactId>kafka-streams</artifactId>
        <version>${kafka.version}</version>
      </dependency>
      <dependency>
        <groupId>io.micronaut.kafka</groupId>
        <artifactId>micronaut-kafka</artifactId>
        <version>${micronaut.kafka.version}</version>
      </dependency>
      <dependency>
        <groupId>org.apache.kafka</groupId>
        <artifactId>kafka-clients</artifactId>
        <version>${kafka.compat.version}</version>
      </dependency>
      <dependency>
        <groupId>org.apache.kafka</groupId>
        <artifactId>kafka-clients</artifactId>
        <version>${kafka.version}</version>
      </dependency>
      <dependency>
        <groupId>io.micronaut.kafka</groupId>
        <artifactId>micronaut-kafka-bom</artifactId>
        <version>${micronaut.kafka.version}</version>
      </dependency>
      <dependency>
        <groupId>io.micronaut.kafka</groupId>
        <artifactId>micronaut-kafka-streams</artifactId>
        <version>${micronaut.kafka.version}</version>
      </dependency>

where the properties are defined as

<kafka.compat.version>3.8.0</kafka.compat.version>
<kafka.version>3.7.0</kafka.version>
<micronaut.kafka.version>5.6.0</micronaut.kafka.version>

Here you can see that kafka-clients is mentioned twice, with different versions.

[graemerocher]

@melix how can we fix this?

[melix]

There are 2 different problems here. First, in micronaut-kafka, we define:

managed-kafka-compat = "3.7.0"
...
# Duplicated to keep catalog compatibility with 3.4.x.  Can be removed for 4.0.0
managed-kafka = { module = 'org.apache.kafka:kafka-clients', version.ref = 'managed-kafka-compat' }

Fun fact, Micronaut Kafka is already 5.x, so this should have been removed in micronaut-kafka long ago.

Second, this shows that it's possible for an inlined module to conflict with an upstream definition. Currently the BOM generator doesn't capture this, and there's, as far as I can see, no way to workaround. So the easiest for this particular Kafka issue is probably to remove the aliases in Micronaut Kafka, since they were deprecated (and probably document that in major releases we should review the module catalog for deprecation removals).

Then the next step would be to implement some mechanism to detect duplicates in the BOM generator. I have this on my todo list, not sure how complicated it is yet. If such a thing happens, we're not in a good situation though, since basically it means there are 2 properties which can be used to declare a version for a single module, one coming from us, the other from the upstream project, and who knows which takes precedence when order of imported BOMs change.