Add support for custom protoc java plugin arguments

[efenglu]

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]

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

[marcoferrer]

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

[sergei-ivanov]

@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]

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]

@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]

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]

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]

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]

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]

+1, upvote

[sahendrickson]

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