Instrumentation fails on windows due to command line arg length.

When starting with a clean project jcoverage fails when compiling the test classes to it's maven.jcoverage.dir with tons of "cannot resolve symbol" errors.

The underlying error has already happend before. Instrumentation failed:

[instrument] [ERROR] java.io.IOException: CreateProcess: C:\j2sdk1.4.1\jre\bin\java.exe -classpath "C:\Dokumente und Einstellungen\westermann\.maven\repository\jcoverage\jars\jcoverage-1.0.5.jar;C:\Dokumente und Einstellungen\westermann\.maven\repository\bcel\jars\bcel-5.1.jar;C:\Dokumente und Einstellungen\westermann\.maven\repository\urbanophile\jars\java-getopt-1.0.9.jar;C:\Dokumente und Einstellungen\westermann\.maven\repository\log4j\jars\log4j-1.2.8.jar;C:\Dokumente und Einstellungen\westermann\.maven\repository\oro\jars\oro-2.0.7.jar;C:\Dokumente und Einstellungen\westermann\.maven\repository\junit\jars\junit-3.8.1.jar;C:\Dokumente und Einstellungen\westermann\.maven\repository\xerces\jars\xercesImpl-2.6.2.jar;C:\Dokumente und Einstellungen\westermann\.maven\repository\xerces\jars\xmlParserAPIs-2.2.1.jar" com.jcoverage.coverage.Instrument -d C:\build\jcoverage\classes -basedir C:\build\classes org\opencms\workplace\CmsWorkplace.class org\opencms\main\CmsRuntimeException.class org\opencms\file\TestSiblings$1.class com\opencms\workplace\CmsRepla?

This leads to the fact that the classes required by the test sources which should be the instrumented ones are not in maven.jcoverage.dir thus missing from jcoverage classpath.

Occurrance:

Only on Windows, not on RH Linux 7.3.

Assumption:

On Windows the maximum command line length is exceeded. I have experienced similar behaviour in build-systems with makefile before. Look at the trainling '?' -> The argument seems to have been truncated. The error hits back to the current process at the process creation for the instrumentation task.

Suggestion:

A) Perhaps use files for the arguments and a new -file argument to the com.jcoverage.coverage.Instrument
class. Or lay open the underlying fork argument of the ANT javac task: Without forking this would not
happen. The fallback could be possible memory problems.

B) Fail the goal immediately when instrumentation fails. Errors that result are hard to find.

Thanks for jcoverage,

Achim