GWT compiler call from Ant causes "Argument list too long" error

[ijonas]

Hi,

I've got a GWT project that I'm upgrading from 1.5.3. to 1.6.4 and
after adjusting my Ant build task as follows

<target name="compile-gwt" depends="compile" description="GWT compile
to JavaScript" unless="skip.gwt">
<java failonerror="true" fork="true"
classname="com.google.gwt.dev.Compiler">
<classpath>
<fileset dir="${src.dir}"/>
<fileset dir="${build.dir}"/>
<fileset dir="${gwt.home}">
<include name="*.jar" />
</fileset>
<fileset dir="${local.lib}/gwt-3rdparty">
<include name="*.jar" />
</fileset>
</classpath>
<!-- add jvmarg -Xss16M or similar if you see a StackOverflowError
-->
<jvmarg value="-Xmx512M" />
<!-- Additional arguments like -style PRETTY or -logLevel DEBUG -->
<arg value="com.vamosa.VamosaClient" />
</java>
</target>

When running the task it causes the following error, from both inside
Eclipse as well as on the command line;

BUILD FAILED
java.io.IOException: Cannot run program "/usr/lib/jvm/java-6-
sun-1.6.0.14/jre/bin/java": java.io.IOException: error=7, Argument
list too long
at java.lang.ProcessBuilder.start(ProcessBuilder.java:459)
at java.lang.Runtime.exec(Runtime.java:593)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke
(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.apache.tools.ant.taskdefs.Execute$Java13CommandLauncher.exec
(Execute.java:832)
at org.apache.tools.ant.taskdefs.Execute.launch(Execute.java:447)
at org.apache.tools.ant.taskdefs.Execute.execute(Execute.java:461)
at org.apache.tools.ant.taskdefs.Java.fork(Java.java:784)
at org.apache.tools.ant.taskdefs.Java.executeJava(Java.java:211)
at org.apache.tools.ant.taskdefs.Java.executeJava(Java.java:132)
at org.apache.tools.ant.taskdefs.Java.execute(Java.java:105)
at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:
288)
at sun.reflect.GeneratedMethodAccessor1.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.apache.tools.ant.dispatch.DispatchUtils.execute
(DispatchUtils.java:106)
at org.apache.tools.ant.Task.perform(Task.java:348)
at org.apache.tools.ant.Target.execute(Target.java:357)
at org.apache.tools.ant.Target.performTasks(Target.java:385)
at org.apache.tools.ant.Project.executeSortedTargets(Project.java:
1337)
at org.apache.tools.ant.Project.executeTarget(Project.java:1306)
at org.apache.tools.ant.helper.DefaultExecutor.executeTargets
(DefaultExecutor.java:41)
at org.apache.tools.ant.Project.executeTargets(Project.java:1189)
at org.apache.tools.ant.Main.runBuild(Main.java:758)
at org.apache.tools.ant.Main.startAnt(Main.java:217)
at org.apache.tools.ant.launch.Launcher.run(Launcher.java:257)
at org.apache.tools.ant.launch.Launcher.main(Launcher.java:104)
Caused by: java.io.IOException: java.io.IOException: error=7, Argument
list too long
at java.lang.UNIXProcess.<init>(UNIXProcess.java:148)
at java.lang.ProcessImpl.start(ProcessImpl.java:65)
at java.lang.ProcessBuilder.start(ProcessBuilder.java:452)

A quick google reveals other Java systems (like Confluence) running
into issues with the fork-flag, so I tried setting fork=false, but
that generated allsorts of classloading nastiness.

I'm running 64-bit Ubuntu 9.04. Any help would be greatly appreciated.

Many thanks,
ijonas Kisselbach

[ijonas]

Nothing like answering your own posts... My mistake was in the
classpath block off the <java/> task

The correct form is:

<target name="compile-gwt" depends="compile" description="GWT compile
to JavaScript" unless="skip.gwt">
<java failonerror="true" fork="true"
classname="com.google.gwt.dev.Compiler">
<classpath>

<pathelement path="${src.dir}"/>
<pathelement path="${build.dir}"/>

<fileset dir="${gwt.home}">
<include name="*.jar" />
</fileset>
<fileset dir="${local.lib}/gwt-3rdparty">
<include name="*.jar" />
</fileset>
</classpath>
<!-- add jvmarg -Xss16M or similar if you see a StackOverflowError
-->
<jvmarg value="-Xmx512M" />
<!-- Additional arguments like -style PRETTY or -logLevel DEBUG -->
<arg value="com.vamosa.VamosaClient" />
</java>
</target>

The faulty classpath block in my original post caused a classpath that
was several kilobytes in size.

Cheers,
Ijonas Kisselbach.