support ScalaPB package/file-level customization

[bjaglin]

See https://scalapb.github.io/docs/customizations

On master, code won't compile if package/file-level options are used to change flat_package as only ScalaPB honors the request.

[akka-ci]

Thank you for your pull request! After a quick sanity check one of the team will reply with 'OK ΤO ΤESΤ' to kick off our automated validation on Jenkins. This compiles the project, runs the tests, and checks for things like binary compatibility and source code formatting. When two team members have also manually reviewed and (perhaps after asking for some amendments) accepted your contribution, it should be good to be merged.

For more details about our contributing process, check out CONTRIBUTING.md - and feel free to ask!

[raboof]

OK TO TEST

[raboof]

On master, code won't compile if package/file-level options are used to change flat_package as only ScalaPB honors the request.

Indeed the Akka gRPC code generation currently only allows changing flat_package as a 'build-wide' wide option. I think we would definitely want to update the Akka gRPC code generation to take into account package/file-level customizations, but this feature is already useful without it.

[bjaglin]

just force-pushed as I had forgotten this...

[ignasi35]

Nice that we're getting this.

(discussion for a separate PR/issue): I wonder if should eventually deprecate and remove the use of flat_package out of the box. We would then fallback to scalapb's behavior and transparently use the options available there.

[bjaglin]

I wonder if should eventually deprecate and remove the use of flat_package out of the box. We would then fallback to scalapb's behavior and transparently use the options available there.

I am not sure it will be required. ScalaPB has promising upcoming changes that will make consumption of JAR-packaged Scala stubs compiled with different options than the generator ones used for the local project seamless.

See scalapb/scalapb-validate#70 & scalapb/ScalaPB#873 for related discussions.

[ignasi35]

The motivation of my comment was to eventually remove from akka-gRPC any access to scalaPB settings since those scalaPB settings are already available via options in the .proto file.

So users no longer need to specify akkaGrpcCodeGeneratorSettings := akkaGrpcCodeGeneratorSettings.value.filterNot(_ == "flat_package") and, instead, use plain scalapb syntax on the .proto file.

Again, I'd rather discuss these further improvements on a separate issue/PR since I'm sure there'll be use cases that require more attention.

[raboof]

Great! Would love to take into account the flat_package option better in the Akka gRPC codegen side but that's for another PR, this is already a great improvement.