Gradle dsl to specify the mainClass for protocPlugin #738
Conversation
|
Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA). View this failed invocation of the CLA check for more information. For the most up to date status, view the checks section at the bottom of the pull request. |
| @@ -104,8 +105,8 @@ class ToolsLocator { | |||
| group:groupId, | |||
| name:artifact, | |||
| version:version, | |||
| classifier:classifier ?: osdetector.classifier, | |||
| ext:extension ?: 'exe', | |||
| classifier:classifier ?: mainClass ? null : osdetector.classifier, | |||
There was a problem hiding this comment.
mainClass should virtually never be specified. In your specific case for dubbo it makes some sense, as the JAR has multiple generators inside. But the recommendation is "the JAR should be stand-alone, with main-class specified in the meta-inf". So I doubt we want these two lines of convenience, as it creates a perverse incentive.
There was a problem hiding this comment.
If mainClass can be specified, it will be more convenient to use.
There was a problem hiding this comment.
I am currently in urgent need of this feature. Without it, I may need to maintain multiple jars separately to complete it, and others may also need to find other ways to solve this problem
There was a problem hiding this comment.
I do not want to encourage mainClass; most cases there should only be a single class. Allowing alternative classes and encouraging never having Main-Class in the jar are two very different things.
There was a problem hiding this comment.
How should I specify classifier as null
There was a problem hiding this comment.
I used translation software which may not convey the message accurately.
There was a problem hiding this comment.
The problem isn't limited to "allowing alternative classes to be the main class." The problem you're seeing looks to impact all usages of jars. My point here is I don't want behavior tied to overriding the main class. Whatever solution here is needed should also be available when using the main-class from inside the jar.
Taking a look at ServiceTalk, it looks like they are just specifying a classifier (io.servicetalk:servicetalk-grpc-protoc:$serviceTalkVersion:all@jar). They were the ones that added jar support to the plugin, so I guess they just didn't need null classifier. Since the gradle shadow plugin does encourage you to publish both "jar without dependencies" and the fat jar, I guess that makes some sense.
Do you only need dubbo-compiler support? It looks like their jar doesn't include dependencies, so I don't think the null classifier would have worked. I'm impressed that Dubbo has gone out of their way to make the exe's.
There was a problem hiding this comment.
If I want to use a jar, but this jar does not have a classifier, it will be forced to specify a classifier by osdetector.classifier. In fact, many jars do not have a classifier. In this case, ar cannot be selected at all.
classifier:classifier ?: mainClass ? null : osdetector.classifier,
Actually, I want jars that do not need classifier to not be overwritten by osdetector.classifier
There was a problem hiding this comment.
I understand theoretically wanting a null classifier. But specifically for dubbo-compiler it seems to be pointless, as dubbo-compiler isn't a fat jar. What plugin are you wanting to use here? Is it dubbo-compiler, or something else?
There was a problem hiding this comment.
Yes, I want to use dubbo compiler. I have recompiled a complete jar in my private library
src/main/groovy/com/google/protobuf/gradle/GenerateProtoTask.groovy
Outdated
Show resolved
Hide resolved
| @@ -184,6 +184,11 @@ protobuf { | |||
| // or | |||
| // path = 'tools/protoc-gen-grpc-java' | |||
| } | |||
| dubbo { | |||
| artifact = "org.apache.dubbo:dubbo-compiler:${dubboVersion}" | |||
There was a problem hiding this comment.
Since this doesn't actually work for other people, I don't think it makes sense as an example. Looks like we don't have an example already for jar files? Oh, well. servicetalk might be a fair example if we were searching for one.
I have successfully verified it locally. How can I solve this problem |
#455 Solve this problem
I encountered this issue when using dubbo generation