chore: make version embedding more robust#451
Conversation
Codecov Report
@@ Coverage Diff @@
## master #451 +/- ##
=============================================
+ Coverage 59.20% 80.63% +21.43%
- Complexity 19 1116 +1097
=============================================
Files 2 106 +104
Lines 125 6942 +6817
Branches 18 369 +351
=============================================
+ Hits 74 5598 +5524
- Misses 34 1145 +1111
- Partials 17 199 +182
Continue to review full report at Codecov.
|
13b4dc3 to
696dc80
Compare
The previous approach used the jar manifest. Unfortunately that approaches falls apart when the consumer shades the client jar. The new approach uses a combination of releasetool's version tag replacement and maven-resources-plugin to generate a class with an embedded version string.
696dc80 to
f6dd067
Compare
| // Note: this file MUST be named GoogleUtils.java so that it can be picked up by releasetool | ||
| public class GoogleUtils { | ||
| public static final String BIGTABLE_CLIENT_VERSION = | ||
| "1.16.1-SNAPSHOT"; // {x-version-update:google-cloud-bigtable:current} |
There was a problem hiding this comment.
@chingor13, to get this to work, I'm guessing we need to add a path here? https://github.com/googleapis/release-please/blob/master/src/releasers/java-yoshi.ts#L182 Any thing else?
This reverts commit 22d831c.
|
As discussed offline: This is a temporary solution. In the future we will stop relying on maven resource filtering and instead hardcode the version and bump it by release-please |
|
It's worth understanding why the customer was shading, and removing the need for that. |
* chore: make version embedding more robust The previous approach used the jar manifest. Unfortunately that approaches falls apart when the consumer shades the client jar. The new approach uses a combination of releasetool's version tag replacement and maven-resources-plugin to generate a class with an embedded version string. * Simplify by using a file allowlisted in release-tool * Revert "Simplify by using a file allowlisted in release-tool" This reverts commit 22d831c.
Use new feature in releasetool (googleapis/releasetool#317) to manage the client version instead of maven tricks introduced in googleapis#451
* chore: improve embedded version handling Use new feature in releasetool (googleapis/releasetool#317) to manage the client version instead of maven tricks introduced in #451 * migrate to new version scheme * rename back to Version * config release-please for version bumps * make sure file doesnt get clobbered * add a couple of tests * fmt
* chore: improve embedded version handling Use new feature in releasetool (googleapis/releasetool#317) to manage the client version instead of maven tricks introduced in googleapis#451 * migrate to new version scheme * rename back to Version * config release-please for version bumps * make sure file doesnt get clobbered * add a couple of tests * fmt (cherry picked from commit 1af8925)
* chore: improve embedded version handling (#715) * chore: improve embedded version handling Use new feature in releasetool (googleapis/releasetool#317) to manage the client version instead of maven tricks introduced in #451 * migrate to new version scheme * rename back to Version * config release-please for version bumps * make sure file doesnt get clobbered * add a couple of tests * fmt (cherry picked from commit 1af8925) * update version * fix test * fix: add back in extraFiles and fix file path (#833) (cherry picked from commit f914954) * fix test Co-authored-by: Igor Bernstein <igorbernstein@google.com>
The previous approach used the jar manifest. Unfortunately that approaches falls apart when the
consumer shades the client jar. The new approach uses a combination of releasetool's version tag
replacement and maven-resources-plugin to generate a class with an embedded version string.