-
Notifications
You must be signed in to change notification settings - Fork 867
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Change the default javaagent artifact to have exporters #4106
Change the default javaagent artifact to have exporters #4106
Conversation
asset_path: javaagent/build/libs/opentelemetry-javaagent-${{ github.event.inputs.version }}-all.jar | ||
asset_name: opentelemetry-javaagent-all.jar | ||
asset_path: javaagent/build/libs/opentelemetry-javaagent-${{ github.event.inputs.version }}.jar | ||
asset_name: opentelemetry-javaagent.jar |
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.
I agree with the rename but it's sort of a breaking change for e.g., Dockerfiles that may be curling the "latest release" URL. Should we upload both at least for one release?
We may also consider whether it is bad practice in general to point at an unversioned URL - if so we can probably update our README to not point at the latest version URL to discourage usage.
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.
Should we upload both at least for one release?
makes sense to me, I added attaching backwards compatible "all" artifact step to both release and patch release builds
update our README to not point at the latest version URL to discourage usage
I like explicit versions in docs (and keeping it updated), IIRC we were stuck on how to automate this? maybe we can tack this problem on to #3516 @iNikem?
// TODO (trask) this needs to be updated now that no more "all" artifact | ||
return "all".equals(classifier) && "jar".equals(extension); |
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.
@breedx-splk any idea with this change if the classifier check should be changed to ""
or null
?
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.
Is the idea here that we'll be publishing the full agent with exporters now without the -all
classifier? If so, then I think we should just remove the classifier check entirely.
It looks like you're also publishing -all
for backwards compat? Assuming that's temporary, yeah, I think we'll want to remove this classifier check...but it might be nice to see what the xml looks like after the first publish to confirm.
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.
the -all
artifact will be attached to the github release for now for backwards compatibility, but won't be published.
there will be a new artifact -slim
published after this tho
it might be nice to see what the xml looks like after the first publish to confirm
this works for me 👍
I vaguely remember that we wanted to make this change after extracting contrib portion. To minimize the number of times we change the meaning of our artifacts. |
I added to tomorrow's meeting agenda |
moving back to draft for now and deferring until after the 1.6.0 release |
we discussed in SIG meetings this week, and I think there's general agreement to go forward with this PR now (see discussion in #3959) I'll raise once more in next Tue SIG meeting and will merge after that if there's still agreement. |
and will add otlp/http exporter to "-slim" as a follow-up PR (for now in this PR "-slim" has no exporters, same as the previous default artifact) |
@@ -73,6 +78,10 @@ dependencies { | |||
|
|||
exporterLibs(project(":javaagent-exporters")) | |||
|
|||
exporterSlimLibs("io.opentelemetry:opentelemetry-exporter-otlp") | |||
exporterSlimLibs("io.opentelemetry:opentelemetry-exporter-otlp-metrics") | |||
exporterSlimLibs("io.grpc:grpc-okhttp:1.41.0") |
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.
Just realized that because this is using okhttp
, adding the HTTP exporters as well should be almost no additional bytecode, so maybe worth it?
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.
Well assuming it doesn't cause dependency hell, wow that's old
https://github.com/grpc/grpc-java/blob/master/build.gradle#L158
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.
Err - nevermind, yeah it wouldn't cause dependency hell since it's a different artifact
So scratch the almost-no-additional-bytecode idea.
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.
By the way, just some random trivia grpc/grpc-java#6119 (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.
"OkHttp" name for the transport is a bit of a misnomer
this thread helped my mental picture 👍
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.
It appears that we can exclude okhttp 2 from the transitive dependencies
open-telemetry/opentelemetry-java#3678
though I added a comment on the grpc-java issue to see if there is anything obviously bad with that.
Currently I guess we effectively have two copies of okhttp2, the forked-into-grpc one and the transitive dependency which we don't seem to need.
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.
I added #4240 to discuss/track
> :warning: prior to version 1.0.0, `opentelemetry-javaagent-all.jar` | ||
only supports manual instrumentation using the `opentelemetry-api` version with the same version | ||
number as the Java agent you are using. Starting with 1.0.0, the Java agent will start supporting | ||
multiple (1.0.0+) versions of `opentelemetry-api`. | ||
|
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.
Are we sure about that? Have we tested that?
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.
we have a smoke test that verifies interop with opentelemetry-api 1.0.0, and #3044 to track doing better than that with muzzle
(also, this is old doc, I'm removing it, see #4106 (comment))
javaagent/build.gradle.kts
Outdated
@@ -164,17 +184,15 @@ tasks { | |||
} | |||
} | |||
|
|||
// Includes everything needed for OOTB experience | |||
val fullJavaagentJar by registering(ShadowJar::class) { | |||
// Includes instrumentations, but not exporters |
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.
Slim does include OTLP exporter, right?
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.
fixed 👍
And introduce a new artifact with classifier "slim"
which does not have any exporters (same as what used to be the default artifact).EDIT: which has only otlp/grpc (and using okhttp instead of netty for size)Resolves #3959
Will send separate PR to be merged after the release updating: