[
https://issues.apache.org/jira/browse/SUREFIRE-1496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16731937#comment-16731937
]
Tibor Digana edited comment on SUREFIRE-1496 at 1/2/19 10:54 AM:
-----------------------------------------------------------------
[~scolebou...@joda.org]
[~earcam]
[~triceo85]
I have not seen in the jira issue description that the build was broken because
of the message in the dump file.
IMHO the message is printed by JVM before Surefire wraps StdOut but then it is
the issue where the user should investigate the message and his project.
Regarding the process pipes, our plan is to use TCP/IP sockets instead of pipes
in the interprocess communication in the near future.
Pls refer to the Roadmap on the front page
https://maven.apache.org/surefire/maven-surefire-plugin/
was (Author: tibor17):
[~scolebou...@joda.org]
[~earcam]
[~triceo85]
I have not seen in the jira issue description that the build was broken because
of the message in the dump file.
IMHO the message is printed by JVM before Surefire wraps StdOut but then it is
the issue where the user should investigate the message and his project.
Regarding the process pipes, our plan is to use TCP/IP sockets instead of pipes
in the interprocess communication in the new future.
Pls refer to the Roadmap on the front page
https://maven.apache.org/surefire/maven-surefire-plugin/
> 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)
