opentelemetry-exporter-logging-otlp has compileOnly scoped dependencies

[steffan-westcott]

Describe the bug

I have a Clojure project which consumes opentelemetry-exporter-logging-otlp. The documentation tool (cljdoc) in my build chain fails due to missing dependencies. Also, browsing opentelemetry-exporter-logging-otlp classes in IntelliJ shows unresolved classes due to missing dependencies.

Inspection of the source shows that opentelemetry-exporter-logging-otlp has compileOnly rather than implementation scoped dependencies on opentelemetry-sdk-trace, opentelemetry-sdk-metrics and opentelemetry-sdk-logs. I am unsure if this is a bug in OpenTelemetry or that I need to add these 3 extra dependencies to my project that consumes opentelemetry-exporter-logging-otlp. It seems wrong to be adding dependencies to SDK components in order to use an exporter.

For your information, cljdoc is a Clojure community tool that generates and hosts Clojure library documentation. cljdoc performs analysis on the target library and its dependencies as a verification step before generating documentation.

Steps to reproduce

The (very small) Clojure project which consumes opentelemetry-exporter-logging-otlp is here

What did you expect to see?
I would expect to see no errors due to missing classes. Concretely:

• No warnings in IntelliJ about missing classes (e.g. LogExporter, MetricExporter, SpanExporter ) when viewing source classes in opentelemetry-exporter-logging-otlp.
• cljdoc should complete its analysis without errors due to missing dependencies.

What did you see instead?

Browsing classes OtlpJsonLoggingLogExporter, OtlpJsonLoggingMetricExporter and OtlpJsonLoggingSpanExporter in an IntelliJ project which consumes opentelemetry-exporter-logging-otlp, references to LogExporter, MetricExporter and SpanExporter respectively cannot be resolved, due to missing dependencies.

Triggering a documentation build by cljdoc produces an analysis failure as seen here The relevant part of the exception trace is this:

"Execution error (ClassNotFoundException) at jdk.internal.loader.BuiltinClassLoader/loadClass
(BuiltinClassLoader.java:581).\nio.opentelemetry.sdk.metrics.export.MetricExporter\n",

What version and what artifacts are you using?
Artifacts: opentelemetry-exporter-logging-otlp
Version: 1.12.0
How did you reference these artifacts? (excerpt from your build.gradle, pom.xml, etc)
The entire dependencies file for the Clojure project is very small:

{:paths ["src"]
 :deps  {org.clojure/clojure {:mvn/version "1.10.3"}
         io.opentelemetry/opentelemetry-exporter-logging-otlp {:mvn/version "1.12.0"}}}

Environment
Compiler: openjdk version "17.0.2" 2022-01-18
OS: "Ubuntu 20.04" (WSL 2)

[steffan-westcott]

A related question that may bring some clarity:
Who is the target audience for opentelemetry-exporter-logging-otlp?

If the target audience is SDK developers only (for the purpose of debugging the SDK), then this would indicate I should not be using this artifact at all. My umbrella project clj-otel targets Clojure library and application developers wishing to add telemetry using a Clojure API.

[jkwatson]

I suspect this was done to allow people to only depend on the signals that they actually care about. Especially, since the logs and metrics SDKs are not yet declared stable, we can't have api dependencies on them yet. We could make the dependency on the tracing SDK api, but until the other two are stable, we would have to keep them as compileOnly so that people would need to opt-in to them very intentionally to use them.

[anuraaga]

I think this was mainly to avoid having per-signal artifacts like we have for the normal OTLP exporter to avoid having a sea of artifacts. In hindsight it probably wasn't such a great idea but maybe something to clean up in a distant v2.

I think it would make sense to switch trace to api though indeed we would not want to do that for other signals until they are marked stable. Users would still be able to exclude the dependency if not needed anyways.