Gradle dsl to specify the mainClass for protocPlugin

[016K]

#455 Solve this problem

I encountered this issue when using dubbo generation

[google-cla]

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.

[ejona86]

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.

[016K]

If mainClass can be specified, it will be more convenient to use.

[016K]

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

[ejona86]

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.

[016K]

How should I specify classifier as null

[016K]

I used translation software which may not convey the message accurately.

[ejona86]

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.

[016K]

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

[ejona86]

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?

[016K]

Yes, I want to use dubbo compiler. I have recompiled a complete jar in my private library

[ejona86]

The code looks fine. Just need to iron out the README. Either an example that uses a fat jar or just don't update the README.

[ejona86]

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.

[016K]

I have successfully verified it locally. How can I solve this problem