Publish proto definitions to maven central

[cwildman]

For Java projects it would be developer friendly to have the OpenTelemetry proto definitions published to maven central with a release tagged with the correct OTLP version.

The existing ways to use these proto definitions or their generated classes in Java projects are:

1. Git submodules which bring in unnecessary complexity for developers and build tooling
2. The OpenTelemetry Java opentelemetry-proto artifact which is confusingly tagged with the version of OpenTelemetry java, not the version of the OTLP being used. This also relies on generated code which has been checked-in which is not my preference for working with IDLs. For example what if you need to change your version of protoc before compiling.
3. Following what OTEL java does and downloading the github release and depending on that in your build tooling.

It would be much more convenient to just have the proto definitions published in a jar to maven central to be used by standard Java build tooling. For example using the protobuf-gradle-plugin to reference a proto dependency.

Alternatively #2 would work if OpenTelemetry Java was willing to tag the opentelemetry-proto releases with the OTLP version but that proposal did not get traction. See the discussion in #otel-java slack here.

I'm interested in other ideas to streamline this. I realize this isn't a huge issue but it's certainly awkward to work with as-is.

[jkwatson]

Just to add color...this has come up before, and the proto jar that is published out of the java project is not intended for general usage. In fact, we have recently updated the java exporters to not use it any more, and are strongly considering stopping the publishing of it altogether.

[cwildman]

@jkwatson that's helpful because the second sentence in the README makes it seem like those are for general usage.

[jkwatson]

@jkwatson that's helpful because the second sentence in the README makes it seem like those are for general usage.

Hmm. That's not a comment that I was aware existed. It's technically true, but shouldn't imply (at least for java, where we've still marked the proto artifact as -alpha) that this is mandatory for languages to do.

[jsuereth]

You can see the current thinking on language-specific publishing of this repository here: #231

Would you be interesting in creating a java-proto specific repository that releases (to maven) a general-purpose java proto package? Does this make sense to do (cc @jkwatson @anuraaga)?

[cwildman]

@jsuereth thanks for pointing me to that PR, it looks like @anuraaga was highlighting the same friction. I'm actually advocating for the middle ground between @yurishkuro and @anuraaga. I agree opentelemetry-proto shouldn't have to publish the language specific classes but it should make it easy for languages to consume the raw proto itself, hence publishing it to maven central with the correct version.

Would you be interesting in creating a java-proto specific repository that releases (to maven) a general-purpose java proto package?

Yes that sounds great to me. I assume here you're talking about releasing the .proto only, nothing else? This would basically look like taking the existing opentelemetry-java/proto build and removing the proto generation(generateProto) and including the release tasks.

[cwildman]

And just to fully understand the tradeoff we're making, the downside to doing this in a separate repo is that it is yet another place that needs an update and release when a new OTLP version is released here.

[jkwatson]

I just realized another reason why you probably wouldn't want to use opentelemetry-java's published protos, anyway. We don't guarantee any sort of timely update to our proto library, since we want to wait until the collector has baked in the new version before we incorporate it into the library itself. So, 👍🏽 on a separate project for managing that publishing.

[jsuereth]

@cwildman Yeah, that's exactly what I'm suggesting. We need to find a set of owners willing to keep it up to date and publish w/ every OTLP release. John has chimed in, what does @anuraaga (and other java maintainers) think of this proposal?

[anuraaga]

Yeah I think a separate repo to handle proto publishing is a good idea - will look into setting that up. It seems weird for opentelemetry-java-proto to publish only proto files, I suspect we'll publish the same thing we do now - generated code + the proto files together, just the output of the gradle protobuf plugin.

And just to fully understand the tradeoff we're making, the downside to doing this in a separate repo is that it is yet another place that needs an update and release when a new OTLP version is released here.

Since we only use the protos in tests in the SDK repo now, I think we'll just use this new one and remove our current opentelemetry-proto so no worries here I think.

[cwildman]

Since we only use the protos in tests in the SDK repo now, I think we'll just use this new one and remove our current opentelemetry-proto so no worries here I think.

My point was that if this repo, open-telemetry/opentelemetry-proto, published to maven central as part of its release process there wouldn't be extra work. My impression is though the maintainers of the opentelemetry-proto itself don't want language specific release details in this repository.

[anuraaga]

Thanks for the patience @cwildman - we are publishing protos using the OTLP versions to Maven Central now

https://github.com/open-telemetry/opentelemetry-proto-java/releases/tag/v0.11.0

https://repo1.maven.org/maven2/io/opentelemetry/proto/opentelemetry-proto/0.11.0-alpha/

Let me know if you see any issues.

[cwildman]

@anuraaga this is great news! I gave it a try and everything is working as expected. Thanks!

[jkwatson]

@anuraaga this is great news! I gave it a try and everything is working as expected. Thanks!

awesome. we're going to deprecate the proto being published by otel-java and remove it altogether in 1.8.0

[jkwatson]

Also, @cwildman, it looks like the new repo needs some documentation love. Would you be willing to do some doc work here?

[cwildman]

@jkwatson yes I can help with that.