[jira] [Commented] (SUREFIRE-1496) Dump file error for java.lang.module.ResolutionException

["Tibor Digana (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/SUREFIRE-1496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16719343#comment-16719343 ] 

Tibor Digana commented on SUREFIRE-1496:
----------------------------------------

[~scolebourne@joda.org]
[~earcam]
The Dump file is only a report and does not crash the plugin.
I think this might have to do with a bug which is fixed in version 3.0.0-M2. White spaces in paths.

If the problem still exists, run the build with debug log level (i.e. mvn test -X) and attach the Surefire args file to JIRA. On Linux it is on file system in the project (target/surefire) and Windows has it in TEMP - follow the logs with the path location.
The args file contains all the module paths executed by java for the forked JVM in Surefire.

> Dump file error for java.lang.module.ResolutionException
> --------------------------------------------------------
>
>                 Key: SUREFIRE-1496
>                 URL: https://issues.apache.org/jira/browse/SUREFIRE-1496
>             Project: Maven Surefire
>          Issue Type: Bug
>          Components: process forking
>    Affects Versions: 2.21.0
>            Reporter: Stephen Colebourne
>            Priority: Major
>
> Scenario:
>  * two JPMS modules `org.foo.a` and `org.foo.b`, both with module-info
>  * `org.foo.a` requires `org.foo.b`
>  * `org.foo.b` exports package `org.foo.b.c`
>  * `org.foo.a` contains a text file: src/main/resources/org/foo/b/c/Foo.txt
>  * when surefire is run on module `org.foo.a` a dump file error occurs:
>  
> {noformat}
> Corrupted STDOUT by directly writing to native stream in forked JVM 1. Stream 'Error occurred during initialization of boot layer'.
> java.lang.IllegalArgumentException: Stream stdin corrupted. Expected comma after third character in command 'Error occurred during initialization of boot layer'.
>  at org.apache.maven.plugin.surefire.booterclient.output.ForkClient$OperationalData.<init>(ForkClient.java:511)
>  at org.apache.maven.plugin.surefire.booterclient.output.ForkClient.processLine(ForkClient.java:209)
>  at org.apache.maven.plugin.surefire.booterclient.output.ForkClient.consumeLine(ForkClient.java:176)
>  at org.apache.maven.plugin.surefire.booterclient.output.ThreadedStreamConsumer$Pumper.run(ThreadedStreamConsumer.java:88)
>  at java.base/java.lang.Thread.run(Thread.java:844)
> Created on 2018-03-07T11:32:36.053
> Corrupted STDOUT by directly writing to native stream in forked JVM 1. Stream 'java.lang.module.ResolutionException: Module org.foo.a contains package org.foo.b.c, module org.foo.b exports package org.foo.b.c to org.foo.a'. 
> {noformat}
>  
> While the scenario is one that JPMS rejects, surefire should handle it better. The compiler compiles the code just fine because it doesn't see the resources as a package. Surefire is thus the first part of Maven that sees it as a "package" that clashes with the module org.foo.b.
> Clearly, some part of surefire needs to be taught to about java.lang.module.ResolutionException, as the error is tricky to find/see because it is a dump file.
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)