当类路径太长时,Java 无法启动。 Windows 上的长度限制特别短。
Gradle 似乎对自己解决这个问题不感兴趣(尽管这是他们的责任,因为他们是启动 Java 的人),所以我们最终用我们自己的任务替换了 JavaExec
任务替代方案。
替代方案是这样的:
public class WorkingJavaExec extends JavaExec {
private static final String MATCH_CHUNKS_OF_70_CHARACTERS =
"(?<=\\G.{70})";
private final Logger logger = LoggerFactory.getLogger(getClass());
@Override
public void exec() {
FileCollection oldClasspath = getClasspath();
File jarFile = null;
try {
if (!oldClasspath.isEmpty()) {
try {
jarFile =
toJarWithClasspath(oldClasspath.getFiles());
setClasspath(getProject().files(jarFile));
} catch (IOException e) {
throw new UncheckedIOException(e);
}
}
super.exec();
} finally {
setClasspath(oldClasspath);
if (jarFile != null) {
try {
Files.delete(jarFile.toPath());
} catch (Exception e) {
logger.warn("Couldn't delete: " + jarFile, e);
}
}
}
}
public static File toJarWithClasspath(Set<File> files)
throws IOException {
File jarFile = File.createTempFile("long-classpath", ".jar");
try (ZipOutputStream zip =
new ZipOutputStream(new FileOutputStream(jarFile))) {
zip.putNextEntry(new ZipEntry("META-INF/MANIFEST.MF"));
try (PrintWriter writer =
new PrintWriter(
new OutputStreamWriter(
zip, StandardCharsets.UTF_8))) {
writer.println("Manifest-Version: 1.0");
String classPath = files.stream().map(
file -> file.toURI().toString())
.collect(Collectors.joining(" "));
String classPathEntry = "Class-Path: " + classPath;
writer.println(Arrays.stream(
classPathEntry.split(MATCH_CHUNKS_OF_70_CHARACTERS))
.collect(Collectors.joining("\n ")));
}
}
return jarFile;
}
}
不过,使用它很麻烦,因为有人可能会在任何地方运行 JavaExec
,我必须将其替换为 WorkingJavaExec
。新开发人员也不知道 Gradle 中存在这个陷阱,所以他们甚至不知道这是他们必须解决的问题。
在阅读 Gradle 的内部结构时,我看到 JavaExec
在内部使用 JavaExecAction
来执行实际的执行。
我想也许通过替换它,我们可以解决这个问题,就好像 Gradle 自己解决了它一样,也许它也适用于其他任务,例如 Test
。但我无法在任何地方找到任何例子。 (即使在其他大型项目中,您也会遇到同样的问题!)
是否可以替换 JavaExecAction
,如果可以,如何替换?
最佳答案
我不确定您是否可以“替换”JavaExecAction
,因为它是在 JavaExec 任务实例化期间设置的,但我认为您可以使用自定义 Plugin 以更好的方式解决此问题如下:
class FixClasspathLimitPlugin implements Plugin<Project> {
@Override
void apply(Project project) {
// after project has been evaluated, hack into all tasks of type JavaExec declared.
project.afterEvaluate {
project.tasks.stream().filter { task -> task instanceof JavaExec }.forEach {
println "Reconfiguring classpath for : $it"
JavaExec javaExec = (JavaExec) it;
FileCollection oldClasspath = javaExec.getClasspath()
// insert an Action at first position, that will change classpath
javaExec.doFirst { task ->
((JavaExec) task).setClasspath(getProject().files(toJarWithClasspath(oldClasspath.getFiles())));
}
// optional - reset old classpath
javaExec.doLast { task ->
((JavaExec) task).setClasspath(oldClasspath)
}
}
}
}
public static File toJarWithClasspath(Set<File> files)
throws Exception {
// same method implementation as given in your question
}
这样,您就不必在您的团队编写的所有构建脚本中替换 JavaExec,您只需确保这些脚本应用您的插件即可。
如果您使用 Gradle 的自定义发行版并在您的企业中使用 wrapper,您甚至可以将此插件作为 Init 脚本包含在此发行版中,如下所述:https://docs.gradle.org/current/userguide/init_scripts.html#sec:using_an_init_script
Put a file that ends with .gradle in the GRADLE_HOME/init.d/ directory, in the Gradle distribution. This allows you to package up a custom Gradle distribution containing some custom build logic and plugins. You can combine this with the Gradle wrapper as a way to make custom logic available to all builds in your enterprise.
这样,插件将以“透明”的方式应用。
关于 Test
任务:我认为它不使用 JavaExecAction
,但可以应用类似的解决方案,使用类似的插件。
关于java - 是否可以换掉 Gradle 用来运行 Java 的 JavaExecAction?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/51238309/