OTel dependency convergence issue #819
Comments
|
I haven't had a chance to look more closely but something is confusing here. We declare a dependency on version |
|
You're right. The However, I have made a minimal example and there are still discrepancies : <?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 https://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>com.example</groupId>
<artifactId>demo</artifactId>
<version>0.0.1-SNAPSHOT</version>
<name>demo</name>
<dependencies>
<dependency>
<groupId>io.micrometer</groupId>
<artifactId>micrometer-tracing-bridge-otel</artifactId>
<version>1.3.3</version>
</dependency>
</dependencies>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-enforcer-plugin</artifactId>
<version>3.5.0</version>
<executions>
<execution>
<id>pom-validation</id>
<goals>
<goal>enforce</goal>
</goals>
</execution>
</executions>
<configuration>
<rules>
<dependencyConvergence/>
</rules>
<fail>true</fail>
</configuration>
</plugin>
</plugins>
</build>
</project>yields Same problem with versions In the case of the |
|
Something is definitely weird and unexpected. We'll take a closer look. |
This wasn't true, at least not for all patch releases. Our 1.3.2 pom declares a dependency on opentelemetry-api 1.39.0 and our 1.3.3 declares a dependency on opentelemetry-api 1.40.0. That's unexpected - we intended for our build to manage the version to 1.38.0. Also, opentelemetry-instrumentation-api is bumping minor versions of opentelemetry-api in patch releases, which is unexpected from our end (although I don't know if it was intentional on the part of the maintainers of that artifact). |
|
A few notes:
because
But as Tommy mentioned above, patch version bumps of
A single BOM and following the same version strategy would be nice from OTel, until then I think we can use |
It seems opentelemetry-bom-alpha contains opentelemetry-bom so we don't need to depend on the latter. Since opentelemetry-instrumentation-api-semconv and io.opentelemetry:opentelemetry-bom-alpha can point to conflicting versions, we should use another BOM: opentelemetry-instrumentation-bom-alpha which contains opentelemetry-bom-alpha. This BOM has an issue though, its patch version upgrades contain minor version upgrades for opentelemetry-bom-alpha, see: 1.33.0 -> 1.35.0: https://repo1.maven.org/maven2/io/opentelemetry/instrumentation/opentelemetry-instrumentation-bom-alpha/1.33.0-alpha/opentelemetry-instrumentation-bom-alpha-1.33.0-alpha.pom 1.33.1 -> 1.36.0: https://repo1.maven.org/maven2/io/opentelemetry/instrumentation/opentelemetry-instrumentation-bom-alpha/1.33.1-alpha/opentelemetry-instrumentation-bom-alpha-1.33.1-alpha.pom 1.33.2 -> 1.37.0: https://repo1.maven.org/maven2/io/opentelemetry/instrumentation/opentelemetry-instrumentation-bom-alpha/1.33.2-alpha/opentelemetry-instrumentation-bom-alpha-1.33.2-alpha.pom 1.33.3 -> 1.38.0: https://repo1.maven.org/maven2/io/opentelemetry/instrumentation/opentelemetry-instrumentation-bom-alpha/1.33.3-alpha/opentelemetry-instrumentation-bom-alpha-1.33.3-alpha.pom 1.33.4 -> 1.39.0: https://repo1.maven.org/maven2/io/opentelemetry/instrumentation/opentelemetry-instrumentation-bom-alpha/1.33.4-alpha/opentelemetry-instrumentation-bom-alpha-1.33.4-alpha.pom 1.33.5 -> 1.40.0: https://repo1.maven.org/maven2/io/opentelemetry/instrumentation/opentelemetry-instrumentation-bom-alpha/1.33.5-alpha/opentelemetry-instrumentation-bom-alpha-1.33.5-alpha.pom Closes gh-819
|
fyi: #823 |
jonatan-ivanov
changed the title
shakuzen
added
the
release notes
|
We should make sure to call out in the release notes that the opentelemetry version has been effectively downgraded to 1.31.0 in this patch version to match our dependency version policy and what it was in our 1.2.0 release. |
|
@jonatan-ivanov my sample project above builds when using the latest 1.3.4-SNAPSHOT (it does not when using 1.3.3) so that's okay. The dependency tree is that in that case is as follows : So thank you for that! However, when I try to use the latest 1.2.10-SNAPSHOT (which I personally don't need, I was just curious), I still get convergence issues : The culprit seems to be |
|
Thanks for checking! I'm afraid that's an issue we cannot fix on Micrometer side, it seems OTel conflicts within its own versions, here are the details with link to the poms: Micrometer depends on
But then, as you pointed out, Micrometer has no control over this, but build tools should be able to overcome this issue by resolving I will inform OTel devs about this problem, please feel free to open an issue in opentelemetry-java. |
Since version
1.3.1, there is a dependency convergence error when trying to use theio.micrometer:micrometer-tracing-bridge-oteldependency :io.opentelemetry:opentelemetry-api-incubatoris present both in1.37-0-alphaand1.38.0-alphathrough different dependency paths.It seems the problem appeared since version
1.3.1as I do not reproduce it when using version1.3.0.It is still present on the latest
1.3.3version.For projects using enforcer plugins, this is inconvenient as it forces to downgrade the version of the dependency (which is, in my case, managed by Spring Boot), or to exclude/include one of the transitive dependency. Unfortunately, neither option is ideal.
The solution would be either :
1.33.2-alphaversion ofopentelemetry-instrumentation-api-semconvdependency instead of1.33.3-alpha, so thatio.opentelemetry:opentelemetry-api-incubatorare in both cases in1.37.0-alpha1.38.0version ofopentelemetry-sdkdependency instead of1.37.0so thatio.opentelemetry:opentelemetry-api-incubatorare in both cases in1.38.0-alphaAlso, it might be a good idea to introduce such enforcer plugin on the project so that it doesn't happen again in the future.
The text was updated successfully, but these errors were encountered: