Investigate allowing optional `package` parameters when parsing Protobuf schema about skeuomorph HOT 7 CLOSED

@dmarticus, to add some clarity, my problems with the package option are:

• It is mandatory for skeuomorph to function, but not for protoc.
• It influences where the resulting files will be generated. While there are workarounds around this, I am inclined to believe it should have only "semantic" meaning, i.e. how services should be referenced.

As for a real-world example, my original .proto files do not have the package option and I cannot really change them as they are used across multiple teams. But even adding the package option is kind of fruitless without the muSrcGenIdiomaticEndpoints as clients generated by protoc will not be able to reference the service without the package prefix.

from skeuomorph.

@a7emenov we should be releasing this change this week! Thanks for your help in providing the context around it and I hope you find the changes helpful :)

from skeuomorph.

@a7emenov do you have an example protobuf file that I could work with that you'd like to be able to use with mu and skeuomorph? I'm planning on implementing this behavior this week and I'd love to have a file that you want to be able to convert to use as a test case

from skeuomorph.

@dmarticus, sure, thank you so much for a swift response.

Example 1:

• File:

  syntax = "proto3";
  option java_package = "my_package";
  
  service MyService {
    rpc Check(MyRequest) returns (MyResponse);
  }
  
  message MyRequest {
    string value = 1;
  }
  
  message MyResponse {
    string value = 1;
  }
  

• Expected:
  MyService service will be generated under "my_package" package.

• Actual:
  Service generation fails as the package option is not provided.

Example 2:

• File:

  syntax = "proto3";
  package other_package;
  
  option java_package = "my_package";
  
  service MyService {
    rpc Check(MyRequest) returns (MyResponse);
  }
  
  message MyRequest {
    string value = 1;
  }
  
  message MyResponse {
    string value = 1;
  }
  

• Expected:
  MyService service will be generated under "my_package" package.

• Actual:
  MyService service is generated under "other_package" package.

from skeuomorph.

Thank you for sharing! These will be some great test cases for my implementation; I appreciate it!

from skeuomorph.

@dmarticus, I can't properly express how much this helps! Much obliged for acting so swiftly, this basically allows to keep using mu in the project. Looking forward to the release!

from skeuomorph.

@a7emenov my pleasure! It's great to have users who push the envelope of what we've made and identify gaps, so I appreciate you for that. The release went out today (https://gitter.im/47deg/mu?at=5f4d6fa5dfaaed4ef521757a), and I'll publish the changes to sbt-mu-srcgen shortly.

from skeuomorph.