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

Jump to bottom

Duplicate folder for Java packages #650

Closed
fabiannagel opened this issue Jul 29, 2015 · 0 comments
Closed

Duplicate folder for Java packages #650

fabiannagel opened this issue Jul 29, 2015 · 0 comments
Labels
java question

Comments

@fabiannagel
Copy link

I have the following project structure (Java):

  • project_root
    • lib
    • src
      • foo_package_1
      • foo_package_2
      • ValidationService
        • proto
        • ValidationService.java

Inside my proto files, I used option java_package = "ValidationService.proto" to specify that I want the generated classes to be placed inside the proto package, but protoc creates another folder/package inside ValidationService. This results in the following constellation:

  • project_root
    • lib
    • src
      • foo_package_1
      • foo_package_2
      • ValidationService
        • ValidationService
          • proto
            • ValidationRequest.java
        • ValidationService.java

Furthermore, the package inside ValidationRequest.java is untruly set to ValidationService.proto, so this doesn't even represent the real project structure. If I restrict the java_package option to proto, the classes are placed accurately inside the proto folder, but the package description inside the source code is wrong again (since it only refers to package proto; instead of package ValidationService.proto;).

If this is a bug and not just my inability to use the java_package option correctly, I would suggest more control for the user to specify path and package separately by using more than one parameter.

Regards
@xfxyjwf xfxyjwf closed this as completed Mar 7, 2017
taoso pushed a commit to taoso/protobuf that referenced this issue Aug 1, 2018
@dsnet
proto: fix and cleanup test for deterministic marshal with custom mar…
427e165 
…shalers (protocolbuffers#656)

PR protocolbuffers#650 added a check to error out when a custom marshaler was called and
deterministic marshaling was also specified.

That change performed the check in a relatively obscure location that did not
catch all code paths. Since determinism can only be enabled on the Buffer type,
we check it up front in Buffer.Marshal.

Also, change the test to avoid code injection into generated sources.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
java question
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@fabiannagel @xfxyjwf