Using a wildcard in a JavaExec classpath with Gradle

Question

I have a side Gradle build that runs some tests on another old Ant build I have. That old ant build has a TON of libraries in it, and I want my Gradle build that runs test to have those in its classpath when it runs the test harness (in this case, cucumber). However, keeping the gigantic list of dependencies in sync seems error-prone, and converting the Ant build to a unified Gradle build isn't really in the cards right now (as much as I want to).

So, I was thinking I could simply reference the jar files in the Ant build within the JavaExec wrapper's classpath. Seems simple enough, so I tried this:

javaexec {
    ...
    classpath = sourceSets.main.output +
                sourceSets.test.output +
                fileTree(dir: libPath, include: '*.jar')
}

libPath is the path to the Ant build's lib directory that contains all the jar files. However, because of the sheer volume of dependencies here, I get this lovely runtime exception when executing:

Caused by: java.io.IOException: Cannot run program "C:\Java\jdk1.8.0_161\bin\java.exe" (in directory "C:\development"): CreateProcess error=206, The filename or extension is too long
        at net.rubygrapefruit.platform.internal.DefaultProcessLauncher.start(DefaultProcessLauncher.java:25)
        ... 7 more
Caused by: java.io.IOException: CreateProcess error=206, The filename or extension is too long
        ... 8 more

I've seen this song and dance before in the Ant build. This is because the classpath is simply too long. If I could define the classpath explicitly myself, I could give it the *.jar path directory (un-exploded into separate jar files) and it would work, shortening the classpath but still including everything. However, because the classpath here is a FileCollection , I don't see a way to provide the wildcard directly to the classpath un-exploded.

Maybe I'm missing something in the DSL or FileCollections that would allow me to do this, but can anyone think of a good way to solve this?

Answer 1

Looks like a pathing jar will suffice in this case:

task pathingJar(type: Jar) {
    appendix = 'pathing'
    doFirst {
        manifest {
            attributes 'Class-Path': fileTree(dir: libPath, include: '*.jar').join(' ')
        }
    }
}

task cucumber(dependsOn: 'pathingJar') {
    doLast {
        ...
        javaexec {
            ...
            classpath = sourceSets.main.output +
                        sourceSets.test.output +
                        files(pathingJar.archivePath)
        }
    }
}