New armeria release 1.31.0 contains dependency on protobuf-java 4.28.2 #5990
Comments
|
If protobuf4 was included, it's unintentional 😅 Let me check and release a patch version. Thanks for the report! |
|
we ran into this also: open-telemetry/opentelemetry-java-contrib#1550 (comment) |
|
For context, protobuf-jackson supports both v3 and v4 while declaring a dependency on the latest version of protobuf when releasing as I think is standard for Java libraries. Perhaps protobuf is too weird to apply standard norms too... One note is that my understanding was the complete breakage in v4 was resolved protocolbuffers/protobuf#17247 I wonder if that just leaves potentially small parts of Armeria left that may need fixing for compatibility. That being said, grpc-java hasn't updated yet which is a good sign. Let me know if it seems the practical approach is to sticking to a v3 dependency in protobuf-jackson for now (some work to wire v4 into the CI in that case, Google loves to cause us extra work :P). |
|
I quickly tested our project with the latest v4 and it just breaks everything... Even though code changes are not very complex (to fix compilation errors), runtime behaviour was broken. In our projects we use other components that are dependent on protobuf v3 serialization (Temporal) - and that simply didn't work with mixed v3/v4. So it would be very good to keep using protobuf-java v3 in armeria as long as grpc-java itself is doing the same :-) |
Motivation: With the recent release of 1.31.0, we received a report that protobuf 4 has been included as an api dependency. This is probably a mistake since 1) the community isn't ready for protobuf 4 2) it's usually safer to follow the protobuf version used by `grpc-java`. The `api` configuration is a consumable configuration, which means it is difficult to detect these kind of issues directly. However, by checking the runtime dependencies for tests we can infer whether a version is inadvertently bumped. In order to detect such mishaps, I also propose that a `failOnVersionConflict` variant is added. Because naively introducing `failOnVersionConflict` introduces many conflicts, I've added a variant which checks for specified dependencies only. (inspired by gradle/gradle#8813) One limitation is that the `dependencies` task is not available when a `failOnVersionConflict` occurs. For this reason, once a failure due to a conflict occurs, it is encouraged to use the `-PdebugDeps` flag with the `dependencies` task. e.g. ``` ./gradlew :grpc:dependencies -PdebugDeps ``` Modifications: - Excluded the `protobuf-java` dependency from `protobuf-jackson` - Added a `failOnVersionConflict` method which checks version conflicts for specific dependencies only Result: - Closes #5990 <!-- Visit this URL to learn more about how to write a pull request description: https://armeria.dev/community/developer-guide#how-to-write-pull-request-description -->
Looks like this 4.28.2 comes from the updated protobuf-jackson.
Basically this new version breaks everything protobuf-related - as 4.x is not compatible with 3.x
The text was updated successfully, but these errors were encountered: