feat(instrumentation-all): introduce aggregate dependency bundling all instrumentation ([#1024](https://github.com/marcschaeferger/opentelemetry-android/issues/1024)) #1254
Conversation
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #1254 +/- ##
=======================================
Coverage 64.29% 64.29%
=======================================
Files 142 142
Lines 3011 3011
Branches 296 296
=======================================
Hits 1936 1936
Misses 998 998
Partials 77 77 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
There was a problem hiding this comment.
Thank you for your contribution, @marcschaeferger!
It is designed to help users explore OpenTelemetry Android's full feature set without having to manage multiple individual dependencies.
My understanding is that the goal of this PR is to create a single dependency that users can add to their projects to get all the auto-instrumentations with a single line of code. The idea is great, but I'm afraid that this approach won't work for the instrumentations that rely on byte code weaving, such as okhttp, compose, httpurlconnection, and android-log. As those depend on the ByteBuddy plugin to be present in the target project, as well as their respective byteBuddy dependencies. So by just adding their libraries, as proposed here, the users won't get them to work.
The only way to provide a "one-liner" solution to apply all instrumentations that I'm aware of is to create a Gradle plugin that would apply the ByteBuddy plugin as well as the regular and byteBuddy dependencies for each instrumentation that has both.
|
Hmmm, do we think that the existing of build-time bytecode instrumentation somehow defeats the utility+convenience of this module, though? Some users will just take the runtime instrumentation or use the wrappers, and it also shouldn't prevent users who want to use the bytebuddy gradle plugin from also adding it, right? |
|
A bit of a tangent, but I think a gradle plugin that performs auto-instrumentation should be a long-term goal of the project. It would make it much simpler to install instrumentation at the appropriate place. |
I think it depends on the user's expectations. If they look at the
That's true, but adding the bytebuddy plugin alone won't make the instrumentations work. To make a single instrumentation work (that relies on bytecode weaving), there has to be a combination of the bytebuddy plugin + agent dependency + runtime dependency. And my understanding is that this |
4 participants
Pull Request: Add
instrumentation:allGradle ModuleIssue: #1024 – Add instrumentation-all package
Summary
This PR adds a new Gradle module
instrumentation:allthat aggregates all end-user Android instrumentation libraries into a single dependency for quick evaluation and experimentation. It is designed to help users explore OpenTelemetry Android's full feature set without having to manage multiple individual dependencies.Issue requested an "
instrumentation-all" package to lower the onboarding friction when evaluating OpenTelemetry Android.By offering a single aggregate module, developers can quickly test features for demos, Proof-of-Concepts, and exploratory instrumentation without manually tracking individual modules, making adoption and initial evaluation significantly simpler.
All Suggestions and changes are welcome ;-)
What's Included
instrumentation:all*:agent,*:testing).instrumentation:allmodule explaining usage, scope, production caveats, and maintenance expectations.instrumentation:all(full install instructions omitted, per guidance) and also fixing small markdown violation.✅ Closes: #1024