Opamp client api

[LikeTheSalad]

Retry of #1481

Creation of the OpampClient main API. It's inspired by the existing OpAMP Go client one with the lifecycle methods as well as some setters and a callback, which is also inspired by the callback in the same Go client.

[trask]

cc @andykellr @evan-bradley @tigrannajaryan

[tigrannajaryan]

I may have said this in the past, but to reiterate: my preference is to make OpAMP Java a separate library. opamp-go is separate and, we don't plan to move it into Go contrib repo. It is sufficiently distinct that keeping it separate makes sense.

It is fine if you want to do the main development in this repo but for consistency it would be nice if before we make a stable release it is moved to opamp-java.

[trask]

my preference is to make OpAMP Java a separate library

hey @tigrannajaryan, each of the components in this repository are published as separate libraries, can you explain a bit more what you mean / what your concerns are with publishing it from this repository? thanks!

[tigrannajaryan]

hey @tigrannajaryan, each of the components in this repository are published as separate libraries, can you explain a bit more what you mean / what your concerns are with publishing it from this repository? thanks!

It is good that it is published as a separate library. However, it is still inconsistent as a practice to put it in the contrib repo, while the Go version uses a separate repo.

[LikeTheSalad]

It is good that it is published as a separate library. However, it is still inconsistent as a practice to put it in the contrib repo, while the Go version uses a separate repo.

It's been a while since we started discussing this implementation, though iirc, one of the things we discussed was that this repo isn't going to be the "final one" for the Java OpAMP Client, though please correct me if I'm wrong, @trask. It's a great place to do experiments with it, especially related to what's going to be its final API, while we can benefit from the available contrib infra that allows us to deploy it as an independent artifact without having to go through the hassle it means to configure a new Java repo to do so.

My plan for this project is to have an independent, yet "internal" client implementation that allows us to do dogfooding in a "safe to break" environment. The reason why I think this is needed, at least within the OTel Java community, is that it seems like there are too many doubts around "what the APIs should look like" and "who's going to maintain it" given that the Java community seems to be short of bandwidth to commit to new projects. So to me it seems like this is a tradeoff that allows us to move forward in the meantime, because otherwise it seems like the alternative is doing nothing at all until an "ideal set of requirements" is met, and I think that'd be wrong because, given that there doesn't seem to be a defined set of rules for what an OpAMP SDK API should look like, then that means that we need to figure it out iteratively, for which we'll need feedback from the community. But for that to happen, we should at least have a "wrong implementation" available to criticise and work upon, otherwise it seems like the Java community will stay paralyzed on this front.

[tigrannajaryan]

I don't mind if the initial experimental implementation is done here. That's totally fine. Once you are certain the implementation is what you need I would prefer that it is moved to a separate opamp-java repo, before making a stable release.