OTeL Java splitting SDK into multiple artifacts

[kenfinnigan]

What are you trying to achieve?

I opened open-telemetry/opentelemetry-java#1460 to split the current single SDK artifact into multiple pieces for Correlation Context, Metrics, Tracing, and then combine them all into a single artifact.

The reason for this is I'd like to use Micrometer for the metrics implementation, as it's a mature and popular framework for handling metrics in Java frameworks. Ideally, I don't want to re-implement the other pieces of the OTeL API to use Micrometer. If the SDK is split into multiple pieces it is easier to switch in Micrometer just for metrics.

Additional context.

There was a concern raised on the issue that this goes against the goal of OTeL to bring metrics, tracing, etc together into a single implementation. I was asked to raise an issue here to hear the perspective of the specification group on such an implementation split for Java.

[Oberon00]

IMHO, in how many artifacts some OpenTelemetry implementation is split up is an implementation detail, as long as the API artifact(s) are separate from the SDK artifact(s).

[andrewhsu]

from the spec sig mtg today, marking as required for ga to make a decision on what to do based on the question

[reyang]

I think each language should have freedom to decide how the SDK is componentized/organized:

1. In C/C++, the linker will do the job. We don't ship *.dll/*.so at this moment so it is not a concern.
2. In JavaScript, the web scenario would normally want the script to be combined and minimized to improve load speed.

[carlosalberto]

+1 to having the SDK packages separation as an implementation detail.

[jkwatson]

Is there value in noting this in the specs, or should we just assume that wasn't isn't forbidden is explicitly ok, wrt implementation details?

[arminru]

+1 to having the SDK packages separation as an implementation detail.

@jkwatson I think explicitly stating this in the spec would be fine.

[tigrannajaryan]

I suggest that we close this issue as a "wont-fix" since it is an implementation detail and does not need to be in the specs.

[arminru]

I think adding/adapting one or two sentences to explicitly allow this to the spec would still make sense since some statements make it sound like the spec would prescribe the exact structure, e.g.:

https://github.com/open-telemetry/opentelemetry-specification/blob/master/specification/library-guidelines.md#expected-usage

The OpenTelemetry Language Library is composed of 2 packages: API package and SDK package.

I added two extra lines making it clear in #931.