Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Gradle dsl to specify the mainClass for protocPlugin #738

Open
wants to merge 6 commits into
base: master
Choose a base branch
from
Open
Show file tree
Hide file tree
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
5 changes: 5 additions & 0 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -184,6 +184,11 @@ protobuf {
     // or
     // path = 'tools/protoc-gen-grpc-java'
   }
dubbo {
artifact = "org.apache.dubbo:dubbo-compiler:${dubboVersion}"
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

// optional (jar main-class)
// mainClass = "org.apache.dubbo.gen.grpc.reactive.ReactorDubboGrpcGenerator"
}
// Any other plugins
...
 }
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -46,6 +46,7 @@ class ExecutableLocator implements Named {

private String artifact
private String path
private String mainClass;

private FileCollection artifactFiles
private String simplifiedArtifactName
Expand Down Expand Up @@ -84,6 +85,14 @@ class ExecutableLocator implements Named {
return path
}

String getMainClass() {
return mainClass
}

void setMainClass(String mainClass) {
this.mainClass = mainClass
}

@PackageScope
FileCollection getArtifactFiles() {
Preconditions.checkState(path == null, 'Not artifact based')
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -721,11 +721,11 @@ public abstract class GenerateProtoTask extends DefaultTask {

protected String computeExecutablePath(ExecutableLocator locator) {
if (locator.path != null) {
return locator.path.endsWith(JAR_SUFFIX) ? createJarTrampolineScript(locator.path) : locator.path
return locator.path.endsWith(JAR_SUFFIX) ? createJarTrampolineScript(locator.path, locator.mainClass) : locator.path
}
File file = locator.artifactFiles.singleFile
if (file.name.endsWith(JAR_SUFFIX)) {
return createJarTrampolineScript(file.getAbsolutePath())
return createJarTrampolineScript(file.getAbsolutePath(), locator.mainClass)
}

if (!file.canExecute() && !file.setExecutable(true)) {
Expand All @@ -742,7 +742,7 @@ public abstract class GenerateProtoTask extends DefaultTask {
* @param jarAbsolutePath Absolute path to the .jar file.
* @return The absolute path to the trampoline executable script.
*/
private String createJarTrampolineScript(String jarAbsolutePath) {
private String createJarTrampolineScript(String jarAbsolutePath, String mainClass) {
assert jarAbsolutePath.endsWith(JAR_SUFFIX)
boolean isWindows = isWindows()
String jarFileName = new File(jarAbsolutePath).getName()
Expand All @@ -758,8 +758,8 @@ public abstract class GenerateProtoTask extends DefaultTask {
// Rewrite the trampoline file unconditionally (even if it already exists) in case the dependency or versioning
// changes we don't need to detect the delta (and the file content is cheap to re-generate).
String trampoline = isWindows ?
"@ECHO OFF\r\n\"${escapePathWindows(javaExe)}\" -jar \"${escapePathWindows(jarAbsolutePath)}\" %*\r\n" :
"#!/bin/sh\nexec '${escapePathUnix(javaExe)}' -jar '${escapePathUnix(jarAbsolutePath)}' \"\$@\"\n"
"@ECHO OFF\r\n\"${escapePathWindows(javaExe)}\" ${mainClass ? "-cp" : "-jar"} \"${escapePathWindows(jarAbsolutePath)}\" ${mainClass} %*\r\n" :
ejona86 marked this conversation as resolved.
Show resolved Hide resolved
"#!/bin/sh\nexec '${escapePathUnix(javaExe)}' ${mainClass ? "-cp" : "-jar"} '${escapePathUnix(jarAbsolutePath)}' ${mainClass} \"\$@\"\n"
scriptExecutableFile.write(trampoline, US_ASCII.name())
setExecutableOrFail(scriptExecutableFile)
logger.info("Resolved artifact jar: ${jarAbsolutePath}. Created trampoline file: ${scriptExecutableFile}")
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -96,6 +96,7 @@ class ToolsLocator {
conf.visible = false
conf.transitive = false
}
def mainClass = locator.mainClass
String groupId, artifact, version, classifier, extension
OsDetector osdetector = project.extensions.getByName("osdetector") as OsDetector
List<String> parts = artifactParts(locator.artifact)
Expand All @@ -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,
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

image
image

How should I specify classifier as null

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

image
image
image
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

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

ext:extension ?: mainClass ? 'jar' : 'exe',
]
project.dependencies.add(config.name, notation)
locator.resolve(config, "$groupId:$artifact:$version".toString())
Expand Down
Loading