SOLR-16236: Clarify use of GSON jar in jaegertracer-configurator

[epugh]

https://issues.apache.org/jira/browse/SOLR-16236

Description

README doesn't reflect whats actually going on... GSON is being included in the module, but shouldn't.

Solution

Fix readme! Fix gson being included.

Tests

manual builds

Checklist

Please review the following and check all that apply:

• [X ] I have reviewed the guidelines for How to Contribute and my code conforms to the standards described there to the best of my ability.
• [ X] I have created a Jira issue and added the issue ID to my pull request title.
• [ X] I have given Solr maintainers access to contribute to my PR branch. (optional but recommended)
• [ X] I have developed this patch against the main branch.
• [ X] I have run ./gradlew check.
• I have added tests for my changes.
• I have added documentation for the Reference Guide

[dsmiley]

Thanks

[risdenk]

I'm not sure I understand why this change is needed. If "remote" is the default in jaeger, and "remote" requires gson - why are we excluding it? It just seems like the documentation was incorrect about needing to manually add gson. I don't think we should be excluding dependencies on a regular basis - especially if they are needed for things to work by default.

[epugh]

I'm not sure I understand why this change is needed. If "remote" is the default in jaeger, and "remote" requires gson - why are we excluding it? It just seems like the documentation was incorrect about needing to manually add gson. I don't think we should be excluding dependencies on a regular basis - especially if they are needed for things to work by default.

@dsmiley can you weigh in on this?

[dsmiley]

Check out the documentation of the sampler choices: https://www.jaegertracing.io/docs/1.22/sampling/
The remote choice is rather exotic IMO; I acknowledge it is nonetheless the default. We can more clearly document changing it, thus encouraging people to do so.
Nonetheless I don't feel too strongly about this. My preference is to reduce needless dependency exposure. But I see we already include it in some other modules (Tika, GCS, ...)

[epugh]

Thoughts folks? I kind of need a tie breaker to decide which way to go... I'd like to merge this sooner versus later as I'm accumulating more "pending PR's to get to done" then I like ;-) Maybe whoever updates the PR first wins? ;-)

[janhoy]

I vote for keeping gson in the distro, making sure that even "remote" sampling works for all users. Seems quite useful in large deploys according to this blog: https://medium.com/jaegertracing/adaptive-sampling-in-jaeger-50f336f4334

[HoustonPutman]

We already rely on it in other contribs, so I see no harm.

[epugh]

Can I get a LGTM?

[dsmiley]

👍