You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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)
The text was updated successfully, but these errors were encountered:
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)
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"
)
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)
The text was updated successfully, but these errors were encountered: