The java story around the OTLP exporter

[svrnm]

The java story around the OTLP exporter is actually pretty nuanced... What you describe here works, but its not the only way.

There are two versions of OTLP we support: grpc and http/protobuf

These have exporter classes of the form OtlpGrpc{Signal}Exporter for grpc, and OtlpHttp{Signal}Exporter for http/protobuf.

Under the hood, there are multiple sender implementations for each of these. Sender is an abstraction we created to be able to plugin different grpc / http client implementations to fulfill the OTLP contract. You select which sender implementation you want by optionally include / excluding dependencies. Here is the list (as of the 8/11 1.29.0 release):

• opentelemetry-exporter-sender-okhttp - The default, included automatically with opentelemetry-exporter-otlp. This includes an okhttp based sender for both OtlpGrpc{Signal}Exporter and OtlpHttp{Signal}Exporter. It works for many people, and is included in the otel java agent distribution. However, certain use cases want to avoid the okhttp dependency, since it has a transitive dependency on kotlin. The alternatives below accommodate these use cases.
• opentelemetry-exporter-sender-jdk - Provides an jdk 11+ http client sender implementation for OtlpHttp{Signal}Exporter. You can use this if you have java 11+, and prefer to avoid extra dependencies since this uses code that comes built into java. If using, you'll want to explicitly exclude the default opentelemetry-exporter-sender-okhttp, and note that you wont be able to use this with OtlpGrpc{Signal}Exporter.
• opentelemetry-exporter-sender-grpc-managed-channel - Provides a sender implementation for OtlpGrpc{Signal}Exporter based on the grpc java client. This supports folks who insist on using ManagedChannel.

Although its a bit complex, there are valid use cases that demand each of these solutions. We think that between these solutions we can make virtually everyone happy.

Eventually, i do want to document what I've written down here (see here). Not sure whether we should include it in this PR or a followup.

Originally posted by @jack-berg in #3144 (comment)

[jack-berg]

Will work on a PR for this soon!