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.
#1039
+2,350
−12
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
![copybara-service[bot]](https://avatars.githubusercontent.com/in/44061?s=60&v=4){kind=small}
…rotobuf/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 xolstice/protobuf-maven-plugin@3ae165e, 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
copybara-service
bot
force-pushed
the
test_486951466
branch
from
fd53ec5
to
72bef10
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Upgrade from 6-year-old
protobuf-liteto its modern equivalent,protobuf-javalite.This change should mostly not be user-visible, since we declare this dependency as
optional.The new version doesn't support the
optimize_for = LITE_RUNTIMEoption in.protofiles, 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 theliteoption to the protobuf compiler. (That option was added in xolstice/protobuf-maven-plugin@3ae165e, but that is not yet part of a release. 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