[
https://issues.apache.org/jira/browse/RATIS-2553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18088660#comment-18088660
]
Tak-Lon (Stephen) Wu commented on RATIS-2553:
---------------------------------------------
Thanks @szetszwo and [~haonan]works on it.
> Make OpenTelemetry dependencies optional/non-transitive for Ratis core modules
> ------------------------------------------------------------------------------
>
> Key: RATIS-2553
> URL: https://issues.apache.org/jira/browse/RATIS-2553
> Project: Ratis
> Issue Type: Sub-task
> Components: trace
> Affects Versions: 3.3.0
> Reporter: Haonan Hou
> Assignee: Haonan Hou
> Priority: Major
> Fix For: 3.3.0
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> After RATIS-2393 / apache/ratis#1341 and follow-up tracing changes, Ratis
> core modules pull OpenTelemetry artifacts into downstream projects through
> ratis-common.
> For downstream projects such as Apache IoTDB, the expectation is that
> depending on Ratis should not bring any OpenTelemetry artifacts by default,
> including:
> - io.opentelemetry:opentelemetry-api
> - io.opentelemetry:opentelemetry-context
> - io.opentelemetry:opentelemetry-common
> - io.opentelemetry:opentelemetry-sdk*
> - io.opentelemetry.semconv:opentelemetry-semconv
> Current behavior:
> ratis-common declares OpenTelemetry dependencies as compile dependencies.
> Since ratis-client, ratis-server, ratis-grpc, ratis-netty, and other modules
> depend on ratis-common, downstream applications receive OpenTelemetry
> dependencies transitively even when tracing is disabled.
> Expected behavior:
> Ratis tracing should be opt-in. Core Ratis artifacts should not expose
> OpenTelemetry dependencies transitively to downstream applications unless the
> downstream application explicitly enables/adds OpenTelemetry support.
> Notes:
> Simply moving SDK dependencies to test scope only partially helps. The
> remaining OpenTelemetry API/context dependencies are still exposed from
> ratis-common, and IoTDB wants to avoid those as well.
> Possible implementation directions:
> - Mark OpenTelemetry dependencies as optional and verify Ratis works without
> them when tracing is disabled.
> - Avoid eager class loading of OpenTelemetry classes on default paths.
> - Consider isolating OpenTelemetry implementation behind a small optional
> integration layer, service provider, or reflection/lazy-loaded adapter.
> - Keep protocol-level SpanContextProto propagation independent from
> OpenTelemetry Java libraries.
> Validation target:
> A downstream dependency tree on Ratis modules should not include any
> io.opentelemetry artifacts by default.
> Tracing-related tests should continue to pass when OpenTelemetry test/runtime
> dependencies are explicitly present in Ratis tests.
> Related:
> - RATIS-2393
> - https://github.com/apache/ratis/pull/1341
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
