Skip to content

Move non-core components out of opentelemetry-java #4661

@jack-berg

Description

@jack-berg

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.

Artifact Status Description
opentelemetry-extension-aws stable Consists of AwsXRayPropagator and AwsConfigurablePropagator, which implements the ConfigurablePropagatorProvider SPI.
opentelemetry-extension-incubator alpha Consists of PassThroughPropagator and ExtendedTracer.
opentelemetry-extension-noop-api alpha Includes a completely noop OpenTelemetry implementation.
opentelemetry-sdk-extension-resources stable Resource detectors for container, host, os, and process
opentelemetry-sdk-extension-aws stable AWS resource providers.
opentelemetry-sdk-extension-jfr-events alpha SpanProcessor which records spans as JFR events.
opentelemetry-sdk-extension-metric-incubator alpha Includes file based view configuration.
opentelemetry-sdk-extension-tracing-incubator alpha Includes the LeadDetectingSpanProcessor
opentelemetry-sdk-extension-zpages alpha zPages SpanProcessor

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    Feature RequestSuggest an idea for this project

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions