-
Notifications
You must be signed in to change notification settings - Fork 78
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 support for custom protoc java plugin arguments #56
Comments
Can you please point me to the examples/documentation of additional parameters for java plugin? |
I author a plugin that’s affected by this. Details documented in this issue, including an example configuration marcoferrer/kroto-plus#28 |
@marcoferrer thanks for describing the use case, it's exactly what I was looking for. I think your case is further complicated by the fact (correct me if I am wrong) that your plugin is not standalone, but rather works alongside Java plugin to inject extra code into the generated classes. While I still have a long term plan to refactor What I can do though is to push the optional plugin parameter into the base class, so that all plugin outputs can use it. The next release will be full of breaking changes, so it's probably a good time to roll this change in as well. |
This will work for me. I was also experimenting with the other Google Java protoc command line arguments, like adding @generated to class files. I also am developing a plug-in that I would like to control the behavior of from the pom file and not the proto file. |
@sergei-ivanov An issue I saw in the gradle plugin repo reminded me of this issue. I remember you mentioned that you had plans to refactor this plugin to use a single protoc invocation. It looks like that might cause a breaking change for existing maven users. Details outlined here Just wanted to give a heads up |
I concur with @ejona86: the case described in google/protobuf-gradle-plugin#306 looks more like an abuse of a legacy feature than a genuine problem. Having two identically named protobuf messages in the same protobuf namespace is definitely an invalid case, and |
I agree. It would be worth noting in the release of the refactor that users experiencing compilation errors need to review their proto definitions for duplicate message names. |
I would also be interested to see |
Any progress on this? Not sure if its being actively worked on but the 0.7 release has been on hold for a year or so>? |
+1, upvote |
I'd like to have the ability to include the --fatal_warnings argument. |
Is your feature request related to a problem? Please describe.
There are features of the java plugin that are not exposed as .proto options. I was like to be able to use them
Describe the solution you'd like
The custom plugin execution already supports this. Simply add the element:
<pluginParameter>
Describe alternatives you've considered
Adding a custom option to proto would require changes to the proto syntax.
The text was updated successfully, but these errors were encountered: