# Classpath too long using JavaExec on Windows

**URL:** <https://discuss.gradle.org/t/classpath-too-long-using-javaexec-on-windows/28000>\
**Category:** Help/Discuss\
**Created:** [August 2, 2018, 10:21pm UTC](https://discuss.gradle.org/t/classpath-too-long-using-javaexec-on-windows/28000 "2018-08-02T22:21:24Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![quintonm](https://sea1.discourse-cdn.com/gradle/user_avatar/discuss.gradle.org/quintonm/32/7113_2.png) [@quintonm](https://discuss.gradle.org/u/quintonm)\
**Post date:** [August 2, 2018, 10:21pm UTC](https://discuss.gradle.org/t/classpath-too-long-using-javaexec-on-windows/28000/1 "2018-08-02T22:21:25Z")

</div>

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](https://discuss.gradle.org/t/problem-with-running-application-classpath-too-big/7600). 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?