-
Notifications
You must be signed in to change notification settings - Fork 831
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
Create OtelVersion class at build time. #5365
Create OtelVersion class at build time. #5365
Conversation
/** | ||
* Autogenerated class do not edit. | ||
*/ | ||
public final class OtelVersion { |
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.
My only concern with this approach: will devs have to run a gradle build in order to be able to compile in IDEA? Or is IDEA smart enough to run what needs to be run and get this file into the generated source when the project is imported?
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'm sure a gradle build step has to happen before Resource
can compile. Isn't that the same with autovalue tho?
Another option was to do string substitution on the actual source tree, but that leaves uncommitted changes. Open to alternatives.
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.
Here is one idea of how to compromise: https://gist.github.com/breedx-splk/01278cc3eb94415353cac1f9cdce89c7
The idea is instead of referencing a static field constant, try to do the same with reflection, and if that fails, fall back to the previous behavior. I don't love it.
Codecov ReportPatch coverage:
Additional details and impacted files@@ Coverage Diff @@
## main #5365 +/- ##
============================================
+ Coverage 91.20% 91.29% +0.08%
- Complexity 4865 4874 +9
============================================
Files 546 549 +3
Lines 14369 14352 -17
Branches 1351 1352 +1
============================================
- Hits 13105 13102 -3
+ Misses 875 863 -12
+ Partials 389 387 -2
... and 27 files with indirect coverage changes Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. ☔ View full report in Codecov by Sentry. |
Can you elaborate on this please 🙂 |
sdk/common/src/main/java/io/opentelemetry/sdk/resources/Resource.java
Outdated
Show resolved
Hide resolved
id("otel.animalsniffer-conventions") | ||
} | ||
apply<OtelVersionClassPlugin>() |
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.
If we do this for :sdk:common
, should we do it everywhere?
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 only wanted to do this in the one place where it's used. If there are other places that ever need to reference the class, then those modules can apply the plugin. I don't think we need it floating around every module. Feels bloaty.
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.
That seems reasonable. Here are some other places we read the version:
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.
And those will still continue work, I didn't remove the properties behavior. Are you suggesting that we should tackle those all in this same PR?
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 you suggesting that we should tackle those all in this same PR?
If we have this pattern, it offers a pretty clean way of accessing the version. Adding a plugin to the gradle build is cleaner than copy / pasting the code to read from the resource.
Doesn't have to be in this PR, but if we like this pattern I think we should standardize on it.
Sure: signalfx/splunk-otel-android#507 |
The stacktrace indicates that |
Ugh, can we please discuss this aspect of this elsewhere? |
Sure, can you open an issue for this then? Trying to understand if the current |
Oh sure #5369 |
buildSrc/src/main/kotlin/io/opentelemetry/gradle/OtelVersionClassPlugin.kt
Outdated
Show resolved
Hide resolved
buildSrc/src/main/kotlin/io/opentelemetry/gradle/OtelVersionClassPlugin.kt
Outdated
Show resolved
Hide resolved
buildSrc/src/main/kotlin/io/opentelemetry/gradle/OtelVersionClassPlugin.kt
Outdated
Show resolved
Hide resolved
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.
Couple small comments, but I approve of the direction 👍
…assPlugin.kt Co-authored-by: jack-berg <[email protected]>
…assPlugin.kt Co-authored-by: jack-berg <[email protected]>
So the current approach for finding the
telemetry.sdk.version
for theResource
usesgetResourceAsStream()
. Although this has been working fine, we recently discovered that this can be slow on some platforms.The approach submitted here generates a java source file that contains the build-time version number, and the source is added to the common project's source tree. This then allows the
Resource
to just reference the constant, rather than having to read the version dynamically at runtime.