Open pjfanning opened 1 day ago
I am not an expert on this code base but I suspect the issue is here:
The PR seem fine, will try it out locally later today. However, it does seem problematic that Pekko is trying to generate code directly into com.google.protobuf, since this is likely to result in conflicts with classes that are provided by protobuf-java. The classes that are being generated should be shipped by scalapb-runtime. Can you figure out why this is happening?
On Tue, Oct 1, 2024 at 10:44 AM PJ Fanning @.***> wrote:
I am not an expert on this code base but I suspect the issue is here:
— Reply to this email directly, view it on GitHub https://github.com/scalapb/ScalaPB/issues/1746#issuecomment-2386598229, or unsubscribe https://github.com/notifications/unsubscribe-auth/AACLBLIYGTG5664QTCQ27HLZZLNOPAVCNFSM6AAAAABPGCKKBKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGOBWGU4TQMRSHE . You are receiving this because you are subscribed to this thread.Message ID: @.***>
-- -Nadav
The story with Pekko gRPC is that Lightbend changed their license for Akka and a new set of developers have forked Pekko to keep an OSS alternative. We don't know everything about why the builds and features are all there.
There are a few build issues in Pekko gRPC when I upgrade to protobuf 4 and ScalaPB 1.0.0.alpha1 and this issue is 1 of them.
The issue happens in an integration test as opposed to happening in the main runtime modules. The integration test builds some code based on some test proto files. One of these proto files imports "google/protobuf/timestamp.proto" to use a type defined in this proto.
With protobuf 3, we end up with lots of generated source files because the Google timestamp.proto has its own dependencies. The classes are all generated into com.google.protobuf package. Interestingly, we don't get the problematic class that I posted in the description.
I'm guessing that timestamp.proto or one or more of its Google dependencies has changed in Protobuf 4 so that we end up with this additional source file (the one that exhibits the Option issue).
Also, the classes for these Google protos seem to be shipped in protobuf-java anyway so that we don't really need to be generating these class files - at least in theory.
This is the already compiled class that is causing my issue when Pekko gRPC tries to create its own Scala version of this. https://javadoc.io/doc/com.google.protobuf/protobuf-java/latest/com/google/protobuf/JavaFeaturesProto.JavaFeatures.html
It might be worth adding some feature to Pekko gRPC or ScalaPB to try to skip generating classes for Google protos. This feature would probably need some logic to check if the generated classes are needed by checking if the classpath already has a class with that Fully Qualified Class Name.
It might be worth adding some feature to Pekko gRPC or ScalaPB to try to skip generating classes for Google protos.
See excludeFilter
here: https://scalapb.github.io/docs/faq/#how-do-i-generate-scala-code-for-protos-from-another-jar
I'm having an issue with getting Pekko gRPC to work with ScalaPB 1.0.0.alpha1. The generated class at bottom of description has
_root_.scala.Option
in most places but has plainOption
in 2 places. This is an issue because there is a classcom.google.protobuf.Option
,You can see the issue at: https://github.com/scalapb/ScalaPB/blob/c4a3b85df27ecc926b4d102a0f9a593b4676e68d/docs/src/main/scala/generated/com/thesamet/docs/json/MyContainer.scala#L42
One instance in my class is
def withLegacyClosedEnum(__v: _root_.scala.Boolean): JavaFeatures = copy(legacyClosedEnum = Option(__v))
. Note the= Option(__v)
. The other instance is the same issue (just 3 lines later in the generated code).