Protobuf 3.25.5 support for Quarkus Compatibility

[umutsahin]

Hi there,

First of all I must say I just did a PoC with Valkey Cluster (bitnami chart) with Jedis forked client and results look amazing.
I was wondering to test valkey-glide and its features well with quarkus, but I am not able to use it due to version incompatibility since quarkus using 3.25.5 right now.

I was thinking if I would be able to compile glide with libprotoc 25.5 so that I would be able to test it.
But I am not able to build it successfully so far. Can you guide me even if I am able to compile it, will it be possible to use the client ?

Thanks!

[barshaul]

@Yury-Fridlyand @yipin-chen @jonathanl-bq
Can you please give your input here?
Since it seems to be a recurrent issue, is there a different workaround here to to resolve these kind of conflicts in Java? I found shading (maven-shade-plugin/com.github.johnrengelman.shadow) or a custom ClassLoader as options, do you have any insights here? shadowing the dependency name sounds like it can be a valid option, do you have any experience with it?

[yipin-chen]

The reason for using protoc version v26.0 or above is that older versions of protobuf were missing the Automatic-Module-Name entry (see protocolbuffers/protobuf#12639). This is why we made the changes in PR #1237 to define the minimum supported versions for all wrappers.

[avifenesh]

@yipin-chen we have issues with the strict netty and protobuf dependencies a lot.
Why can't we utilize Maven an Gradle shadow plugins to resolve it within our own jar?
Its blocking many users and solving it should be a top priority.
@Yury-Fridlyand @jonathanl-bq please give your input.

@asafpamzn - please lets give the JAR hell priority, and find a solution, we can't be so limited, its recurring constantly.

[Yury-Fridlyand]

Shadowing jars is a working solution. We need to make a decision which dependencies to be shadowed, and how that package will be released.

[avifenesh]

netty and protobuff are clear ones.