I am asking all participants directly as I have created Jira issue [1]
related to our previous talk.
If you agree with the text in Jira, we can follow the idea of the fix.
The fix seems to be very simple. If you have spare time, please open a
pullreq on GitHub.
I have already assigned this issue
It sounds like you don't have a problem with Surefire nothing but the
debugger in your IDE.
If not, then again "where you see the issue? E.g. in surefire-report
files in directory target/surefire-reports/ ?".
> I'd like to be able to debug that failure even though my own OS is
> Unixy.
> Does
Thanks folks for your input.
Reading on the user list archive, I'm realizing my premise may have been
unclear if you only read it here:
I didn't use a literal 0x0A byte in the pom, I used the xml entity.
I'll put it as a java expression in hopes that clients do not render it
as a literal line
Maybe we are missing CDATA here:
...
java.lang.RuntimeException
at MyTest.test(MyTest.java:7)
On Tue, May 7, 2019 at 11:18 PM Laird Nelson wrote:
> On Tue, May 7, 2019 at 2:07 PM Tibor Digana
> wrote:
>
> > strange thing is that the new line is ignored.
> >
>
> Lurking here,
This is my experiment, see the HTML (contains the stacktrace within
...) and a picture attached.
org.junit.jupiter
junit-jupiter-engine
5.4.1
test
...
org.apache.maven.plugins
maven-surefire-plugin
3.0.0-M3
org.apache.maven.plugins
On Tue, May 7, 2019 at 2:07 PM Tibor Digana wrote:
> strange thing is that the new line is ignored.
>
Lurking here, but (a) I thought in a forked
execution were indeed passed on the command line as -D arguments, (b) the
behavior may have to do instead with the fact that whitespace in XML is
strange thing is that the new line is ignored.
What version of plugin you use?
Where you see the stack trace? In console, in text report or XML report?
Perhaps we have to see your project. You can post the code with POM on Gist
but I think we cannot help you more unless we see the POM and try
Hi John,
You must observe the warning in this case:
line.separator cannot be set as system property, use
-Dline.separator=... instead
The same is with
"java.library.path", "file.encoding", "jdk.map.althashing.threshold",
"line.separator" .
This means that you should not use these property keys
line.separator is a system dependent property, and not a system property that
you can override.
This will be CRLF for Windows, and LF for *Nix & MacOS.
https://www.geeksforgeeks.org/system-lineseparator-method-in-java-with-examples/
Hi, I may have found a bug.
My team's code has tests failing depending on what system they're run
on, apparently because of conflicting line separator. I'm trying to
change the line.separator value so I can debug.
My normal setting is line.separator=\n, and tests currently pass. I
tried adding
10 matches
Mail list logo
