-
Notifications
You must be signed in to change notification settings - Fork 231
Add a new submodule to build a client bundle. #601
Conversation
Signed-off-by: Carlos Alberto Cortez <calberto.cortez@gmail.com>
22247f8
to
238c6d3
Compare
Signed-off-by: Carlos Alberto Cortez <calberto.cortez@gmail.com>
Codecov Report
@@ Coverage Diff @@
## master #601 +/- ##
============================================
- Coverage 89.53% 89.27% -0.26%
+ Complexity 542 540 -2
============================================
Files 68 68
Lines 1949 1949
Branches 251 251
============================================
- Hits 1745 1740 -5
- Misses 129 133 +4
- Partials 75 76 +1
Continue to review full report at Codecov.
|
Signed-off-by: Carlos Alberto Cortez <calberto.cortez@gmail.com>
jaeger-client/build.gradle
Outdated
@@ -7,3 +9,28 @@ dependencies { | |||
|
|||
testCompile group: 'junit', name: 'junit', version: junitVersion | |||
} | |||
|
|||
/* Shaded the same libraries as jaeger-thrift, | |||
* leaving the slf4j dependency in place, as a *requirement* |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This comment seems out of date now.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Although not sure whether the slf4j-api should be shaded, as there is no slf4j logging impl as part of this uber jar, so would need to pick it up from the app's dependencies. Not sure what the impact of shading the api would have on picking up an impl?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I was wondering about this myself later on (whether shading it or not). So I think I will update the code to not shade it at all.
jaeger-client/build.gradle
Outdated
relocate 'okio' , 'io.jaegertracing.vendor.okio' | ||
relocate 'org.apache' , 'io.jaegertracing.vendor.org.apache' | ||
relocate 'org.slf4j' , 'io.jaegertracing.vendor.org.slf4j' | ||
classifier 'bundle' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would prefer another name - bundle
makes me think OSGi 😄 , but not sure what might be better. Could be something simple like all
- but will let others comment.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
all
sounds about right to me.
} | ||
} | ||
|
||
tasks.check.dependsOn tasks.shadowJar |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This wasn't required in the thrift usecase - was the shadowJar task not being triggered?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
shadowJar
is only being triggered in the thrift case when jaeger-crossdock
is being built. Based on what you wrote, it sounds like we should do the same here? :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure it should be dependent on jaeger-crossdock
build - ideally it should just be built when the non-shaded artifact is being built.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, then this line should stay, as it builds the shaded artifact right after the non-shaded one was built.
* Use a 'all' classifier. * Do not shade slf4j. Signed-off-by: Carlos Alberto Cortez <calberto.cortez@gmail.com>
I've updated the PR to reflect the latest feedback. Let me know ;) |
@carlosalberto looks good - my only concern is that I believe the qualified jar dependency would still have a transient dependency on the non-shaded dependencies. If the main use of the jar is to physically download the jar and include it with a javaagent, then this would not be an issue. But if someone includes the dependency in their app's pom.xml, this would still pull in the transient dependencies. I guess they could always exclude them - but not ideal. What do others think? |
Hey hey @objectiser Trying to re-take this conversation:
I think this is the exact use scenario, yes - to download and use it directly (would also work when doing Cassandra server side instrumentation, where you would simply put this JAR in the Cassandra bin path). |
@carlosalberto Agree it meets that use case - just worried whether some users would expect to use it as a pom dependency. @jpkrohling Thoughts? Would documenting this in the readme be enough? |
@carlosalberto would you please list the contents of your local Maven repository for the affected artifact like, If you are producing both a "slim" and a "fat" jar, I'd be interested in seeing the |
Have a bundled Client artifact (fat jar)
Addresses #599 - I'm wondering if this name would go well with the rest of the artifacts ;)
Let me know if this could be of help.