Skip to content
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

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

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

copybara-service[bot]
Copy link
Contributor

Upgrade from 6-year-old protobuf-lite to 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_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. 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

…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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant