Create a jar with the dependencies for easy deployment

[carlosalberto]

Requirement: To provide a jar with all the dependencies and tracerresolver support.

The new ongoing SpecialAgent effort is designed to take a single jar that provides a Tracer through a TracerFactory - as part of this I've been putting some prototype in
https://github.com/opentracing-contrib/java-opentracing-lightstep/tree/master/jaeger to create such a jar (minor work needed, as you can see).

Problem - Be able to use Jaeger along the SpecialAgent

Not an actual problem, but more of a good thing to have ;)

Proposal

To have a module (part of this repo or outside it) that builds and publishes a JAR (core, thrift transport, tracerresolver). I can create a small PR for this repo if needed ;)

[yurishkuro]

I am not opposed to this in principle, but the main question is what you consider "all the dependencies"? Jaeger client is composable, there are modules that some people may or may not need, e.g. jaeger-zipkin, or if we introduce grpc reporter in the future then thrift & grpc would not be needed together.

Why is this a limitation of the special agent that only one jar can be used?

[carlosalberto]

Hey @yurishkuro

Thanks for the feedback. So, "all the dependencies" in this context means the simplest complete (standard) profile that would make Jaeger run. In the "simplest" part, I'm not including the optional components (such as the zipkin connector) - oh, and if you guys accept this route, I will update the docs to reflect this, of course ;)

And also: correct, if you introduce grpc support in the future, then you would need to provide one fat-jar for each one (or only one, for either grpc or thrift).

The limitation from the SA side is actually only about using a single TracerFactory jar per run.

Let me know if you think I should include other components here.

[yurishkuro]

Is it not what jaeger-client artifact already contains?

https://github.com/jaegertracing/jaeger-client-java/tree/master/jaeger-client

[carlosalberto]

@yurishkuro Yes, the very same - but exposed as a fat-jar that can be simply passed around - the SpecialAgent scenario is one example, but also instrumenting Cassandra on the server side (when implemented) could make use of this (as you have to copy the jars to the deployment directory).

Let me know ;)

[yurishkuro]

I see. @jpkrohling I thought we already had fat jar somewhere. It feels to me that if the scope of the two artifacts is the same (i.e. jaeger-client), then slim/fat jars should be released from the same project, only tagged differently.

[objectiser]

The only issue is if we want to have fat jars for both thrift and grpc - in that case it may make more sense to have separate modules.
If we only want to have a far jar for our preferred transport, so switching to grpc when available, then could be done within the same module.

[yurishkuro]

Yes, we're talking about a default/recommended configuration, which is what jaeger-client provides now. It's a slim jar now with transitive dependencies. How do we publish an additional fat jar from the same module?

[objectiser]

The thrift module provides an example of how to create a "shadow" (i.e. fat jar) in the same module. We should also relocate the dependencies to internal packages to avoid conflicts with same dependencies (diff versions) used by client app.

[carlosalberto]

Hey @yurishkuro @objectiser

I updated #601 the build script so now the fat-jar is built as part of jaeger-client, instead of doing it in a different module.

Observe that:

• I'm shading a few libraries (while keeping the dependency to SJ4L, as without it the fat-jar fails to load)
• I'm using the bundle classifier - would you guys prefer shadow for this fat-jar?
• I'm building this (extra) fat-jar as part of the check task, instead of building it as part of building jaeger-crossdock, as jaeger-thrift does for its shadow one (I have no idea what this is). Let me know if this is ok ;)

[jpkrohling]

I remember we had all sorts of build problems with the shadow enabled by default for the client module. It would be good to get the commit history for the whole client module and see how it evolved.