Feature Request: support Java protoc plugins and allow specifying main class about protobuf-gradle-plugin HOT 8 CLOSED

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.

from protobuf-gradle-plugin.

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.

from protobuf-gradle-plugin.

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.

from protobuf-gradle-plugin.

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

from protobuf-gradle-plugin.

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.

from protobuf-gradle-plugin.

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

from protobuf-gradle-plugin.

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.

from protobuf-gradle-plugin.

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

from protobuf-gradle-plugin.