-
-
Notifications
You must be signed in to change notification settings - Fork 285
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
issue where generated code has a ref to Option
as opposed to _root_.scala.Option
#1746
Comments
I am not an expert on this code base but I suspect the issue is here: ScalaPB/compiler-plugin/src/main/scala/scalapb/compiler/ProtobufGenerator.scala Line 1412 in c4a3b85
|
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:
https://github.com/scalapb/ScalaPB/blob/c4a3b85df27ecc926b4d102a0f9a593b4676e68d/compiler-plugin/src/main/scala/scalapb/compiler/ProtobufGenerator.scala#L1412
—
Reply to this email directly, view it on GitHub
<#1746 (comment)>,
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. 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. 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. |
See |
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 class
com.google.protobuf.Option
,You can see the issue at:
ScalaPB/docs/src/main/scala/generated/com/thesamet/docs/json/MyContainer.scala
Line 42 in c4a3b85
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).The text was updated successfully, but these errors were encountered: