Tuning the way Gradle uses Ant to compile

Old Forum Archive
1

My company uses Gradle to build Java projects. Our build farm runs on Linux boxes however a lot of our developers use Windows workstations. On Windows, some of our builds fail with the infamous error message “java.io.IOException: CreateProcess error=206, The filename or extension is too long”.

This occurs in the compilation step using Ant under the hood because the classpath exceeds Windows’ max length (about 8192 chars).

To workaround this issue, I thought about implementing the “pathing jar” approach described here: http://stackoverflow.com/questions/201816/how-to-set-a-long-java-classpath-in-msdos-windows/201969#201969 however this requires tuning the way Gradle invokes Ant. Instead of providing a (too long) list of jar paths, the tweak consists in generating a jar file that lists all those files for us.

I had a quick look at the Gradle source code (in 1.4, the version we use) but couldn’t find any callback / entry point to implement such a fix.

What’s the best approach to fix this issue ?

Thanks,

2

Hello Francois, as a first side note notice that the useAnt property in JavaCompile is deprecated in Gradle. Now to your question. I think one approach would be to reconfigure all your JavaCompile tasks in your builds and create a path jar in the doFirst block of the JavaCompile tasks or in a task your compile tasks depends on.

this could look like this:

tasks.withType(JavaCompile){
 doFirst{
  println "generating path jar"
  ant{
   jar(destfile:"$buildDir/pathjars/${name}Path.jar"){
    manifest{
     attribute(name:"Class-Path", value:configurations.compile.asPath)
    }
   }
  }
  classpath = files("$buildDir/pathjars/${name}Path.jar")
 }
}

BTW. this should also be adaptable to the AntCompiler task types you have in your builds

cheers, René

3

Hi René,

That’s a very elegant solution (as always !). Thanks for the quick turn-around. I’ll test this right away.

Cheers

4

BTW. It might be interesting for you to just apply this setup when running on windows, as it is a very windows specific solution

5

I’d be interested to hear why you are still using the Ant-based compiler integration. Gradle’s “native” compiler integration is faster, doesn’t suffer from such limitations, and is the way forward in general.

6

Hi Peter,

I understand your question. To be honest, there’s not a good reason for this. We migrated this year to Gradle. The migration job for this particular (huge, Rene knows) build was done by one team (not mine). The build is continuously maintained by a lot of people (not a single team) so there’s a really diffuse responsibility. In the end noone’s really responsible for ensuring we use the latest version of Gradle for instance. Likewise, it’s unclear who’s responsible for maintaining this huge build. Now I could switch to the native compiler but since I was never explained the very reason why we initially used Ant (and I’m pretty sure there’s a reason) my change will surely yield side effects.

7

I see. Still worth a shot.