Feature Request: support Java protoc plugins and allow specifying main class

[edenman]

We have an existing codegen plugin for protobuf that is invoked in a maven build thusly:

          <protocPlugins>
            <protocPlugin>
              <id>foo-protobuf</id>
              <groupId>com.foo.protobuf</groupId>
              <artifactId>foo-protobuf-plugin</artifactId>
              <version>HEAD-SNAPSHOT</version>
              <mainClass>com.foo.protobuf.compiler.plugin.PluginMain</mainClass>
            </protocPlugin>
          </protocPlugins>

If I try to add this same plugin the way this project specifies that plugins should be added:

plugins {
    foo {
      artifact = 'com.foo.protobuf:foo-protobuf-plugin:HEAD-SNAPSHOT'
    }

The build fails (target protobufToolsLocator_foo) because it's trying to download an executable artifact foo-protobuf-plugin-osx-x86_64.exe which doesn't exist (the artifact is actually foo-protobuf-plugin-HEAD-SNAPSHOT.jar).

I think I can work around this by creating a local executable that downloads the jar and runs it with the classname specified, but it would be rad if this library included this functionality.

[ejona86]

The hardest part of this seems to be "support Java protoc plugins." After that, it seems it would be easy to provide a way to override the mainClass (I assume because the JAR did not set one in its metadata).

It does seem that the plugin would have to generate a .sh or .bat file to be executed by protoc.

[zhangkun83]

So, if I don't find a .exe file in the artifact, but find a .jar file, I would assume it is a Java plugin. In that case, I would generate a .sh or .bat file to be executed by protoc.

I am not yet sure if .bat file works under windows, because the Maven protoc plugin makes use of winrun4j.

[ejona86]

Yeah, it might not; it may require calling cmd.exe, which would defeat the purpose. The Maven protoc plugin logic seems sane; mimicking it would be reasonable.

[edenman]

FWIW, the "specify main method" thing isn't actually important to me, I realized the jar is actually executable already. Main thing is to just support .jar plugins. My current workaround:

#!/bin/sh
curl https://my-maven-server.com/content/groups/public/com/mycompany/protobuf/protobuf-plugin/1.3/protobuf-plugin-1.3-shaded.jar > protobuf-plugin-1.3-shaded.jar
java -jar protobuf-plugin-1.3-shaded.jar
rm protobuf-plugin-1.3-shaded.jar

[noel-yap]

From https://github.com/google/protobuf-gradle-plugin/blob/master/src/main/groovy/com/google/protobuf/gradle/ToolsLocator.groovy#L84, it looks to me that all that's needed is for some way to override the classifier and extension fields. This solution would also be generic in that the codegen plugin can be implemented in any language. Those wanting to use Java would then follow something like http://en.newinstance.it/2012/04/17/self-executing-jar-files/ to build the executable.

[noel-yap]

@zhangkun83 , I'd like to implement the above PR. One issue is that if we stick with the Gradle syntax described in https://docs.gradle.org/3.3/userguide/dependency_management.html#sub:classifiers, it would break backwards compatibility since existing users will have to start specifying explicitly the classifier part as ${os.detector.classifier} and the extension as exe.

One alternative is to create some other syntax (perhaps a field indicating the classifier and extension).

My personal preference would be to break backwards compatibility now while the version of the plugin is 0.+ rather than to introduce syntax that's inconsistent with the rest of Gradle. What do you think?

[noel-yap]

Actually, I see a way to maintain backwards compatibility -- developers of the codegen plugin publish with a classifier (eg jvm8) and the extension can still default to exe. When resolving the codegen plugin dependency, if a classifier isn't specified, it'll still default to using os.detector.classifier.

[wwadge]

If you're looking at a somewhat complete example, you might wish to have a look here: https://github.com/Xorlev/grpc-jersey/blob/master/build.gradle