Gradle
  1. Gradle
  2. GRADLE-1420

Forked groovyc compilation can create a classpath line too long for Windows

    Details

    • Type: Bug Bug
    • Status: Resolved Resolved
    • Resolution: Fixed
    • Affects Version/s: 1.0-milestone-1
    • Fix Version/s: 1.0-rc-1

      Description

      We hit the same issue documented here:

      http://gradle.1045684.n5.nabble.com/Groovyc-fork-failing-on-Windows-td3357060.html

      When gradle tries to compile (in our case) a mixed groovy/java environment on a Windows machine it returns an exception:

      java.io.IOException: Cannot run program "c:\PROGRA~1\Java\jdk1.6.0_10
      \jre\bin\java": CreateProcess error=87, The parameter is incorrect"

      This is due to the command exceeding the size limit on command-line arguments in Windows. The build works fine in Linux.

      Peter suggests turning off forking on the above thread as a workaround:

      [compileGroovy, compileTestGroovy]*.groovyOptions.fork = false

      The process indeed does not fork with that line, but it just hangs (even with GRADLE_OPTS set to 1G).

        Issue Links

          Activity

          Hide
          Guillaume Laforge
          added a comment -

          Ray, it's not in a released version of Groovy yet.
          I tried the patch indicated in the Groovy JIRA issue, but alas, it's failing the Groovy build.
          So it seems the patch needs a bit more work.

          Show
          Guillaume Laforge
          added a comment - Ray, it's not in a released version of Groovy yet. I tried the patch indicated in the Groovy JIRA issue, but alas, it's failing the Groovy build. So it seems the patch needs a bit more work.
          Hide
          Ray Nicholus
          added a comment -

          Tasks for gradle build file to address groovyc "classpath too long" issue.

          Show
          Ray Nicholus
          added a comment - Tasks for gradle build file to address groovyc "classpath too long" issue.
          Hide
          Ray Nicholus
          added a comment - - edited

          I finally got the "pathing jar" idea to work. I consider this to be a permanent workaround. This could be considered a solution if it is made part of gradle itself.

          The original pathing jar code was provided by Peter, but it didn't work. The problem: classpath elements referenced in the pathing jar must be relative to the location of the pathing jar. So, this appears to work for me (see attached classpath-too-long.txt).

          Show
          Ray Nicholus
          added a comment - - edited I finally got the "pathing jar" idea to work. I consider this to be a permanent workaround. This could be considered a solution if it is made part of gradle itself. The original pathing jar code was provided by Peter, but it didn't work. The problem: classpath elements referenced in the pathing jar must be relative to the location of the pathing jar. So, this appears to work for me (see attached classpath-too-long.txt).
          Hide
          Kirk Rasmussen
          added a comment -

          For us unfortunate developers stuck on the Windows platform I have opened the following bug report (might take a few days to show up):

          http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7162307

          It turns out that javac has supported @argfile mechanism for a long time (since at least 1.4):

          http://docs.oracle.com/javase/1.4.2/docs/tooldocs/windows/java.html#commandlineargfile

          I'm not sure why the "java" launcher was over looked. I have problems running certain TestNG unit tests because the -classpath command line becomes too long (in Windows anyways)

          This could be easily solved by Oracle if they added support for @argfile! Or if Windows ever enters the 21st century. I won't hold my breath...

          Show
          Kirk Rasmussen
          added a comment - For us unfortunate developers stuck on the Windows platform I have opened the following bug report (might take a few days to show up): http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7162307 It turns out that javac has supported @argfile mechanism for a long time (since at least 1.4): http://docs.oracle.com/javase/1.4.2/docs/tooldocs/windows/java.html#commandlineargfile I'm not sure why the "java" launcher was over looked. I have problems running certain TestNG unit tests because the -classpath command line becomes too long (in Windows anyways) This could be easily solved by Oracle if they added support for @argfile! Or if Windows ever enters the 21st century. I won't hold my breath...
          Hide
          Kirk Rasmussen
          added a comment -

          FYI...

          Surefire uses the empty JAR technique too but they also use the CLASSPATH environment variable as an option which doesn't have some the shortcomings of the MANIFEST techique:

          http://maven.apache.org/plugins/maven-surefire-plugin/examples/class-loading.html

          Show
          Kirk Rasmussen
          added a comment - FYI... Surefire uses the empty JAR technique too but they also use the CLASSPATH environment variable as an option which doesn't have some the shortcomings of the MANIFEST techique: http://maven.apache.org/plugins/maven-surefire-plugin/examples/class-loading.html

            People

            • Assignee:
              Unassigned
              Reporter:
              Ben Dotte
            • Votes:
              5 Vote for this issue
              Watchers:
              7 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: