| commit | 72bef10798882e7a28e5ba5dc592b50c0c5ccc78 | [log] [tgz] |
|---|---|---|
| author | cpovirk <[email protected]> | Tue Nov 08 15:57:02 2022 |
| committer | Google Java Core Libraries <[email protected]> | Tue Nov 15 21:58:36 2022 |
| tree | 047e78340c9894dbc45638c8ecbb70171c921f2a | |
| parent | 1de76958abc8f3dbfad07d142bd290dc53d7427a [diff] |
Upgrade from [6-year-old](https://repo1.maven.org/maven2/com/google/protobuf/protobuf-lite/3.0.1/) `protobuf-lite` to its modern equivalent, `protobuf-javalite`. This change should mostly not be user-visible, since we [declare this dependency as `optional`](https://github.com/google/truth/blob/1de76958abc8f3dbfad07d142bd290dc53d7427a/extensions/liteproto/pom.xml#L43). The new version doesn't support the `optimize_for = LITE_RUNTIME` option in `.proto` files, presumably on the theory that you should be able to compile the same protobuf for both the "lite" and "speed" runtimes. Unfortunately, xolstice/protobuf-maven-plugin does not provide a way to pass the `lite` option to the protobuf compiler. (That option was added in https://github.com/xolstice/protobuf-maven-plugin/commit/3ae165e5f6b33f8a6221ece11cc79a7df5eeb8df, but that is not yet part of [a release](https://github.com/xolstice/protobuf-maven-plugin/tags). And the project doesn't appear very active lately.) So we can't generate the Java protobuf classes with that plugin. Maybe there's another plugin we could use, if only one that runs an arbitrary executable? But for now, I'm taking another approach: I'm submitting the generated sources. To generate them, I ran `mvn clean install -X -e`, found the location of the protobuf executable and arguments in the output, and ran it with `--java_out=lite:/the/path/from/the/output`. Then I tweaked the Maven setup to build those sources instead of generating and building the protobuf ones. Yuck. This could cause someone some frustration down the line when it comes time to make a change to the test protos. But given that we haven't had to change those protos yet in their 6+ years of existence, I'm hoping for the best. Another alternative for us to consider is to just not run these specific tests in our open-source build. RELNOTES=n/a PiperOrigin-RevId: 486951466
Truth makes your test assertions and failure messages more readable. Similar to AssertJ, it natively supports many JDK and Guava types, and it is extensible to others.
Truth is owned and maintained by the Guava team. It is used in the majority of the tests in Google’s own codebase.
Read more at the main website.