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?