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

add test that excludes generating source for google protos #380

Open
pjfanning opened this issue Oct 2, 2024 · 2 comments
Open

add test that excludes generating source for google protos #380

pjfanning opened this issue Oct 2, 2024 · 2 comments

Comments

@pjfanning
Copy link
Contributor

pjfanning commented Oct 2, 2024

based on scalapb/ScalaPB#1746 and #371

One of the issues in #371 is that the sbt build for plugin-tester-scala started failing. It was a real issue and I have submitted a fix to ScalaPB. The thing is though: one of the protos we are testing imports a Google Timestamp proto. There is no need to generate classes for the Google Timestamp proto because protobuf-java jar has a class already that represents this data type. What we end up with in our integration test is that we generate a Scala class for this Timestamp type and other Google types. These classes will clash with the protobuf-java classes. The classes should have the same methods but these days, Java is trying to get us to stop splitting packages across jars for security reasons (eg JSR 376).

It would be good to see if we can successfully get ScalaPB not to generate these Google classes. See scalapb/ScalaPB#1746 (comment)

@raboof
Copy link
Member

raboof commented Oct 3, 2024

What we end up with in our integration test is that we generate a Scala class for this Timestamp type and other Google types. These classes will clash with the protobuf-java classes. The classes should have the same methods

Are you sure? IIRC the Scala classes are typically different (as they have Scala stuff), and by default are generated into a slightly different package (one level of depth deeper or shallower, IIRC).

They could be in scalapb-runtime though, in which case it'd still make sense to avoid generating them and add that dependency instead.

Java is trying to get us to stop splitting packages across jars for security reasons (eg JSR 376).

Yeah that might become a challenge

It would be good to see if we can successfully get ScalaPB not to generate these Google classes. See scalapb/ScalaPB#1746 (comment)

👍

@vermas7988
Copy link

in application projects it works as mentioned in scalaPB docs: scalaPB docs.
e.g.

libraryDependencies ++= Seq(
  "com.somepackage" %% "that-has-jar" % "1.0" % "protobuf-src" intransitive(),
  // then manually importing the common google dependencies separately
  "com.thesamet.scalapb.common-protos" %% "proto-google-common-protos-scalapb_0.11" % "2.9.6-0" % "protobuf",
  "com.thesamet.scalapb.common-protos" %% "proto-google-common-protos-scalapb_0.11" % "2.9.6-0"
)

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

No branches or pull requests

3 participants