Jack Berg

It sounds like you're using the jaeger exporter, yet you've linked to docs for configuring the OTLP exporter. The minimal set of env vars needed to configure the jaeger exporter...

It feels strange accepting additions to the stable extension annotations module without knowing what an implementation of a corresponding annotation processor looks like. Can `opentelemetry-extension-annotations` move to `opentelemetry-java-instrumentation` to live...

Hi @fstab just following up on @jkwatson's comment. Here's where we're at: - We don't think opentelemetry-java is the right long term home for these annotations, given that the primary...

I'm going to close this because now that we've moved forward with the decision to move annotations to `opentelemetry-java-instrumentation`.

Sorry for not responding sooner. I've been hesitant to accept this because it introduces a new transitive dependency for the `:exporters:zipkin` module on `com.squareup.okhttp3:okhttp`. More generally, the `:exporters:otlp:common` artifact is...

It shades in okhttp [io.zipkin.reporter2:zipkin-sender-okhttp3](https://github.com/open-telemetry/opentelemetry-java/blob/main/exporters/zipkin/build.gradle.kts#L18).

This is unblocked now that #4575 is merged. I've pushed a commit to rebase. Thanks @Donnerbart!

@jkwatson any additional thoughts before I merge this?

> Its not quite clear to me why such design exists. Hi @splatch - sorry for the delayed reply. Not sure what the best answer is here, but I can...

@anuraaga its a little unclear, but my read of that section of the spec is that the language on `job` and `instance` labels for remote write and federated pull exporter...