Context in its own package?

Although io.grpc.Context is shipped in its own artifact, and non-gRPC users can also depend on it, the package name still causes branding issue (google/instrumentation-java/issues/162), and a practical issue with OSGI (#2727). We may consider moving it into its own package and splitting it completely from gRPC.

We have two questions to answer:

1. What should the new package name be? Probably something starting with com.google, but probably not com.google.common.context because it collides with a Google’s proprietary context class.
2. How to bridge the old Context and Deadline to the new ones.

[codefromthecrypt]

Could be a non-company’specific package name similar to dagger which just uses one word iirc. Short package helps as you can fully qualify the class easily in adapters

On 30 Mar 2017 08:02, “Bogdan Drutu” [e-mail] wrote:

We can put it under com.google.instrumentation.context (but again it may not be generic enough and probably the name is too long). Can we put it in com.google.context or com.google.base?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/grpc/grpc-java/issues/2847#issuecomment-290262409, or mute the thread https://github.com/notifications/unsubscribe-auth/AAD613167xYd09n-xX3Rd_yj7o2T7Himks5rqvD9gaJpZM4MleqG .

[aseovic]

As I mentioned in #3522, it definitely feels like something like this should already be a part of JDK, but unfortunately it isn’t. Based on the discussion above, com.google.context does seem to make most sense.

The bottom line is that it certainly doesn’t feel like it belongs to io.grpc namespace (or project), considering that it has nothing to do with gRPC itself, and that both instrumentation-api and opencensus-api depend on it (which creates a really strange dependency graph, considering that grpc-core depends on both of those).