You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by "Brett Porter (JIRA)" <ji...@codehaus.org> on 2005/08/22 08:38:13 UTC
[jira] Updated: (MPJCOVERAGE-28) Instrumentation fails on windows due to command line arg length.
[ http://jira.codehaus.org/browse/MPJCOVERAGE-28?page=all ]
Brett Porter updated MPJCOVERAGE-28:
------------------------------------
Description:
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
was:
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
Remaining Estimate: (was: 4 hours)
Original Estimate: (was: 14400)
> Instrumentation fails on windows due to command line arg length.
> ----------------------------------------------------------------
>
> Key: MPJCOVERAGE-28
> URL: http://jira.codehaus.org/browse/MPJCOVERAGE-28
> Project: maven-jcoverage-plugin
> Type: Bug
> Versions: 1.0.9
> Environment: Windows XP Professional Version 2002, SP 2, Java 1.4.1, Maven 1.02, Pentium IV 2.26 GHZ, 1 GB Ram
> Reporter: Achim Westermann
> Assignee: Emmanuel Venisse
>
>
> 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
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org