Following the spirit of moving opentelemetry-extension-annotations to a more appropriate home in opentelemetry-java-instrumentation, and prompted by a discussion in the 7/28 Office Hours, I've done a scan of the project for components that are candidates to live elsewhere. The list includes all artifacts that contain code that isn't explicitly included in the spec, with exceptions for opentelemetry-micrometer1-shim and opentelemetry-extension-kotlin.
Comments
opentelemetry-extension-aws - Not sure what the history is here, but xray propagator isn't included in the list of propagators defined the spec and including it in the core sets a precedent of making exceptions. I'd like to see this deprecated and moved to opentelemetry-java-contrib/aws-xray.
opentelemetry-extension-incubator - I like the idea of having places to incubate API / SDK concepts, but think if they're going to live in the core project there needs to be a path to inclusion the stable API / SDK artifacts. Not clear that that path exists for PassThroughPropagator or ExtendedTracer.
opentelemetry-extension-noop-api - Should probably move this toopentelemetry-java-contrib. If we think its important enough to keep in core, perhaps opentelemetry-extension-incubator, since there may be a chance for a completely noop implementation to be added to the spec some day.
opentelemetry-sdk-extension-resources - I don't feel especially strongly about this, but this probably makes more sense in opentelemetry-java-instrumentation.
opentelemetry-sdk-extension-aws - I think this makes most sense in opentelemetry-java-instrumentation, especially if the standard resource providers end up there.
opentelemetry-sdk-extension-jfr-events - Move to opentelemetry-java-contrib.
opentelemetry-sdk-extension-metric-incubator - Can probably retain since file based SDK configuration is being very seriously discussed in the specification.
opentelemetry-sdk-extension-tracing-incubator - If we're confident enough with the LeakDetectingSpanProcessor, we should consider promoting it to the stable opentelemetry-sdk-testing artifact, since it makes sense as a testing utility.
opentelemetry-sdk-extension-zpages - zPages are mentioned in the experimental section of the specification, but I think this could be merged into opentelemetry-sdk-extension-tracing-incubator, since there are no transitive dependencies required to run.
Following the spirit of moving opentelemetry-extension-annotations to a more appropriate home in
opentelemetry-java-instrumentation, and prompted by a discussion in the 7/28 Office Hours, I've done a scan of the project for components that are candidates to live elsewhere. The list includes all artifacts that contain code that isn't explicitly included in the spec, with exceptions foropentelemetry-micrometer1-shimandopentelemetry-extension-kotlin.opentelemetry-extension-awsAwsXRayPropagatorandAwsConfigurablePropagator, which implements theConfigurablePropagatorProviderSPI.opentelemetry-extension-incubatorPassThroughPropagatorandExtendedTracer.opentelemetry-extension-noop-apiOpenTelemetryimplementation.opentelemetry-sdk-extension-resourcesopentelemetry-sdk-extension-awsopentelemetry-sdk-extension-jfr-eventsopentelemetry-sdk-extension-metric-incubatoropentelemetry-sdk-extension-tracing-incubatorLeadDetectingSpanProcessoropentelemetry-sdk-extension-zpagesComments
opentelemetry-extension-aws- Not sure what the history is here, but xray propagator isn't included in the list of propagators defined the spec and including it in the core sets a precedent of making exceptions. I'd like to see this deprecated and moved to opentelemetry-java-contrib/aws-xray.opentelemetry-extension-incubator- I like the idea of having places to incubate API / SDK concepts, but think if they're going to live in the core project there needs to be a path to inclusion the stable API / SDK artifacts. Not clear that that path exists forPassThroughPropagatororExtendedTracer.opentelemetry-extension-noop-api- Should probably move this toopentelemetry-java-contrib. If we think its important enough to keep in core, perhapsopentelemetry-extension-incubator, since there may be a chance for a completely noop implementation to be added to the spec some day.opentelemetry-sdk-extension-resources- I don't feel especially strongly about this, but this probably makes more sense inopentelemetry-java-instrumentation.opentelemetry-sdk-extension-aws- I think this makes most sense inopentelemetry-java-instrumentation, especially if the standard resource providers end up there.opentelemetry-sdk-extension-jfr-events- Move toopentelemetry-java-contrib.opentelemetry-sdk-extension-metric-incubator- Can probably retain since file based SDK configuration is being very seriously discussed in the specification.opentelemetry-sdk-extension-tracing-incubator- If we're confident enough with theLeakDetectingSpanProcessor, we should consider promoting it to the stableopentelemetry-sdk-testingartifact, since it makes sense as a testing utility.opentelemetry-sdk-extension-zpages- zPages are mentioned in the experimental section of the specification, but I think this could be merged intoopentelemetry-sdk-extension-tracing-incubator, since there are no transitive dependencies required to run.