Classpath too long using JavaExec on Windows


(Quinton McCombs) #1

I am running into a problem with the classpath being too long on Windows when using JavaExec. The solution that has been working was to create a classpath jar as described in this post. However, that stops working when the java-library plugin is applied.

The problem seems to come the fact that configurations.runtimeClasspath.collect { it.absolutePath } returns references to the JAR files that would be produced from project dependencies. Without the java-library plugin applied, the jar tasks for each of the dependent projects are added to the task graph. With the java-plugin applied, that no longer happens.

Task to create the classpath jar: (in moduleB)
task classpathJar(type: Jar) {
archiveName = “${project.name}-classpath.jar”
doFirst {
manifest {
attributes “Class-Path”: files(configurations.runtimeClasspath).collect { name ->
name.toURI()
}.join(" ")
}
}
}

JavaExec task in moduleB:
task runWebapp(dependsOn: [classpathJar, testClasses], type: JavaExec) {
classpath = files(classpathJar.archivePath, sourceSets.main.java.outputDir)
main ‘com.mycompany.AppConfigurator’
}

moduleB has a dependency on moduleA.

In the jar produced by the classpathJar task, the manifest has the following entries for the classpath (most omitted):
file:/Users/quinton/dev/project/moduleB/build/classes/java/main/
file:/Users/quinton/dev/project/moduleB/build/resources/main/
file:/Users/quinton/dev/project/moduleA/build/libs/moduleA-1.jar

With the java-library plugin applied, the jar file for moduleA is not built. This causes the JavaExec task to fail because com.mycompany.AppConfigurator is not found on the classpath.

I think one solution would be to write the output directories to the manifest instead of the jars. I am just not sure how to get all of the output directories for the dependent modules (there are approx 12 and they are nested). I am just not sure how to do that or if that is even the correct approach.

Any ideas?