Use generated class instead of jar manifest to populate notifier vers…

diegov commented 3 years ago

This PR updates the method we use to find the notifier version, to use a generated Java class instead of the jar's manifest attributes.

This fixes the notifier version attribute when users shade rollbar-java, since until now we could end up reporting the version of the user's application as the notifier version instead of our own, due to the fact that our classes had been merged into the user's jar, and only one manifest resource (the user's) remained.

The approach we take now is to generate a static class at build time, with a single method returning the version. This removes the need for any dynamic resource loading, which could fail under relocation since the references are strings.

Description of the change

Description here

Type of change

[X] Bug fix (non-breaking change that fixes an issue)

[ ] New feature (non-breaking change that adds functionality)

[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)

Related issues

[ch85159]

Checklists

Development

[x] Lint rules pass locally
[x] The code changed/added as part of this pull request has been covered with tests
[x] All tests related to the changed code pass in development

Code review

[ ] This pull request has a descriptive title and information useful to a reviewer. There may be a screenshot or screencast attached
[x] "Ready for review" label attached to the PR and reviewers mentioned in a comment
[ ] Changes have been reviewed by at least one other engineer
[ ] Issue from task tracker has a link to this pull request

diegov commented 3 years ago

Wrong clubhouse reference 🤦‍♂️

shortcut-integration[bot] commented 3 years ago

This pull request has been linked to Clubhouse Story #85159: [L2][SEV 2] Notifier version shows code_version due to Gradle Shadow plugin.

rollbar / rollbar-java