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

Add support for custom protoc java plugin arguments #56

Open
efenglu opened this issue Feb 21, 2019 · 11 comments
Open

Add support for custom protoc java plugin arguments #56

efenglu opened this issue Feb 21, 2019 · 11 comments
Assignees
Milestone

Comments

@efenglu
Copy link

efenglu commented Feb 21, 2019

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.

@sergei-ivanov sergei-ivanov self-assigned this Feb 24, 2019
@sergei-ivanov sergei-ivanov added this to the 0.7 milestone Feb 24, 2019
@sergei-ivanov
Copy link
Member

Can you please point me to the examples/documentation of additional parameters for java plugin?

@marcoferrer
Copy link

I author a plugin that’s affected by this. Details documented in this issue, including an example configuration marcoferrer/kroto-plus#28

@sergei-ivanov
Copy link
Member

@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 protobuf-maven-plugin configuration in a similar way to how gradle plugin works (multiple outputs, single execution), it is not something I am planning for the nearest future.

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.

@efenglu
Copy link
Author

efenglu commented Mar 1, 2019

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.

@marcoferrer
Copy link

@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

@sergei-ivanov
Copy link
Member

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 protoc is entirely correct to complain about it.

@marcoferrer
Copy link

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.

@thesamet
Copy link

I would also be interested to see pluginParameter being supported for custom java plugins. I am the author of ScalaPB which includes a protobuf plugin that generates Scala code and is written in Scala. The plugin supports multiple options that users can pass through protoc. We recommend using this plugin for maven users, and they frequently need to pass additional options and we're hitting this limitation. See for example: https://gitter.im/ScalaPB/community?at=5ddf7d50d64a052fb67918c9

@jeffzoch
Copy link

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>?

@artie-shevchenko
Copy link

+1, upvote

@sahendrickson
Copy link

I'd like to have the ability to include the --fatal_warnings argument.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

7 participants