date:20181102



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

ASF GitHub Bot commented on SUREFIRE-1588:
--

cstamas edited a comment on issue #197: SUREFIRE-1588 Patch (Java7)
URL: https://github.com/apache/maven-surefire/pull/197#issuecomment-435514071
 
 
   @jglick re copying, then we open a total different "pandora" box, think 
about dep artifact GAVs with differrent G's but same As and Vs (for example 
`/org/foo/1.0/api-1.0.jar` vs `/com/bar/1.0/api-1.0.jar`), we'd need to handle 
conflicts like these. Or we could copy them in maven2 layout (ie. create a mini 
"local repo" for surefire booter), and handle that.
   
   I'd def look into other directions as well...
   
   This whole thing started due `-cp` and different command line length 
constraints, look here 
https://maven.apache.org/surefire/maven-surefire-plugin/examples/class-loading.html


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Surefire manifest jar classloading broken on latest Debian/Ubuntu Java8
> ---
>
> Key: SUREFIRE-1588
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1588
> Project: Maven Surefire
>  Issue Type: Bug
>Affects Versions: 2.22.1
>Reporter: Cservenak, Tamas
>Assignee: Tibor Digana
>Priority: Major
> Fix For: 3.0.0-M1
>
>
> See issue [1], but in short: latest Java8 on Ubuntu/Debian/Mint family of 
> Linuxes (am on Mint, Ubuntu derivative) contains this patch [3], and eforces 
> Manifest class path entries to be relative, as defined in [2].
> Hence, surefire booter and rest of Maven classpath, that uses absolute URLs 
> are simply discarded.
> Example error:
> {noformat}
> # Created at 2018-10-30T21:34:43.339
> Error: Could not find or load main class 
> org.apache.maven.surefire.booter.ForkedBooter{noformat}
> using the new property 
> {{-Djdk.net.URLClassPath.disableClassPathURLCheck=debug}} clearly shows that 
> all the entries from the surefire JAR are simply ignored.
>  
> [1] [https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911925]
> [2] 
> https://docs.oracle.com/javase/8/docs/technotes/guides/jar/jar.html#classpath
> [3] [https://hg.openjdk.java.net/jdk/jdk/rev/27135de165ac]



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

[GitHub] cstamas edited a comment on issue #197: SUREFIRE-1588 Patch (Java7)

cstamas edited a comment on issue #197: SUREFIRE-1588 Patch (Java7)
URL: https://github.com/apache/maven-surefire/pull/197#issuecomment-435514071
 
 
   @jglick re copying, then we open a total different "pandora" box, think 
about dep artifact GAVs with differrent G's but same As and Vs (for example 
`/org/foo/1.0/api-1.0.jar` vs `/com/bar/1.0/api-1.0.jar`), we'd need to handle 
conflicts like these. Or we could copy them in maven2 layout (ie. create a mini 
"local repo" for surefire booter), and handle that.
   
   I'd def look into other directions as well...
   
   This whole thing started due `-cp` and different command line length 
constraints, look here 
https://maven.apache.org/surefire/maven-surefire-plugin/examples/class-loading.html


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[jira] [Commented] (SUREFIRE-1588) Surefire manifest jar classloading broken on latest Debian/Ubuntu Java8



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

ASF GitHub Bot commented on SUREFIRE-1588:
--

cstamas commented on issue #197: SUREFIRE-1588 Patch (Java7)
URL: https://github.com/apache/maven-surefire/pull/197#issuecomment-435514071
 
 
   @jglick re copying, then we open a total different "pandora" box, think 
about dep artifact GAVs with differrent G's but same As and Vs (for example 
`/org/foo/1.0/api-1.0.jar` vs `/com/bar/1.0/api-1.0.jar`), we'd need to handle 
conflicts like these. Or we could copy them in maven2 layout (ie. create a mini 
"local repo" for surefire booter), and handle that.
   
   I'd def look into other directions as well...


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Surefire manifest jar classloading broken on latest Debian/Ubuntu Java8
> ---
>
> Key: SUREFIRE-1588
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1588
> Project: Maven Surefire
>  Issue Type: Bug
>Affects Versions: 2.22.1
>Reporter: Cservenak, Tamas
>Assignee: Tibor Digana
>Priority: Major
> Fix For: 3.0.0-M1
>
>
> See issue [1], but in short: latest Java8 on Ubuntu/Debian/Mint family of 
> Linuxes (am on Mint, Ubuntu derivative) contains this patch [3], and eforces 
> Manifest class path entries to be relative, as defined in [2].
> Hence, surefire booter and rest of Maven classpath, that uses absolute URLs 
> are simply discarded.
> Example error:
> {noformat}
> # Created at 2018-10-30T21:34:43.339
> Error: Could not find or load main class 
> org.apache.maven.surefire.booter.ForkedBooter{noformat}
> using the new property 
> {{-Djdk.net.URLClassPath.disableClassPathURLCheck=debug}} clearly shows that 
> all the entries from the surefire JAR are simply ignored.
>  
> [1] [https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911925]
> [2] 
> https://docs.oracle.com/javase/8/docs/technotes/guides/jar/jar.html#classpath
> [3] [https://hg.openjdk.java.net/jdk/jdk/rev/27135de165ac]



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

[GitHub] cstamas commented on issue #197: SUREFIRE-1588 Patch (Java7)

cstamas commented on issue #197: SUREFIRE-1588 Patch (Java7)
URL: https://github.com/apache/maven-surefire/pull/197#issuecomment-435514071
 
 
   @jglick re copying, then we open a total different "pandora" box, think 
about dep artifact GAVs with differrent G's but same As and Vs (for example 
`/org/foo/1.0/api-1.0.jar` vs `/com/bar/1.0/api-1.0.jar`), we'd need to handle 
conflicts like these. Or we could copy them in maven2 layout (ie. create a mini 
"local repo" for surefire booter), and handle that.
   
   I'd def look into other directions as well...


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[jira] [Commented] (SUREFIRE-1588) Surefire manifest jar classloading broken on latest Debian/Ubuntu Java8



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

ASF GitHub Bot commented on SUREFIRE-1588:
--

jglick commented on issue #197: SUREFIRE-1588 Patch (Java7)
URL: https://github.com/apache/maven-surefire/pull/197#issuecomment-435512386
 
 
   > With affected JDK and this kind of Windows setup this PR will not work.
   
   So maybe we do need to fall back to copying classpath JARs into the `target` 
directory somewhere. Would be slow, but better than not working at all.
   
   Can the whole issue be bypassed by running the booter with an explicit `-cp` 
rather than trying to use a `Class-Path` attribute?


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Surefire manifest jar classloading broken on latest Debian/Ubuntu Java8
> ---
>
> Key: SUREFIRE-1588
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1588
> Project: Maven Surefire
>  Issue Type: Bug
>Affects Versions: 2.22.1
>Reporter: Cservenak, Tamas
>Assignee: Tibor Digana
>Priority: Major
> Fix For: 3.0.0-M1
>
>
> See issue [1], but in short: latest Java8 on Ubuntu/Debian/Mint family of 
> Linuxes (am on Mint, Ubuntu derivative) contains this patch [3], and eforces 
> Manifest class path entries to be relative, as defined in [2].
> Hence, surefire booter and rest of Maven classpath, that uses absolute URLs 
> are simply discarded.
> Example error:
> {noformat}
> # Created at 2018-10-30T21:34:43.339
> Error: Could not find or load main class 
> org.apache.maven.surefire.booter.ForkedBooter{noformat}
> using the new property 
> {{-Djdk.net.URLClassPath.disableClassPathURLCheck=debug}} clearly shows that 
> all the entries from the surefire JAR are simply ignored.
>  
> [1] [https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911925]
> [2] 
> https://docs.oracle.com/javase/8/docs/technotes/guides/jar/jar.html#classpath
> [3] [https://hg.openjdk.java.net/jdk/jdk/rev/27135de165ac]



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

[GitHub] jglick commented on issue #197: SUREFIRE-1588 Patch (Java7)

jglick commented on issue #197: SUREFIRE-1588 Patch (Java7)
URL: https://github.com/apache/maven-surefire/pull/197#issuecomment-435512386
 
 
   > With affected JDK and this kind of Windows setup this PR will not work.
   
   So maybe we do need to fall back to copying classpath JARs into the `target` 
directory somewhere. Would be slow, but better than not working at all.
   
   Can the whole issue be bypassed by running the booter with an explicit `-cp` 
rather than trying to use a `Class-Path` attribute?


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[jira] [Commented] (SUREFIRE-1588) Surefire manifest jar classloading broken on latest Debian/Ubuntu Java8



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

ASF GitHub Bot commented on SUREFIRE-1588:
--

cstamas commented on issue #197: SUREFIRE-1588 Patch (Java7)
URL: https://github.com/apache/maven-surefire/pull/197#issuecomment-435506871
 
 
   Btw, second look:
   
   SiblingAggregatorIT POMs are not using `it-parent`, so that IT is kinda 
fluke, it always tests with use Maven (3.6.0 it my case) Super-POM defined 
surefire, not the built one. So it will never pass on affected JDK.
   
   Surefire162CharsetProviderIT copied the jcharset into wrong repo, this is 
why it did not found the artifact in local repo: it copied it to 
`surefire-its/${env.HOME}/.m2/repository-oss/jcharset/jcharset/1.2.1/jcharset-1.2.1.jar`,
 like did not interpolate things. Yes, my settings.xml defines my local repo as 
`${env.HOME}/.m2/repository-oss`.
   
   and finally, the Surefire1535TestNGParallelSuitesIT failure you got, don't 
know what is it about, but: seems you are on Windows and you have local repo 
and maven workdir on different drive letters. With affected JDK and this kind 
of Windows setup this PR will not work. Unlike UN*X, Windows due drive letter 
will not be able to "relativise" paths like these.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Surefire manifest jar classloading broken on latest Debian/Ubuntu Java8
> ---
>
> Key: SUREFIRE-1588
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1588
> Project: Maven Surefire
>  Issue Type: Bug
>Affects Versions: 2.22.1
>Reporter: Cservenak, Tamas
>Assignee: Tibor Digana
>Priority: Major
> Fix For: 3.0.0-M1
>
>
> See issue [1], but in short: latest Java8 on Ubuntu/Debian/Mint family of 
> Linuxes (am on Mint, Ubuntu derivative) contains this patch [3], and eforces 
> Manifest class path entries to be relative, as defined in [2].
> Hence, surefire booter and rest of Maven classpath, that uses absolute URLs 
> are simply discarded.
> Example error:
> {noformat}
> # Created at 2018-10-30T21:34:43.339
> Error: Could not find or load main class 
> org.apache.maven.surefire.booter.ForkedBooter{noformat}
> using the new property 
> {{-Djdk.net.URLClassPath.disableClassPathURLCheck=debug}} clearly shows that 
> all the entries from the surefire JAR are simply ignored.
>  
> [1] [https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911925]
> [2] 
> https://docs.oracle.com/javase/8/docs/technotes/guides/jar/jar.html#classpath
> [3] [https://hg.openjdk.java.net/jdk/jdk/rev/27135de165ac]



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

[GitHub] cstamas commented on issue #197: SUREFIRE-1588 Patch (Java7)

cstamas commented on issue #197: SUREFIRE-1588 Patch (Java7)
URL: https://github.com/apache/maven-surefire/pull/197#issuecomment-435506871
 
 
   Btw, second look:
   
   SiblingAggregatorIT POMs are not using `it-parent`, so that IT is kinda 
fluke, it always tests with use Maven (3.6.0 it my case) Super-POM defined 
surefire, not the built one. So it will never pass on affected JDK.
   
   Surefire162CharsetProviderIT copied the jcharset into wrong repo, this is 
why it did not found the artifact in local repo: it copied it to 
`surefire-its/${env.HOME}/.m2/repository-oss/jcharset/jcharset/1.2.1/jcharset-1.2.1.jar`,
 like did not interpolate things. Yes, my settings.xml defines my local repo as 
`${env.HOME}/.m2/repository-oss`.
   
   and finally, the Surefire1535TestNGParallelSuitesIT failure you got, don't 
know what is it about, but: seems you are on Windows and you have local repo 
and maven workdir on different drive letters. With affected JDK and this kind 
of Windows setup this PR will not work. Unlike UN*X, Windows due drive letter 
will not be able to "relativise" paths like these.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[jira] [Commented] (SUREFIRE-1588) Surefire manifest jar classloading broken on latest Debian/Ubuntu Java8



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

ASF GitHub Bot commented on SUREFIRE-1588:
--

cstamas edited a comment on issue #197: SUREFIRE-1588 Patch (Java7)
URL: https://github.com/apache/maven-surefire/pull/197#issuecomment-435497122
 
 
   **IMPORTANT UPDATE**: as I removed the logging from the PR locally (mention 
above), I also removed the report stuff from master, and then I got these IT 
results, so please mind me, I forgot to mention and defs don't want to mislead 
you or anyone else. Sorry again.
   
   @Tibor17 I ran locally ITs of the current master **modified by removing line 
152 in JarManifestForkConfiguration, the logDump call** (on affected Linux with 
b13 openjdk8), and I got totally different outcome: none of those ITs you 
mention failed, but instead I have:
   
   ```
   Results :
   
   Tests in error: 
 
jarShouldUseFile(org.apache.maven.surefire.its.jiras.Surefire855AllowFailsafeUseArtifactFileIT):
 Exit code was non-zero: 1; command line and log = (..)
 
warShouldUseClasses(org.apache.maven.surefire.its.jiras.Surefire855AllowFailsafeUseArtifactFileIT):
 Exit code was non-zero: 1; command line and log = (..)

osgiBundleShouldUseFile(org.apache.maven.surefire.its.jiras.Surefire855AllowFailsafeUseArtifactFileIT):
 Exit code was non-zero: 1; command line and log = (..)
 
testCharsetProvider(org.apache.maven.surefire.its.jiras.Surefire162CharsetProviderIT):
 Exit code was non-zero: 1; command line and log = (..)
 testSiblingAggregator(org.apache.maven.surefire.its.SiblingAggregatorIT): 
Exit code was non-zero: 1; command line and log = (..)
   
   Tests run: 780, Failures: 0, Errors: 5, Skipped: 138
   ```
   
   And the most interesting part: some ITs failed due SUREFIRE-1588! 
   
   For example, SUREFIRE-1588 causes 
org.apache.maven.surefire.its.SiblingAggregatorIT failure, produced traces like 
these:
   
   ```
   [ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-surefire-plugin:2.12.4:test (default-test) on 
project child2: Execution default-test of goal 
org.apache.maven.plugins:maven-surefire-plugin:2.12.4:test failed: The forked 
VM terminated without saying properly goodbye. VM crash or System.exit called ? 
-> [Help 1]
   org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute 
goal org.apache.maven.plugins:maven-surefire-plugin:2.12.4:test (default-test) 
on project child2: Execution default-test of goal 
org.apache.maven.plugins:maven-surefire-plugin:2.12.4:test failed: The forked 
VM terminated without saying properly goodbye. VM crash or System.exit called ?
   ```
   
   Please note, all 2.x surefire plugin versions are affected of SUREFIRE-1588, 
hence it failed (unsure why IT uses 2.12.4 in the first place and not the built 
plugin).
   
   Surefire162CharsetProviderIT fails due this
   ```
   Caused by: org.apache.maven.project.DependencyResolutionException: Could not 
resolve dependencies for project 
org.apache.maven.surefire.its:surefire-162-charsetProvider:jar:1.0-SNAPSHOT: 
Could not find artifact jcharset:jcharset:jar:1.2.1 in central 
(https://repo.maven.apache.org/maven2/)
   ```
   
   And is right, there is no such thing.
   
   And finally the Surefire855 tests fails as they assert this
   
   ```
   Expected: a string containing "/target/jiras-surefire-855-jar-1.0.jar"
but: was 
"../../../../../../../../.m2/repository-oss/org/apache/maven/surefire/surefire-booter/3.0.0-M1-SNAPSHOT/surefire-booter-3.0.0-M1-SNAPSHOT.jar
 
../../../../../../../../.m2/repository-oss/org/apache/maven/surefire/surefire-api/3.0.0-M1-SNAPSHOT/surefire-api-3.0.0-M1-SNAPSHOT.jar
 
../../../../../../../../.m2/repository-oss/org/apache/maven/surefire/surefire-logger-api/3.0.0-M1-SNAPSHOT/surefire-logger-api-3.0.0-M1-SNAPSHOT.jar
 ../test-classes/ ../jiras-surefire-855-jar-1.0.jar 
../../../../../../../../.m2/repository-oss/junit/junit/4.11/junit-4.11.jar 
../../../../../../../../.m2/repository-oss/org/hamcrest/hamcrest-core/1.3/hamcrest-core-1.3.jar
 
../../../../../../../../.m2/repository-oss/org/easytesting/fest-assert-core/2.0M9/fest-assert-core-2.0M9.jar
 
../../../../../../../../.m2/repository-oss/org/easytesting/fest-util/1.2.4/fest-util-1.2.4.jar
 
../../../../../../../../.m2/repository-oss/org/hamcrest/hamcrest-library/1.3/hamcrest-library-1.3.jar
 
../../../../../../../../.m2/repository-oss/org/apache/maven/surefire/surefire-junit4/3.0.0-M1-SNAPSHOT/surefire-junit4-3.0.0-M1-SNAPSHOT.jar
 
../../../../../../../../.m2/repository-oss/org/apache/maven/surefire/common-java5/3.0.0-M1-SNAPSHOT/common-java5-3.0.0-M1-SNAPSHOT.jar
 
../../../../../../../../.m2/repository-oss/org/apache/maven/surefire/common-junit3/3.0.0-M1-SNAPSHOT/common-junit3-3.0.0-M1-SNAPSHOT.jar

[jira] [Commented] (SUREFIRE-1588) Surefire manifest jar classloading broken on latest Debian/Ubuntu Java8



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

ASF GitHub Bot commented on SUREFIRE-1588:
--

cstamas edited a comment on issue #197: SUREFIRE-1588 Patch (Java7)
URL: https://github.com/apache/maven-surefire/pull/197#issuecomment-435497122
 
 
   @Tibor17 I ran locally ITs of the current master (on affected Linux with b13 
openjdk8), and I got totally different outcome: none of those ITs you mention 
failed, but instead I have:
   
   ```
   Results :
   
   Tests in error: 
 
jarShouldUseFile(org.apache.maven.surefire.its.jiras.Surefire855AllowFailsafeUseArtifactFileIT):
 Exit code was non-zero: 1; command line and log = (..)
 
warShouldUseClasses(org.apache.maven.surefire.its.jiras.Surefire855AllowFailsafeUseArtifactFileIT):
 Exit code was non-zero: 1; command line and log = (..)

osgiBundleShouldUseFile(org.apache.maven.surefire.its.jiras.Surefire855AllowFailsafeUseArtifactFileIT):
 Exit code was non-zero: 1; command line and log = (..)
 
testCharsetProvider(org.apache.maven.surefire.its.jiras.Surefire162CharsetProviderIT):
 Exit code was non-zero: 1; command line and log = (..)
 testSiblingAggregator(org.apache.maven.surefire.its.SiblingAggregatorIT): 
Exit code was non-zero: 1; command line and log = (..)
   
   Tests run: 780, Failures: 0, Errors: 5, Skipped: 138
   ```
   
   And the most interesting part: some ITs failed due SUREFIRE-1588! 
   
   For example, SUREFIRE-1588 causes 
org.apache.maven.surefire.its.SiblingAggregatorIT failure, produced traces like 
these:
   
   ```
   [ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-surefire-plugin:2.12.4:test (default-test) on 
project child2: Execution default-test of goal 
org.apache.maven.plugins:maven-surefire-plugin:2.12.4:test failed: The forked 
VM terminated without saying properly goodbye. VM crash or System.exit called ? 
-> [Help 1]
   org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute 
goal org.apache.maven.plugins:maven-surefire-plugin:2.12.4:test (default-test) 
on project child2: Execution default-test of goal 
org.apache.maven.plugins:maven-surefire-plugin:2.12.4:test failed: The forked 
VM terminated without saying properly goodbye. VM crash or System.exit called ?
   ```
   
   Please note, all 2.x surefire plugin versions are affected of SUREFIRE-1588, 
hence it failed (unsure why IT uses 2.12.4 in the first place and not the built 
plugin).
   
   Surefire162CharsetProviderIT fails due this
   ```
   Caused by: org.apache.maven.project.DependencyResolutionException: Could not 
resolve dependencies for project 
org.apache.maven.surefire.its:surefire-162-charsetProvider:jar:1.0-SNAPSHOT: 
Could not find artifact jcharset:jcharset:jar:1.2.1 in central 
(https://repo.maven.apache.org/maven2/)
   ```
   
   And is right, there is no such thing.
   
   And finally the Surefire855 tests fails as they assert this
   
   ```
   Expected: a string containing "/target/jiras-surefire-855-jar-1.0.jar"
but: was 
"../../../../../../../../.m2/repository-oss/org/apache/maven/surefire/surefire-booter/3.0.0-M1-SNAPSHOT/surefire-booter-3.0.0-M1-SNAPSHOT.jar
 
../../../../../../../../.m2/repository-oss/org/apache/maven/surefire/surefire-api/3.0.0-M1-SNAPSHOT/surefire-api-3.0.0-M1-SNAPSHOT.jar
 
../../../../../../../../.m2/repository-oss/org/apache/maven/surefire/surefire-logger-api/3.0.0-M1-SNAPSHOT/surefire-logger-api-3.0.0-M1-SNAPSHOT.jar
 ../test-classes/ ../jiras-surefire-855-jar-1.0.jar 
../../../../../../../../.m2/repository-oss/junit/junit/4.11/junit-4.11.jar 
../../../../../../../../.m2/repository-oss/org/hamcrest/hamcrest-core/1.3/hamcrest-core-1.3.jar
 
../../../../../../../../.m2/repository-oss/org/easytesting/fest-assert-core/2.0M9/fest-assert-core-2.0M9.jar
 
../../../../../../../../.m2/repository-oss/org/easytesting/fest-util/1.2.4/fest-util-1.2.4.jar
 
../../../../../../../../.m2/repository-oss/org/hamcrest/hamcrest-library/1.3/hamcrest-library-1.3.jar
 
../../../../../../../../.m2/repository-oss/org/apache/maven/surefire/surefire-junit4/3.0.0-M1-SNAPSHOT/surefire-junit4-3.0.0-M1-SNAPSHOT.jar
 
../../../../../../../../.m2/repository-oss/org/apache/maven/surefire/common-java5/3.0.0-M1-SNAPSHOT/common-java5-3.0.0-M1-SNAPSHOT.jar
 
../../../../../../../../.m2/repository-oss/org/apache/maven/surefire/common-junit3/3.0.0-M1-SNAPSHOT/common-junit3-3.0.0-M1-SNAPSHOT.jar
 
../../../../../../../../.m2/repository-oss/org/apache/maven/surefire/common-junit4/3.0.0-M1-SNAPSHOT/common-junit4-3.0.0-M1-SNAPSHOT.jar
 
../../../../../../../../.m2/repository-oss/org/apache/maven/shared/maven-shared-utils/3.1.0/maven-shared-utils-3.1.0.jar"
   ```
   So, it is there but as relative URI `../jiras-surefire-855-jar-1.0.jar`.
   
   So all in all, I have no clue what is happening on master. In the mean time, 
I started ITs of this PR (so

[jira] [Commented] (SUREFIRE-1588) Surefire manifest jar classloading broken on latest Debian/Ubuntu Java8



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

ASF GitHub Bot commented on SUREFIRE-1588:
--

cstamas commented on issue #197: SUREFIRE-1588 Patch (Java7)
URL: https://github.com/apache/maven-surefire/pull/197#issuecomment-435497122
 
 
   @Tibor17 I ran locally ITs of the current master (on affected Linux with b13 
openjdk8), and I got totally different outcome: none of those ITs you mention 
failed, but instead I have:
   
   ```
   Results :
   
   Tests in error: 
 
jarShouldUseFile(org.apache.maven.surefire.its.jiras.Surefire855AllowFailsafeUseArtifactFileIT):
 Exit code was non-zero: 1; command line and log = (..)
 
warShouldUseClasses(org.apache.maven.surefire.its.jiras.Surefire855AllowFailsafeUseArtifactFileIT):
 Exit code was non-zero: 1; command line and log = (..)

osgiBundleShouldUseFile(org.apache.maven.surefire.its.jiras.Surefire855AllowFailsafeUseArtifactFileIT):
 Exit code was non-zero: 1; command line and log = (..)
 
testCharsetProvider(org.apache.maven.surefire.its.jiras.Surefire162CharsetProviderIT):
 Exit code was non-zero: 1; command line and log = (..)
 testSiblingAggregator(org.apache.maven.surefire.its.SiblingAggregatorIT): 
Exit code was non-zero: 1; command line and log = (..)
   
   Tests run: 780, Failures: 0, Errors: 5, Skipped: 138
   ```
   
   And the most interesting part: some ITs failed due SUREFIRE-1588! 
   
   For example, SUREFIRE-1588 causes 
org.apache.maven.surefire.its.SiblingAggregatorIT failure, produced traces like 
these:
   
   ```
   [ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-surefire-plugin:2.12.4:test (default-test) on 
project child2: Execution default-test of goal 
org.apache.maven.plugins:maven-surefire-plugin:2.12.4:test failed: The forked 
VM terminated without saying properly goodbye. VM crash or System.exit called ? 
-> [Help 1]
   org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute 
goal org.apache.maven.plugins:maven-surefire-plugin:2.12.4:test (default-test) 
on project child2: Execution default-test of goal 
org.apache.maven.plugins:maven-surefire-plugin:2.12.4:test failed: The forked 
VM terminated without saying properly goodbye. VM crash or System.exit called ?
   ```
   
   Please note, all 2.x surefire plugin versions are affected of SUREFIRE-1588, 
hence it failed (unsure why IT uses 2.12.4 in the first place and not the built 
plugin).
   
   Surefire162CharsetProviderIT fails due this
   ```
   Caused by: org.apache.maven.project.DependencyResolutionException: Could not 
resolve dependencies for project 
org.apache.maven.surefire.its:surefire-162-charsetProvider:jar:1.0-SNAPSHOT: 
Could not find artifact jcharset:jcharset:jar:1.2.1 in central 
(https://repo.maven.apache.org/maven2/)
   ``
   
   And is right, there is no such thing.
   
   And finally the Surefire855 tests fails as they assert this
   
   ```
   Expected: a string containing "/target/jiras-surefire-855-jar-1.0.jar"
but: was 
"../../../../../../../../.m2/repository-oss/org/apache/maven/surefire/surefire-booter/3.0.0-M1-SNAPSHOT/surefire-booter-3.0.0-M1-SNAPSHOT.jar
 
../../../../../../../../.m2/repository-oss/org/apache/maven/surefire/surefire-api/3.0.0-M1-SNAPSHOT/surefire-api-3.0.0-M1-SNAPSHOT.jar
 
../../../../../../../../.m2/repository-oss/org/apache/maven/surefire/surefire-logger-api/3.0.0-M1-SNAPSHOT/surefire-logger-api-3.0.0-M1-SNAPSHOT.jar
 ../test-classes/ ../jiras-surefire-855-jar-1.0.jar 
../../../../../../../../.m2/repository-oss/junit/junit/4.11/junit-4.11.jar 
../../../../../../../../.m2/repository-oss/org/hamcrest/hamcrest-core/1.3/hamcrest-core-1.3.jar
 
../../../../../../../../.m2/repository-oss/org/easytesting/fest-assert-core/2.0M9/fest-assert-core-2.0M9.jar
 
../../../../../../../../.m2/repository-oss/org/easytesting/fest-util/1.2.4/fest-util-1.2.4.jar
 
../../../../../../../../.m2/repository-oss/org/hamcrest/hamcrest-library/1.3/hamcrest-library-1.3.jar
 
../../../../../../../../.m2/repository-oss/org/apache/maven/surefire/surefire-junit4/3.0.0-M1-SNAPSHOT/surefire-junit4-3.0.0-M1-SNAPSHOT.jar
 
../../../../../../../../.m2/repository-oss/org/apache/maven/surefire/common-java5/3.0.0-M1-SNAPSHOT/common-java5-3.0.0-M1-SNAPSHOT.jar
 
../../../../../../../../.m2/repository-oss/org/apache/maven/surefire/common-junit3/3.0.0-M1-SNAPSHOT/common-junit3-3.0.0-M1-SNAPSHOT.jar
 
../../../../../../../../.m2/repository-oss/org/apache/maven/surefire/common-junit4/3.0.0-M1-SNAPSHOT/common-junit4-3.0.0-M1-SNAPSHOT.jar
 
../../../../../../../../.m2/repository-oss/org/apache/maven/shared/maven-shared-utils/3.1.0/maven-shared-utils-3.1.0.jar"
   ```
   So, it is there but as relative URI `../jiras-surefire-855-jar-1.0.jar`.
   
   So all in all, I have no clue what is happening on master. In the mean time, 
I started ITs of this PR (so 2.22.1+this

[jira] [Commented] (MJARSIGNER-58) Update maven-jarsigner dependency

2018-11-02 Thread Hudson (JIRA)



[ 
https://issues.apache.org/jira/browse/MJARSIGNER-58?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16673586#comment-16673586
 ] 

Hudson commented on MJARSIGNER-58:
--

Build succeeded in Jenkins: Maven TLP » maven-jarsigner-plugin » master #24

See 
https://builds.apache.org/job/maven-box/job/maven-jarsigner-plugin/job/master/24/

> Update maven-jarsigner dependency
> -
>
> Key: MJARSIGNER-58
> URL: https://issues.apache.org/jira/browse/MJARSIGNER-58
> Project: Maven Jar Signer Plugin
>  Issue Type: Dependency upgrade
>Reporter: Robert Scholte
>Assignee: Robert Scholte
>Priority: Major
> Fix For: 3.0.0
>
>




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

[jira] [Closed] (MJARSIGNER-58) Update maven-jarsigner dependency



 [ 
https://issues.apache.org/jira/browse/MJARSIGNER-58?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robert Scholte closed MJARSIGNER-58.

Resolution: Fixed

Fixed in 
[d9c8e009df9af93ba98454adad4f78f79af760bc|https://gitbox.apache.org/repos/asf?p=maven-jarsigner-plugin.git;a=commit;h=d9c8e009df9af93ba98454adad4f78f79af760bc]

> Update maven-jarsigner dependency
> -
>
> Key: MJARSIGNER-58
> URL: https://issues.apache.org/jira/browse/MJARSIGNER-58
> Project: Maven Jar Signer Plugin
>  Issue Type: Dependency upgrade
>Reporter: Robert Scholte
>Assignee: Robert Scholte
>Priority: Major
> Fix For: 3.0.0
>
>




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

[jira] [Closed] (MJARSIGNER-46) output STDOUT and STDERR on Windows as ERROR rather than INFO when there is an error



 [ 
https://issues.apache.org/jira/browse/MJARSIGNER-46?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robert Scholte closed MJARSIGNER-46.

Resolution: Cannot Reproduce
  Assignee: Robert Scholte

According to the integration tests failures are logged, marked as [ERROR] 

> output STDOUT and STDERR on Windows as ERROR rather than INFO when there is 
> an error
> 
>
> Key: MJARSIGNER-46
> URL: https://issues.apache.org/jira/browse/MJARSIGNER-46
> Project: Maven Jar Signer Plugin
>  Issue Type: New Feature
>Affects Versions: 1.4
> Environment: Windows
>Reporter: robert mundkowsky
>Assignee: Robert Scholte
>Priority: Minor
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> When jarsigner.exe has "exitcode 1", error output is logged as INFO.  I 
> thought it was not outputting the STDERR and STDOUT from the executable, but 
> I just noticed it is there as INFO rather than ERROR.  So when I was looking 
> for the ERROR details, I never looked up further in INFO and DEBUG lines, 
> because I thought thoses were reporting non-failure info.  Would be very 
> helpful to output stuff from jarsigner.exe has "exitcode 1" as ERROR when 
> there is an error.



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

[jira] [Updated] (MNG-6417) unable to print any colored text in netbeans using maven 3.5.3



 [ 
https://issues.apache.org/jira/browse/MNG-6417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Karl Heinz Marbaise updated MNG-6417:
-
Fix Version/s: waiting-for-feedback

> unable to print any colored text in netbeans using maven 3.5.3
> --
>
> Key: MNG-6417
> URL: https://issues.apache.org/jira/browse/MNG-6417
> Project: Maven
>  Issue Type: Bug
>Reporter: Peter
>Priority: Minor
> Fix For: waiting-for-feedback
>
>
> unable to print any colored text in netbeans using maven 3.5.3, i am using 
> these code to test
> {noformat}
> @Test
>  public void test() throws Exception {
>  String ANSI_RESET = "\u001B[0m";
>  String ANSI_RED = "\u001B[31m";
>  System.out.print(ANSI_RED + "XX");
>  System.out.flush();
>  System.out.println(ANSI_RESET);
>  System.out.println("\033[31;1mHello\033[0m, \033[32;1;2mworld!\033[0m");
>  System.out.println((char) 27 + "[31m" + "ERROR MESSAGE IN RED");
> // System.out.println((char) 27 + "[33mYELLOW");
>  AnsiConsole.systemInstall();
>  System.out.println(ansi().eraseScreen().render("@|red Hello|@ @|green 
> World|@"));
>  System.out.println(ansi().fg(GREEN).a("Hello").fg(BLUE).a(" World").reset());
>  }
> {noformat}



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

[jira] [Commented] (MNG-6417) unable to print any colored text in netbeans using maven 3.5.3



[ 
https://issues.apache.org/jira/browse/MNG-6417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16673567#comment-16673567
 ] 

Karl Heinz Marbaise commented on MNG-6417:
--

Can you please add an full example project which shows the issue...furthermore 
it looks like your test is trying to give some output to stdout ...the question 
is why do you like to output color to the console during a test?

> unable to print any colored text in netbeans using maven 3.5.3
> --
>
> Key: MNG-6417
> URL: https://issues.apache.org/jira/browse/MNG-6417
> Project: Maven
>  Issue Type: Bug
>Reporter: Peter
>Priority: Minor
> Fix For: waiting-for-feedback
>
>
> unable to print any colored text in netbeans using maven 3.5.3, i am using 
> these code to test
> {noformat}
> @Test
>  public void test() throws Exception {
>  String ANSI_RESET = "\u001B[0m";
>  String ANSI_RED = "\u001B[31m";
>  System.out.print(ANSI_RED + "XX");
>  System.out.flush();
>  System.out.println(ANSI_RESET);
>  System.out.println("\033[31;1mHello\033[0m, \033[32;1;2mworld!\033[0m");
>  System.out.println((char) 27 + "[31m" + "ERROR MESSAGE IN RED");
> // System.out.println((char) 27 + "[33mYELLOW");
>  AnsiConsole.systemInstall();
>  System.out.println(ansi().eraseScreen().render("@|red Hello|@ @|green 
> World|@"));
>  System.out.println(ansi().fg(GREEN).a("Hello").fg(BLUE).a(" World").reset());
>  }
> {noformat}



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

[jira] [Updated] (MNG-6417) unable to print any colored text in netbeans using maven 3.5.3



 [ 
https://issues.apache.org/jira/browse/MNG-6417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Karl Heinz Marbaise updated MNG-6417:
-
Priority: Minor  (was: Major)

> unable to print any colored text in netbeans using maven 3.5.3
> --
>
> Key: MNG-6417
> URL: https://issues.apache.org/jira/browse/MNG-6417
> Project: Maven
>  Issue Type: Bug
>Reporter: Peter
>Priority: Minor
>
> unable to print any colored text in netbeans using maven 3.5.3, i am using 
> these code to test
> {noformat}
> @Test
>  public void test() throws Exception {
>  String ANSI_RESET = "\u001B[0m";
>  String ANSI_RED = "\u001B[31m";
>  System.out.print(ANSI_RED + "XX");
>  System.out.flush();
>  System.out.println(ANSI_RESET);
>  System.out.println("\033[31;1mHello\033[0m, \033[32;1;2mworld!\033[0m");
>  System.out.println((char) 27 + "[31m" + "ERROR MESSAGE IN RED");
> // System.out.println((char) 27 + "[33mYELLOW");
>  AnsiConsole.systemInstall();
>  System.out.println(ansi().eraseScreen().render("@|red Hello|@ @|green 
> World|@"));
>  System.out.println(ansi().fg(GREEN).a("Hello").fg(BLUE).a(" World").reset());
>  }
> {noformat}



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

[jira] [Created] (MJARSIGNER-58) Update maven-jarsigner dependency

Robert Scholte created MJARSIGNER-58:


 Summary: Update maven-jarsigner dependency
 Key: MJARSIGNER-58
 URL: https://issues.apache.org/jira/browse/MJARSIGNER-58
 Project: Maven Jar Signer Plugin
  Issue Type: Dependency upgrade
Reporter: Robert Scholte
Assignee: Robert Scholte
 Fix For: 3.0.0






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

[jira] [Closed] (MNG-6455) ci-friendly version in parent pom displays build warning in child project



 [ 
https://issues.apache.org/jira/browse/MNG-6455?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Karl Heinz Marbaise closed MNG-6455.

Resolution: Cannot Reproduce

> ci-friendly version in parent pom displays build warning in child project
> -
>
> Key: MNG-6455
> URL: https://issues.apache.org/jira/browse/MNG-6455
> Project: Maven
>  Issue Type: Bug
>Reporter: Robert Thornton
>Priority: Minor
> Fix For: waiting-for-feedback
>
>
> I have a project that is using a parent project with ci-friendly versions, 
> but while Maven is scanning for projects, it is looking for 
> "my-parent-$%7Brevision%7D.pom" instead of "my-parent-1.0-a8e435".  The 
> project builds, but a warning is printed which confuses some of the teams 
> using my parent pom.
> {{[INFO] Scanning for projects...}}
> {{Downloading from mvn-lds: 
> https://code.myserver.org/artifactory/mvn-repo/my/stack/platform/my-parent/$%7Brevision%7D/my-parent-$%7Brevision%7D.pom}}
> {{[WARNING] Failed to build parent project for 
> my.stack.platform:my-project:pom:4.8.2.RELEASE}}
>  
> I've tracked the issue down to DefaultProjectBuilder, line 671 where 
> `project.getParentArtifact()` is returning an Artifact object with the 
> unresolved version.



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

[jira] [Commented] (MNG-6482) Artifactory returns oldest snapshot instead of newest



[ 
https://issues.apache.org/jira/browse/MNG-6482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16673555#comment-16673555
 ] 

Karl Heinz Marbaise commented on MNG-6482:
--

Can you please format the question otherwise it's really hard to read

> Artifactory returns oldest snapshot instead of newest
> -
>
> Key: MNG-6482
> URL: https://issues.apache.org/jira/browse/MNG-6482
> Project: Maven
>  Issue Type: Bug
>Reporter: Chandan
>Priority: Major
>
> Artifactory returns oldest snapshot instead of newest
> When repoA is built locally, it is not using the latest snapshot of repoB. It 
> uses the SNAPSHOT which was downloaded the first time. This is the case even 
> when repoA is built using -U maven flag: mvn -U clean install.
> The repoB SNAPSHOT is uploaded in the artifactory, but maven is not 
> downloading the latest SNAPSHOT to the local repository.
> Steps tried to resolve the issue:
> 1) Used -U to build repoA locally, which should force maven to check the 
> availability of latest snapshot. RESULT: Only the 
> maven-metadata-snapshots-local.xml is updated but the SNAPSHOT is not 
> downloaded.
> 2) executed rm -rf ~/.m2/repository/repoB/repoB/ to delete the local 
> repository which contains the repoB SNAPSHOT.RESULT: When repoA code is built 
> locally, maven is downloading the lastest SNAPSHOT of repoB.
> 3)Added  to both the build profiles present in repoA code 
> pom.xml file.*For intergration 
> profile*int-repository-internalhttp://maven.repoB.net/repository/internaltrueneverwarntruealwayswarn
> For wombat build 
> profilewombat-repository-internalhttp://maven.repoB.net/repository/internaltrueneverwarntruealwayswarnNo
>  luck.
> 4)Used  in repository id=snapshots-local in  
> section by changing the 
> following.truealwayswarnsnapshots-locallibs-snapshothttp://artifactory.devaws.repoB.net/artifactory/libs-snapshot-localNo
>  luck.
> 5)Used  in settings.xml by adding the 
> followinglocal-repotruealwayswarn
> No luck.



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

[jira] [Commented] (MNG-6484) reload empty/corrupted jars in m2 from central



[ 
https://issues.apache.org/jira/browse/MNG-6484?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16673553#comment-16673553
 ] 

Karl Heinz Marbaise commented on MNG-6484:
--

First thing as Michael already mentioned and I bet you don't have turned on 
checksum policy to fail...

> reload empty/corrupted jars in m2 from central
> --
>
> Key: MNG-6484
> URL: https://issues.apache.org/jira/browse/MNG-6484
> Project: Maven
>  Issue Type: Bug
>Affects Versions: 3.5.4
>Reporter: Daniil Iaitskov
>Priority: Minor
> Fix For: waiting-for-feedback
>
>
> I run mvn install when artifactory repository was not available.
> Maven created an empty jar for logback-core dependency.
> When you try to run build fails with error that some class is not found.
>  
>  



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

[jira] [Issue Comment Deleted] (MNG-6500) Dependency resolution broken with Java 11



 [ 
https://issues.apache.org/jira/browse/MNG-6500?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Karl Heinz Marbaise updated MNG-6500:
-
Comment: was deleted

(was: First I can't even compile the branch with JDK 11 which results in 
{code}
[ERROR] Failed to execute goal on project devon4j-rest: Could not resolve 
dependencies for project 
com.devonfw.java.modules:devon4j-rest:jar:3.0.0-SNAPSHOT: Failure to find 
org.openjfx:javafx.base:jar:11.0.0-SNAPSHOT in 
http://localhost:8081/nexus/content/groups/public was cached in the local 
repository, resolution will not be reattempted until the update interval of 
nexus has elapsed or updates are forced -> [Help 1]
[ERROR]
{code}
Is there any special setup needed to build it? Are there any profiles used? 
Apart from that I don't find any dependency to org.openjfx in any pom file? I 
can remember there was an thing related to JavaFX in JDK 11 which has been 
removed ?


)

> Dependency resolution broken with Java 11
> -
>
> Key: MNG-6500
> URL: https://issues.apache.org/jira/browse/MNG-6500
> Project: Maven
>  Issue Type: Bug
>Affects Versions: 3.5.4
> Environment: Java 11
>Reporter: Jörg Hohwiller
>Priority: Major
>
> I am facing an issue that some transitive dependencies are missing on maven 
> dependency resolution. This reproducible works fine with older Java (java8) 
> and always fails with java 11.
> The code that fails can be found in this feature branch:
> [https://github.com/hohwille/devon4j/tree/feature-16-java-11-build]
> A detailed description of the issue can be found here:
> [https://github.com/devonfw/devon4j/issues/16]
> It would be awesome if someone could have a look and make maven work smooth 
> with Java 11.



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

[jira] [Commented] (MNG-6500) Dependency resolution broken with Java 11



[ 
https://issues.apache.org/jira/browse/MNG-6500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16673550#comment-16673550
 ] 

Karl Heinz Marbaise commented on MNG-6500:
--

First I can't even compile the branch with JDK 11 which results in 
{code}
[ERROR] Failed to execute goal on project devon4j-rest: Could not resolve 
dependencies for project 
com.devonfw.java.modules:devon4j-rest:jar:3.0.0-SNAPSHOT: Failure to find 
org.openjfx:javafx.base:jar:11.0.0-SNAPSHOT in 
http://localhost:8081/nexus/content/groups/public was cached in the local 
repository, resolution will not be reattempted until the update interval of 
nexus has elapsed or updates are forced -> [Help 1]
[ERROR]
{code}
Is there any special setup needed to build it? Are there any profiles used? 
Apart from that I don't find any dependency to org.openjfx in any pom file? I 
can remember there was an thing related to JavaFX in JDK 11 which has been 
removed ?




> Dependency resolution broken with Java 11
> -
>
> Key: MNG-6500
> URL: https://issues.apache.org/jira/browse/MNG-6500
> Project: Maven
>  Issue Type: Bug
>Affects Versions: 3.5.4
> Environment: Java 11
>Reporter: Jörg Hohwiller
>Priority: Major
>
> I am facing an issue that some transitive dependencies are missing on maven 
> dependency resolution. This reproducible works fine with older Java (java8) 
> and always fails with java 11.
> The code that fails can be found in this feature branch:
> [https://github.com/hohwille/devon4j/tree/feature-16-java-11-build]
> A detailed description of the issue can be found here:
> [https://github.com/devonfw/devon4j/issues/16]
> It would be awesome if someone could have a look and make maven work smooth 
> with Java 11.



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

[jira] [Updated] (MNG-6501) Maven always picks the JRE path as java.home



 [ 
https://issues.apache.org/jira/browse/MNG-6501?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Karl Heinz Marbaise updated MNG-6501:
-
Priority: Minor  (was: Blocker)

> Maven always picks the JRE path as java.home
> 
>
> Key: MNG-6501
> URL: https://issues.apache.org/jira/browse/MNG-6501
> Project: Maven
>  Issue Type: Bug
>  Components: core
>Affects Versions: 3.2.3
>Reporter: Joseph
>Priority: Minor
> Attachments: maven_jdk.png
>
>
> we set the proper JDK directory as JAVA_HOME in the environment variable. but 
> the maven is forcefully picking up JRE_HOME.
> Even though the JAVA_HOME is pointing to the proper JDK path.
>  
> $ echo $JAVA_HOME
> */apps/dftjenkins/local/java/jdk1.8.0_102*
> $ ls -lrt ${JAVA_HOME}/bin/javac
> -rwxr-xr-x. 1 dftjenkins cisco 7941 Jun 22  2016 
> */apps/dftjenkins/local/java/jdk1.8.0_102/bin/javac*
> $ echo $M2_HOME
> /apps/dftjenkins/local/apache-maven/apache-maven-3.2.3
>  
> Maven is picking the JRE path as java.home
>  
> $ mvn -v
> Java HotSpot(TM) 64-Bit Server VM warning: ignoring option MaxPermSize=256m; 
> support was removed in 8.0
> Picked up _JAVA_OPTIONS: -Djava.io.tmpdir=/apps/dftjenkins/jenkins_node/tmp
> Apache Maven 3.2.3 (33f8c3e1027c3ddde99d3cdebad2656a31e8fdf4; 
> 2014-08-11T13:58:10-07:00)
> Maven home: /apps/dftjenkins/local/apache-maven/current
> Java version: 1.8.0_102, vendor: Oracle Corporation
> *Java home: /apps/dftjenkins/local/java/jdk1.8.0_102/jre*
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "3.10.0-693.11.6.el7.x86_64", arch: "amd64", 
> family: "unix"
>  This issue impact the ant call from maven execution . because java.home is 
> pointing to JRE_HOME and the ant compilation fails with 
>  
> [ERROR] Perhaps JAVA_HOME does not point to the JDK.
> [ERROR] It is currently set to "/apps/dftjenkins/local/java/jdk1.8.0_102/jre"
>  
>  



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

[jira] [Updated] (MNG-6503) parent pom relative path regression after 3.3.9



 [ 
https://issues.apache.org/jira/browse/MNG-6503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Karl Heinz Marbaise updated MNG-6503:
-
Priority: Critical  (was: Major)

> parent pom relative path regression after 3.3.9
> ---
>
> Key: MNG-6503
> URL: https://issues.apache.org/jira/browse/MNG-6503
> Project: Maven
>  Issue Type: Bug
>Affects Versions: 3.5.4, 3.6.0
> Environment: Windows 10, Java 8, fails with maven 3.5.4 and 3.6.0, 
> works with 3.3.9
>Reporter: Marshall Schor
>Priority: Critical
> Attachments: mvntst.zip
>
>
> Used to work in 3.3.9.  Failure to resolve parent-pom via relative-path in 
> some cases.
>   
>  A trivial example, with the folder structure and the poms. You
>  can see the failure by typing mvn help:effective-pom after cd'ing to the top
>  project's folder.
> Here's the folder structure:
> {noformat}
>  mvntst <- top folder
>     parent  <- subfolder having parent pom
>     subproj <- subfolder having a sub project
> {noformat}
> The 3 folders have a pom.xml:
> in mvntst folder (the top level folder)
> {code:xml}
> 
>  http://maven.apache.org/POM/4.0.0;
>      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
>      xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
>  [http://maven.apache.org/xsd/maven-4.0.0.xsd];>
>      4.0.0
>      mvntst
>      top
>      pom
>      
>          mvntst
>          parent
>          1.0.0
>          parent/pom.xml   
>      
>      
>        subproj
>      
>  
> {code}
> in parent subfolder:
> {code:xml}
> 
>  http://maven.apache.org/POM/4.0.0;
>      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
>      xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
>  [http://maven.apache.org/xsd/maven-4.0.0.xsd];>
>      4.0.0
>      mvntst
>      parent
>      1.0.0
>      pom
>  
> {code}
> in subproj subfolder:
> {code:xml}
> 
>  http://maven.apache.org/POM/4.0.0;
>      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
>      xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
>  [http://maven.apache.org/xsd/maven-4.0.0.xsd];>
>      4.0.0
>      mvntst
>      subproj
>      
>          mvntst
>          parent
>          1.0.0
>          ../parent/pom.xml    
>      
>  
> {code}
> In doing various tests: if the top pom is missing its relative-path, you get 
> an
>  expected
> {noformat}Non-resolvable parent POM for mvntst:top:[unknown-version]: Failure 
> to find
>  mvntst:parent:pom:1.0.0 ...{noformat}
> putting in the relative-path into the top fixes this, and results in finding 
> the
>  parent for the top level.
>  If you don't have a  section in the top level, the mvn
>  {{help:effective-pom}} works OK.
> Putting in the  section gives the error:
>  {noformat}Non-resolvable parent POM for mvntst:subproj:[unknown-version]: 
> Failure to find
>  mvntst:parent:pom:1.0.0{noformat}
> Adding the  to the artifact IDs for the top and subproj doesn't help,
>  except to change the error message to include the version instead of
>  [unknown-version]



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

[jira] [Commented] (MNG-6500) Dependency resolution broken with Java 11



[ 
https://issues.apache.org/jira/browse/MNG-6500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16673545#comment-16673545
 ] 

Karl Heinz Marbaise commented on MNG-6500:
--

Hi, unfortunately the branch can't be compiled with Java 11 cause of this:
{code}
[ERROR] Failed to execute goal on project devon4j-rest: Could not resolve 
dependencies for project 
com.devonfw.java.modules:devon4j-rest:jar:3.0.0-SNAPSHOT: Failure to find 
org.openjfx:javafx.base:jar:11.0.0-SNAPSHOT in 
http://localhost:8081/nexus/content/groups/public was cached in the local 
repository, resolution will not be reattempted until the update interval of 
nexus has elapsed or updates are forced -> [Help 1]
[ERROR]
{code}
JDK 10 works without any issue. Furthermore I don't find any dependency to 
openjfx but I can understand the failure cause with JDK 11 JavaFX has been 
removed from JDK 11...The question is: Do I need to do a special setup to build 
the project?  Does this build has any special profiles etc? 


> Dependency resolution broken with Java 11
> -
>
> Key: MNG-6500
> URL: https://issues.apache.org/jira/browse/MNG-6500
> Project: Maven
>  Issue Type: Bug
>Affects Versions: 3.5.4
> Environment: Java 11
>Reporter: Jörg Hohwiller
>Priority: Major
>
> I am facing an issue that some transitive dependencies are missing on maven 
> dependency resolution. This reproducible works fine with older Java (java8) 
> and always fails with java 11.
> The code that fails can be found in this feature branch:
> [https://github.com/hohwille/devon4j/tree/feature-16-java-11-build]
> A detailed description of the issue can be found here:
> [https://github.com/devonfw/devon4j/issues/16]
> It would be awesome if someone could have a look and make maven work smooth 
> with Java 11.



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

[jira] [Commented] (MNG-6502) More performant AbstractZipArchiver when maven module contains lots of big resources



[ 
https://issues.apache.org/jira/browse/MNG-6502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16673521#comment-16673521
 ] 

Karl Heinz Marbaise commented on MNG-6502:
--

Can explain more in detail the circumstances in particular if we are talking 
about big resources? Can you give particular number? And best would be having a 
test project which can reproduce the issue...Furthermore If I read the memory 
parts correctly this should be targeted to the 
[plexus-archiver|https://github.com/codehaus-plexus/plexus-archiver] project?

> More performant AbstractZipArchiver when maven module contains lots of big 
> resources
> 
>
> Key: MNG-6502
> URL: https://issues.apache.org/jira/browse/MNG-6502
> Project: Maven
>  Issue Type: Improvement
>Reporter: Hoa Phan
>Priority: Major
> Attachments: Screen Shot 2018-11-01 at 2.22.42 am.png, Screen Shot 
> 2018-11-01 at 2.25.22 am.png
>
>
> Consider process resources in parallel
>  
> !Screen Shot 2018-11-01 at 2.22.42 am.png!
> Consider flexible/adjustable buffer size for IOUtil.copy
> !Screen Shot 2018-11-01 at 2.25.22 am.png!



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

[jira] [Commented] (MNG-6239) jansi messes up System.err and System.out



[ 
https://issues.apache.org/jira/browse/MNG-6239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16673517#comment-16673517
 ] 

Karl Heinz Marbaise commented on MNG-6239:
--

Maven Release 3.6.0 contains jansi 1.17.1 ...is this still valid?

> jansi messes up System.err and System.out
> -
>
> Key: MNG-6239
> URL: https://issues.apache.org/jira/browse/MNG-6239
> Project: Maven
>  Issue Type: Bug
>  Components: core
>Affects Versions: 3.5.0
> Environment: Java 1.8.0_131, Ubuntu 17.04
>Reporter: Simone Bordet
>Priority: Minor
> Attachments: mvn-jansi.tgz
>
>
> I use the Maven Exec Plugin to run a class that asks for interactive input 
> from the user. This was working in 3.3.9, but does not work in 3.5.0.
> Anything printed on {{System.err}} or {{System.out}} without a newline is not 
> printed immediately on the terminal window.
> Example:
> {code:java}
> BufferedReader console = new BufferedReader(new InputStreamReader(System.in));
> System.err.printf("listen port: ");
> String value = console.readLine().trim();
> {code}
> The example above would not print {{listen port:}} on the terminal.
> Attached you can find a project that reproduces this issue.
> Unpack the project and then run:
> {noformat}
> $ mvn install && mvn exec:exec
> {noformat}
> The expected output of the reproducer would be:
> {noformat}
> err.println
> out.println
> err.printerr.printfout.printout.printf
> {noformat}
> instead I get:
> {noformat}
> err.println
> out.println
> {noformat}
> Removing {{jansi-1.13.jar}} from {{$MAVEN/lib/}} fixes the issue.



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

[jira] [Updated] (MNG-6239) jansi messes up System.err and System.out



 [ 
https://issues.apache.org/jira/browse/MNG-6239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Karl Heinz Marbaise updated MNG-6239:
-
Priority: Minor  (was: Major)

> jansi messes up System.err and System.out
> -
>
> Key: MNG-6239
> URL: https://issues.apache.org/jira/browse/MNG-6239
> Project: Maven
>  Issue Type: Bug
>  Components: core
>Affects Versions: 3.5.0
> Environment: Java 1.8.0_131, Ubuntu 17.04
>Reporter: Simone Bordet
>Priority: Minor
> Attachments: mvn-jansi.tgz
>
>
> I use the Maven Exec Plugin to run a class that asks for interactive input 
> from the user. This was working in 3.3.9, but does not work in 3.5.0.
> Anything printed on {{System.err}} or {{System.out}} without a newline is not 
> printed immediately on the terminal window.
> Example:
> {code:java}
> BufferedReader console = new BufferedReader(new InputStreamReader(System.in));
> System.err.printf("listen port: ");
> String value = console.readLine().trim();
> {code}
> The example above would not print {{listen port:}} on the terminal.
> Attached you can find a project that reproduces this issue.
> Unpack the project and then run:
> {noformat}
> $ mvn install && mvn exec:exec
> {noformat}
> The expected output of the reproducer would be:
> {noformat}
> err.println
> out.println
> err.printerr.printfout.printout.printf
> {noformat}
> instead I get:
> {noformat}
> err.println
> out.println
> {noformat}
> Removing {{jansi-1.13.jar}} from {{$MAVEN/lib/}} fixes the issue.



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

[jira] [Updated] (MNG-6239) jansi messes up System.err and System.out



 [ 
https://issues.apache.org/jira/browse/MNG-6239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Karl Heinz Marbaise updated MNG-6239:
-
Priority: Major  (was: Blocker)

> jansi messes up System.err and System.out
> -
>
> Key: MNG-6239
> URL: https://issues.apache.org/jira/browse/MNG-6239
> Project: Maven
>  Issue Type: Bug
>  Components: core
>Affects Versions: 3.5.0
> Environment: Java 1.8.0_131, Ubuntu 17.04
>Reporter: Simone Bordet
>Priority: Major
> Attachments: mvn-jansi.tgz
>
>
> I use the Maven Exec Plugin to run a class that asks for interactive input 
> from the user. This was working in 3.3.9, but does not work in 3.5.0.
> Anything printed on {{System.err}} or {{System.out}} without a newline is not 
> printed immediately on the terminal window.
> Example:
> {code:java}
> BufferedReader console = new BufferedReader(new InputStreamReader(System.in));
> System.err.printf("listen port: ");
> String value = console.readLine().trim();
> {code}
> The example above would not print {{listen port:}} on the terminal.
> Attached you can find a project that reproduces this issue.
> Unpack the project and then run:
> {noformat}
> $ mvn install && mvn exec:exec
> {noformat}
> The expected output of the reproducer would be:
> {noformat}
> err.println
> out.println
> err.printerr.printfout.printout.printf
> {noformat}
> instead I get:
> {noformat}
> err.println
> out.println
> {noformat}
> Removing {{jansi-1.13.jar}} from {{$MAVEN/lib/}} fixes the issue.



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

[jira] [Commented] (MNG-6501) Maven always picks the JRE path as java.home



[ 
https://issues.apache.org/jira/browse/MNG-6501?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16673509#comment-16673509
 ] 

Karl Heinz Marbaise commented on MNG-6501:
--

Hm..If I call a {{mvn --version}} on my Mac with Maven 3.6.0 it looks like this:
{code}
Apache Maven 3.6.0 (97c98ec64a1fdfee7767ce5ffb20918da4f719f3; 
2018-10-24T20:41:47+02:00)
Maven home: /usr/local/maven
Java version: 1.8.0_171, vendor: Oracle Corporation, runtime: 
/Library/Java/JavaVirtualMachines/jdk1.8.0_171.jdk/Contents/Home/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "mac os x", version: "10.11.6", arch: "x86_64", family: "mac"
{code}
It looks like it would point to JRE but I can compile and build etc. without 
any issue...

Furthermore can you please add a full log output {{mvn -X ..}} in the situation 
where your build failsApart from that I would recommend to remove the 
setting of {{M2_HOME}} in particular in Jenkins builds. Apart from that I would 
ask why you need to use Ant in a Maven build? Please add the pom file as 
well


> Maven always picks the JRE path as java.home
> 
>
> Key: MNG-6501
> URL: https://issues.apache.org/jira/browse/MNG-6501
> Project: Maven
>  Issue Type: Bug
>  Components: core
>Affects Versions: 3.2.3
>Reporter: Joseph
>Priority: Blocker
> Attachments: maven_jdk.png
>
>
> we set the proper JDK directory as JAVA_HOME in the environment variable. but 
> the maven is forcefully picking up JRE_HOME.
> Even though the JAVA_HOME is pointing to the proper JDK path.
>  
> $ echo $JAVA_HOME
> */apps/dftjenkins/local/java/jdk1.8.0_102*
> $ ls -lrt ${JAVA_HOME}/bin/javac
> -rwxr-xr-x. 1 dftjenkins cisco 7941 Jun 22  2016 
> */apps/dftjenkins/local/java/jdk1.8.0_102/bin/javac*
> $ echo $M2_HOME
> /apps/dftjenkins/local/apache-maven/apache-maven-3.2.3
>  
> Maven is picking the JRE path as java.home
>  
> $ mvn -v
> Java HotSpot(TM) 64-Bit Server VM warning: ignoring option MaxPermSize=256m; 
> support was removed in 8.0
> Picked up _JAVA_OPTIONS: -Djava.io.tmpdir=/apps/dftjenkins/jenkins_node/tmp
> Apache Maven 3.2.3 (33f8c3e1027c3ddde99d3cdebad2656a31e8fdf4; 
> 2014-08-11T13:58:10-07:00)
> Maven home: /apps/dftjenkins/local/apache-maven/current
> Java version: 1.8.0_102, vendor: Oracle Corporation
> *Java home: /apps/dftjenkins/local/java/jdk1.8.0_102/jre*
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "3.10.0-693.11.6.el7.x86_64", arch: "amd64", 
> family: "unix"
>  This issue impact the ant call from maven execution . because java.home is 
> pointing to JRE_HOME and the ant compilation fails with 
>  
> [ERROR] Perhaps JAVA_HOME does not point to the JDK.
> [ERROR] It is currently set to "/apps/dftjenkins/local/java/jdk1.8.0_102/jre"
>  
>  



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

[jira] [Issue Comment Deleted] (MNG-6261) Relative parent POM resolution failing in 3.5.0 with complex multimodule builds



 [ 
https://issues.apache.org/jira/browse/MNG-6261?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Karl Heinz Marbaise updated MNG-6261:
-
Comment: was deleted

(was: Build succeeded in Jenkins: Maven TLP » maven-remote-resources-plugin » 
MRRESOURCES-103 #23

See 
https://builds.apache.org/job/maven-box/job/maven-remote-resources-plugin/job/MRRESOURCES-103/23/)

> Relative parent POM resolution failing in 3.5.0 with complex multimodule 
> builds
> ---
>
> Key: MNG-6261
> URL: https://issues.apache.org/jira/browse/MNG-6261
> Project: Maven
>  Issue Type: Bug
>Affects Versions: 3.5.0
>Reporter: Dawid Weiss
>Assignee: Robert Scholte
>Priority: Minor
>  Labels: up-for-grabs
> Fix For: 3.6.x-candidate
>
> Attachments: capture-6.png, repro.zip
>
>
> In my effort to upgrade an existing (fairly complex) Maven build to Java 
> 1.9.0 I updated Maven to 3.5.0 (from 3.3.9). Unfortunately I get errors when 
> the project's modules are resolved:
> {noformat}
> > mvn validate
> [FATAL] Non-resolvable parent POM for 
> com.carrotsearch.lingo4g:lingo4g-public-bom:[unknown-version]: Could not find 
> artifact com.carrotsearch.lingo4g:lingo4g-public:pom:1.6.0-SNAPSHOT and 
> 'parent.relativePath' points at wrong local POM @ line 5, column 11
> ...
> (and many follow).
> {noformat}
> This build has a correct pom parent-structure (a tree), but is fairly complex 
> -- the submodule hierarchy is not aligned with parent-child pom hierarchy 
> (it's best to look at the repro code to understand how it's structured).
> However, it's been working correctly with all prior Maven versions and I 
> wonder if it's a regression bug or maybe underspecified Maven requirement 
> (that should be enforced with a warning and not lead to this odd runtime 
> message).



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

[jira] [Created] (MCHECKSTYLE-363) Upgrading checkstyle at runtime in multi modules configuration

2018-11-02 Thread Luc Maisonobe (JIRA)

Luc Maisonobe created MCHECKSTYLE-363:
-

 Summary: Upgrading checkstyle at runtime in multi modules 
configuration
 Key: MCHECKSTYLE-363
 URL: https://issues.apache.org/jira/browse/MCHECKSTYLE-363
 Project: Maven Checkstyle Plugin
  Issue Type: Improvement
Affects Versions: 3.0.0
Reporter: Luc Maisonobe


The documentation example "Upgrading Checkstyle at Runtime" shows how to

select another version of the underlying checkstyle tool, but it doesn't work in

multi-modules configuration.

The dependencies seem to not be inherited in multi-modules. With the 
documentation as

it exists now (for version 3.0.0, as of 2018-11-02), the checkstyle tool used 
by children modules is the default one (i.e. 6.18 for 3.0.0 or 6.1.1 for 2.17), 
and as the recent checkstyle tool configurations are incompatible with pre 8.0 
(mainly SuppressionCommentFilter which is now a child of TreeWalker), the build 
fails.

It would be nice to update the example documentation to add something like:

    Note that in multi-modules configuration, putting the above setting in 
parent pom
   pluginManagement is not sufficient because dependencies are not inherited. 
The
   ... must be copied in the pom of all modules. Also 
as
  the  section does not allow dependency settings, the
  dependency settings must be set in a 
... section in the children 
pom.



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

[jira] [Commented] (SUREFIRE-1588) Surefire manifest jar classloading broken on latest Debian/Ubuntu Java8



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

ASF GitHub Bot commented on SUREFIRE-1588:
--

Tibor17 commented on issue #197: SUREFIRE-1588 Patch (Java7)
URL: https://github.com/apache/maven-surefire/pull/197#issuecomment-435438509
 
 
   The problem is that `TEST-TestSuite.xml` appears in wrong folder and it 
should be in `target/surefire-reports-1` and 2. Not sure how this change could 
influence the reports dir and resolution of it.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Surefire manifest jar classloading broken on latest Debian/Ubuntu Java8
> ---
>
> Key: SUREFIRE-1588
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1588
> Project: Maven Surefire
>  Issue Type: Bug
>Affects Versions: 2.22.1
>Reporter: Cservenak, Tamas
>Assignee: Tibor Digana
>Priority: Major
> Fix For: 3.0.0-M1
>
>
> See issue [1], but in short: latest Java8 on Ubuntu/Debian/Mint family of 
> Linuxes (am on Mint, Ubuntu derivative) contains this patch [3], and eforces 
> Manifest class path entries to be relative, as defined in [2].
> Hence, surefire booter and rest of Maven classpath, that uses absolute URLs 
> are simply discarded.
> Example error:
> {noformat}
> # Created at 2018-10-30T21:34:43.339
> Error: Could not find or load main class 
> org.apache.maven.surefire.booter.ForkedBooter{noformat}
> using the new property 
> {{-Djdk.net.URLClassPath.disableClassPathURLCheck=debug}} clearly shows that 
> all the entries from the surefire JAR are simply ignored.
>  
> [1] [https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911925]
> [2] 
> https://docs.oracle.com/javase/8/docs/technotes/guides/jar/jar.html#classpath
> [3] [https://hg.openjdk.java.net/jdk/jdk/rev/27135de165ac]



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

[GitHub] Tibor17 commented on issue #197: SUREFIRE-1588 Patch (Java7)

Tibor17 commented on issue #197: SUREFIRE-1588 Patch (Java7)
URL: https://github.com/apache/maven-surefire/pull/197#issuecomment-435438509
 
 
   The problem is that `TEST-TestSuite.xml` appears in wrong folder and it 
should be in `target/surefire-reports-1` and 2. Not sure how this change could 
influence the reports dir and resolution of it.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[jira] [Commented] (SUREFIRE-1588) Surefire manifest jar classloading broken on latest Debian/Ubuntu Java8



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

ASF GitHub Bot commented on SUREFIRE-1588:
--

Tibor17 commented on issue #197: SUREFIRE-1588 Patch (Java7)
URL: https://github.com/apache/maven-surefire/pull/197#issuecomment-435436625
 
 
   @cstamas 
   I think nobody run the ITs on this PR. The problem is that we broke the 
build with this fix.
   There are two failing ITs.
   The first one `Surefire141PluggableProvidersIT` can be fixed easily if we 
comment the dump logger. The test got two dump files and it expects one, which 
is the error. Or fix it in the IT would not be a problem.
   The second is bad `Surefire1535TestNGParallelSuitesIT`and I do not 
understand it. So, please help.
   See this dump file 
`surefire-its\target\Surefire1535TestNGParallelSuitesIT_forks2Redirected\target\surefire-reports-${surefire.forkNumber}\2018-11-02T17-13-42_917.dump`
   # Created at 2018-11-02T17:13:43.787
   Boot Manifest-JAR contains absolute paths in classpath 
D:\.m2\repository\org\apache\maven\surefire\surefire-api\3.0.0-M2-SNAPSHOT\surefire-api-3.0.0-M2-SNAPSHOT.jar
   java.lang.IllegalArgumentException: 'other' has different root
at sun.nio.fs.WindowsPath.relativize(WindowsPath.java:392)
at sun.nio.fs.WindowsPath.relativize(WindowsPath.java:44)
at 
org.apache.maven.plugin.surefire.booterclient.JarManifestForkConfiguration.toClasspathElementUri(JarManifestForkConfiguration.java:147)
at 
org.apache.maven.plugin.surefire.booterclient.JarManifestForkConfiguration.createJar(JarManifestForkConfiguration.java:117)
at 
org.apache.maven.plugin.surefire.booterclient.JarManifestForkConfiguration.resolveClasspath(JarManifestForkConfiguration.java:73)
at 
org.apache.maven.plugin.surefire.booterclient.DefaultForkConfiguration.createCommandLine(DefaultForkConfiguration.java:143)
at 
org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:579)
at 
org.apache.maven.plugin.surefire.booterclient.ForkStarter.access$600(ForkStarter.java:115)
at 
org.apache.maven.plugin.surefire.booterclient.ForkStarter$2.call(ForkStarter.java:444)
at 
org.apache.maven.plugin.surefire.booterclient.ForkStarter$2.call(ForkStarter.java:420)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
   
   I am inhurry with other appointments. Feel free to investigate. If you want 
to fix it, feel free, but please run the `mvn install -P run-its` and then make 
a commit to master or better a branch.
   I do not understand this stack trace. I hope you know what is going on.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Surefire manifest jar classloading broken on latest Debian/Ubuntu Java8
> ---
>
> Key: SUREFIRE-1588
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1588
> Project: Maven Surefire
>  Issue Type: Bug
>Affects Versions: 2.22.1
>Reporter: Cservenak, Tamas
>Assignee: Tibor Digana
>Priority: Major
> Fix For: 3.0.0-M1
>
>
> See issue [1], but in short: latest Java8 on Ubuntu/Debian/Mint family of 
> Linuxes (am on Mint, Ubuntu derivative) contains this patch [3], and eforces 
> Manifest class path entries to be relative, as defined in [2].
> Hence, surefire booter and rest of Maven classpath, that uses absolute URLs 
> are simply discarded.
> Example error:
> {noformat}
> # Created at 2018-10-30T21:34:43.339
> Error: Could not find or load main class 
> org.apache.maven.surefire.booter.ForkedBooter{noformat}
> using the new property 
> {{-Djdk.net.URLClassPath.disableClassPathURLCheck=debug}} clearly shows that 
> all the entries from the surefire JAR are simply ignored.
>  
> [1] [https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911925]
> [2] 
> https://docs.oracle.com/javase/8/docs/technotes/guides/jar/jar.html#classpath
> [3] [https://hg.openjdk.java.net/jdk/jdk/rev/27135de165ac]



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

[GitHub] Tibor17 commented on issue #197: SUREFIRE-1588 Patch (Java7)

Tibor17 commented on issue #197: SUREFIRE-1588 Patch (Java7)
URL: https://github.com/apache/maven-surefire/pull/197#issuecomment-435436625

@cstamas
I think nobody run the ITs on this PR. The problem is that we broke the
build with this fix.
There are two failing ITs.
The first one `Surefire141PluggableProvidersIT` can be fixed easily if we
comment the dump logger. The test got two dump files and it expects one, which
is the error. Or fix it in the IT would not be a problem.
The second is bad `Surefire1535TestNGParallelSuitesIT`and I do not
understand it. So, please help.
See this dump file
`surefire-its\target\Surefire1535TestNGParallelSuitesIT_forks2Redirected\target\surefire-reports-${surefire.forkNumber}\2018-11-02T17-13-42_917.dump`
# Created at 2018-11-02T17:13:43.787
Boot Manifest-JAR contains absolute paths in classpath
D:\.m2\repository\org\apache\maven\surefire\surefire-api\3.0.0-M2-SNAPSHOT\surefire-api-3.0.0-M2-SNAPSHOT.jar
java.lang.IllegalArgumentException: 'other' has different root
at sun.nio.fs.WindowsPath.relativize(WindowsPath.java:392)
at sun.nio.fs.WindowsPath.relativize(WindowsPath.java:44)
at
org.apache.maven.plugin.surefire.booterclient.JarManifestForkConfiguration.toClasspathElementUri(JarManifestForkConfiguration.java:147)
at
org.apache.maven.plugin.surefire.booterclient.JarManifestForkConfiguration.createJar(JarManifestForkConfiguration.java:117)
at
org.apache.maven.plugin.surefire.booterclient.JarManifestForkConfiguration.resolveClasspath(JarManifestForkConfiguration.java:73)
at
org.apache.maven.plugin.surefire.booterclient.DefaultForkConfiguration.createCommandLine(DefaultForkConfiguration.java:143)
at
org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:579)
at
org.apache.maven.plugin.surefire.booterclient.ForkStarter.access$600(ForkStarter.java:115)
at
org.apache.maven.plugin.surefire.booterclient.ForkStarter$2.call(ForkStarter.java:444)
at
org.apache.maven.plugin.surefire.booterclient.ForkStarter$2.call(ForkStarter.java:420)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)

I am inhurry with other appointments. Feel free to investigate. If you want
to fix it, feel free, but please run the `mvn install -P run-its` and then make
a commit to master or better a branch.
I do not understand this stack trace. I hope you know what is going on.

This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

With regards,
Apache Git Services

[jira] [Commented] (SUREFIRE-1588) Surefire manifest jar classloading broken on latest Debian/Ubuntu Java8



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

ASF GitHub Bot commented on SUREFIRE-1588:
--

Tibor17 commented on issue #197: SUREFIRE-1588 Patch (Java7)
URL: https://github.com/apache/maven-surefire/pull/197#issuecomment-435419279
 
 
   @mirabilos 
   I understand, but MRESOURCES-237 is a problem of symbolic links in 
maven-resources-plugin. Nothing to do with us in my understanding. Do not 
worry, we are running 1400 tests on multiple platforms, so the likelihood 
should not be high.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Surefire manifest jar classloading broken on latest Debian/Ubuntu Java8
> ---
>
> Key: SUREFIRE-1588
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1588
> Project: Maven Surefire
>  Issue Type: Bug
>Affects Versions: 2.22.1
>Reporter: Cservenak, Tamas
>Assignee: Tibor Digana
>Priority: Major
> Fix For: 3.0.0-M1
>
>
> See issue [1], but in short: latest Java8 on Ubuntu/Debian/Mint family of 
> Linuxes (am on Mint, Ubuntu derivative) contains this patch [3], and eforces 
> Manifest class path entries to be relative, as defined in [2].
> Hence, surefire booter and rest of Maven classpath, that uses absolute URLs 
> are simply discarded.
> Example error:
> {noformat}
> # Created at 2018-10-30T21:34:43.339
> Error: Could not find or load main class 
> org.apache.maven.surefire.booter.ForkedBooter{noformat}
> using the new property 
> {{-Djdk.net.URLClassPath.disableClassPathURLCheck=debug}} clearly shows that 
> all the entries from the surefire JAR are simply ignored.
>  
> [1] [https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911925]
> [2] 
> https://docs.oracle.com/javase/8/docs/technotes/guides/jar/jar.html#classpath
> [3] [https://hg.openjdk.java.net/jdk/jdk/rev/27135de165ac]



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

[GitHub] Tibor17 commented on issue #197: SUREFIRE-1588 Patch (Java7)

Tibor17 commented on issue #197: SUREFIRE-1588 Patch (Java7)
URL: https://github.com/apache/maven-surefire/pull/197#issuecomment-435419279
 
 
   @mirabilos 
   I understand, but MRESOURCES-237 is a problem of symbolic links in 
maven-resources-plugin. Nothing to do with us in my understanding. Do not 
worry, we are running 1400 tests on multiple platforms, so the likelihood 
should not be high.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[jira] [Commented] (SUREFIRE-1588) Surefire manifest jar classloading broken on latest Debian/Ubuntu Java8



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

ASF GitHub Bot commented on SUREFIRE-1588:
--

cstamas commented on issue #197: SUREFIRE-1588 Patch (Java7)
URL: https://github.com/apache/maven-surefire/pull/197#issuecomment-435416391
 
 
   @Tibor17 Tested 3.0.0-M1 on my machine, and it is OK.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Surefire manifest jar classloading broken on latest Debian/Ubuntu Java8
> ---
>
> Key: SUREFIRE-1588
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1588
> Project: Maven Surefire
>  Issue Type: Bug
>Affects Versions: 2.22.1
>Reporter: Cservenak, Tamas
>Assignee: Tibor Digana
>Priority: Major
> Fix For: 3.0.0-M1
>
>
> See issue [1], but in short: latest Java8 on Ubuntu/Debian/Mint family of 
> Linuxes (am on Mint, Ubuntu derivative) contains this patch [3], and eforces 
> Manifest class path entries to be relative, as defined in [2].
> Hence, surefire booter and rest of Maven classpath, that uses absolute URLs 
> are simply discarded.
> Example error:
> {noformat}
> # Created at 2018-10-30T21:34:43.339
> Error: Could not find or load main class 
> org.apache.maven.surefire.booter.ForkedBooter{noformat}
> using the new property 
> {{-Djdk.net.URLClassPath.disableClassPathURLCheck=debug}} clearly shows that 
> all the entries from the surefire JAR are simply ignored.
>  
> [1] [https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911925]
> [2] 
> https://docs.oracle.com/javase/8/docs/technotes/guides/jar/jar.html#classpath
> [3] [https://hg.openjdk.java.net/jdk/jdk/rev/27135de165ac]



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

[GitHub] cstamas commented on issue #197: SUREFIRE-1588 Patch (Java7)

cstamas commented on issue #197: SUREFIRE-1588 Patch (Java7)
URL: https://github.com/apache/maven-surefire/pull/197#issuecomment-435416391
 
 
   @Tibor17 Tested 3.0.0-M1 on my machine, and it is OK.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[jira] [Commented] (SUREFIRE-1588) Surefire manifest jar classloading broken on latest Debian/Ubuntu Java8

2018-11-02 Thread Cservenak, Tamas (JIRA)



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

Cservenak, Tamas commented on SUREFIRE-1588:


Tested staged 3.0.0-M1 and it works fine on my machine (where I spotted 
initially the issue).

Linux Mint 19 + openjdk 8 (8u181-b13-1ubuntu0.18.04.1)

Cool beans!

> Surefire manifest jar classloading broken on latest Debian/Ubuntu Java8
> ---
>
> Key: SUREFIRE-1588
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1588
> Project: Maven Surefire
>  Issue Type: Bug
>Affects Versions: 2.22.1
>Reporter: Cservenak, Tamas
>Assignee: Tibor Digana
>Priority: Major
> Fix For: 3.0.0-M1
>
>
> See issue [1], but in short: latest Java8 on Ubuntu/Debian/Mint family of 
> Linuxes (am on Mint, Ubuntu derivative) contains this patch [3], and eforces 
> Manifest class path entries to be relative, as defined in [2].
> Hence, surefire booter and rest of Maven classpath, that uses absolute URLs 
> are simply discarded.
> Example error:
> {noformat}
> # Created at 2018-10-30T21:34:43.339
> Error: Could not find or load main class 
> org.apache.maven.surefire.booter.ForkedBooter{noformat}
> using the new property 
> {{-Djdk.net.URLClassPath.disableClassPathURLCheck=debug}} clearly shows that 
> all the entries from the surefire JAR are simply ignored.
>  
> [1] [https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911925]
> [2] 
> https://docs.oracle.com/javase/8/docs/technotes/guides/jar/jar.html#classpath
> [3] [https://hg.openjdk.java.net/jdk/jdk/rev/27135de165ac]



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

[jira] [Commented] (SUREFIRE-1588) Surefire manifest jar classloading broken on latest Debian/Ubuntu Java8



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

ASF GitHub Bot commented on SUREFIRE-1588:
--

mirabilos commented on issue #197: SUREFIRE-1588 Patch (Java7)
URL: https://github.com/apache/maven-surefire/pull/197#issuecomment-435410915
 
 
   > You can check it out now from our staging repo 
https://repository.apache.org/content/repositories/maven-1463. See the guide to 
testing staged releases 
http://maven.apache.org/guides/development/guide-testing-releases.html
   
   Ah thanks, I was trying to figure that out, but did not get as far.
   
   Yes, I can confirm that the snapshot version `3.0.0-M1` fixes this 
particular issue. (Meaning we’ll switch to a 3.0.0 release once that’s there.)
   
   I’m a bit wary of major upgrades though, due to unwelcome surprises such as 
the still-unfixed `MRESOURCES-237`. That’s why I was asking whether anything 
else would change as part of the 2.x → 3.x switch.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Surefire manifest jar classloading broken on latest Debian/Ubuntu Java8
> ---
>
> Key: SUREFIRE-1588
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1588
> Project: Maven Surefire
>  Issue Type: Bug
>Affects Versions: 2.22.1
>Reporter: Cservenak, Tamas
>Assignee: Tibor Digana
>Priority: Major
> Fix For: 3.0.0-M1
>
>
> See issue [1], but in short: latest Java8 on Ubuntu/Debian/Mint family of 
> Linuxes (am on Mint, Ubuntu derivative) contains this patch [3], and eforces 
> Manifest class path entries to be relative, as defined in [2].
> Hence, surefire booter and rest of Maven classpath, that uses absolute URLs 
> are simply discarded.
> Example error:
> {noformat}
> # Created at 2018-10-30T21:34:43.339
> Error: Could not find or load main class 
> org.apache.maven.surefire.booter.ForkedBooter{noformat}
> using the new property 
> {{-Djdk.net.URLClassPath.disableClassPathURLCheck=debug}} clearly shows that 
> all the entries from the surefire JAR are simply ignored.
>  
> [1] [https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911925]
> [2] 
> https://docs.oracle.com/javase/8/docs/technotes/guides/jar/jar.html#classpath
> [3] [https://hg.openjdk.java.net/jdk/jdk/rev/27135de165ac]



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

[GitHub] mirabilos commented on issue #197: SUREFIRE-1588 Patch (Java7)

mirabilos commented on issue #197: SUREFIRE-1588 Patch (Java7)
URL: https://github.com/apache/maven-surefire/pull/197#issuecomment-435410915
 
 
   > You can check it out now from our staging repo 
https://repository.apache.org/content/repositories/maven-1463. See the guide to 
testing staged releases 
http://maven.apache.org/guides/development/guide-testing-releases.html
   
   Ah thanks, I was trying to figure that out, but did not get as far.
   
   Yes, I can confirm that the snapshot version `3.0.0-M1` fixes this 
particular issue. (Meaning we’ll switch to a 3.0.0 release once that’s there.)
   
   I’m a bit wary of major upgrades though, due to unwelcome surprises such as 
the still-unfixed `MRESOURCES-237`. That’s why I was asking whether anything 
else would change as part of the 2.x → 3.x switch.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[jira] [Closed] (SUREFIRE-1588) Surefire manifest jar classloading broken on latest Debian/Ubuntu Java8



 [ 
https://issues.apache.org/jira/browse/SUREFIRE-1588?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tibor Digana closed SUREFIRE-1588.
--
Resolution: Fixed

https://gitbox.apache.org/repos/asf?p=maven-surefire.git;a=commit;h=9dab1bfdd9864e1c9cc5e076b6a72f5d1a915937

> Surefire manifest jar classloading broken on latest Debian/Ubuntu Java8
> ---
>
> Key: SUREFIRE-1588
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1588
> Project: Maven Surefire
>  Issue Type: Bug
>Affects Versions: 2.22.1
>Reporter: Cservenak, Tamas
>Assignee: Tibor Digana
>Priority: Major
> Fix For: 3.0.0-M1
>
>
> See issue [1], but in short: latest Java8 on Ubuntu/Debian/Mint family of 
> Linuxes (am on Mint, Ubuntu derivative) contains this patch [3], and eforces 
> Manifest class path entries to be relative, as defined in [2].
> Hence, surefire booter and rest of Maven classpath, that uses absolute URLs 
> are simply discarded.
> Example error:
> {noformat}
> # Created at 2018-10-30T21:34:43.339
> Error: Could not find or load main class 
> org.apache.maven.surefire.booter.ForkedBooter{noformat}
> using the new property 
> {{-Djdk.net.URLClassPath.disableClassPathURLCheck=debug}} clearly shows that 
> all the entries from the surefire JAR are simply ignored.
>  
> [1] [https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911925]
> [2] 
> https://docs.oracle.com/javase/8/docs/technotes/guides/jar/jar.html#classpath
> [3] [https://hg.openjdk.java.net/jdk/jdk/rev/27135de165ac]



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

[jira] [Commented] (SUREFIRE-1588) Surefire manifest jar classloading broken on latest Debian/Ubuntu Java8



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

ASF GitHub Bot commented on SUREFIRE-1588:
--

Tibor17 commented on issue #197: SUREFIRE-1588 Patch (Java7)
URL: https://github.com/apache/maven-surefire/pull/197#issuecomment-435405583
 
 
   @mirabilos 
   You can check it out now from our staging repo 
https://repository.apache.org/content/repositories/maven-1463. See the guide to 
testing staged releases 
http://maven.apache.org/guides/development/guide-testing-releases.html


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Surefire manifest jar classloading broken on latest Debian/Ubuntu Java8
> ---
>
> Key: SUREFIRE-1588
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1588
> Project: Maven Surefire
>  Issue Type: Bug
>Affects Versions: 2.22.1
>Reporter: Cservenak, Tamas
>Assignee: Tibor Digana
>Priority: Major
> Fix For: 3.0.0-M1
>
>
> See issue [1], but in short: latest Java8 on Ubuntu/Debian/Mint family of 
> Linuxes (am on Mint, Ubuntu derivative) contains this patch [3], and eforces 
> Manifest class path entries to be relative, as defined in [2].
> Hence, surefire booter and rest of Maven classpath, that uses absolute URLs 
> are simply discarded.
> Example error:
> {noformat}
> # Created at 2018-10-30T21:34:43.339
> Error: Could not find or load main class 
> org.apache.maven.surefire.booter.ForkedBooter{noformat}
> using the new property 
> {{-Djdk.net.URLClassPath.disableClassPathURLCheck=debug}} clearly shows that 
> all the entries from the surefire JAR are simply ignored.
>  
> [1] [https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911925]
> [2] 
> https://docs.oracle.com/javase/8/docs/technotes/guides/jar/jar.html#classpath
> [3] [https://hg.openjdk.java.net/jdk/jdk/rev/27135de165ac]



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

[GitHub] Tibor17 commented on issue #197: SUREFIRE-1588 Patch (Java7)

Tibor17 commented on issue #197: SUREFIRE-1588 Patch (Java7)
URL: https://github.com/apache/maven-surefire/pull/197#issuecomment-435405583
 
 
   @mirabilos 
   You can check it out now from our staging repo 
https://repository.apache.org/content/repositories/maven-1463. See the guide to 
testing staged releases 
http://maven.apache.org/guides/development/guide-testing-releases.html


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[jira] [Commented] (SUREFIRE-1588) Surefire manifest jar classloading broken on latest Debian/Ubuntu Java8



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

ASF GitHub Bot commented on SUREFIRE-1588:
--

Tibor17 edited a comment on issue #197: SUREFIRE-1588 Patch (Java7)
URL: https://github.com/apache/maven-surefire/pull/197#issuecomment-435397200
 
 
   @mirabilos 
   It will take 3 days or longer. Sorry, this is the process of Vote for the 
release. So you are welcome to join our mailing list and Vote there for this 
release. I understand how urgent it is for you but this is not my decision that 
you will wait till next week.
   The version 3.0.0-M1 will be available in ASF Nexus. So you can use it from 
there but it is not Central repo.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Surefire manifest jar classloading broken on latest Debian/Ubuntu Java8
> ---
>
> Key: SUREFIRE-1588
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1588
> Project: Maven Surefire
>  Issue Type: Bug
>Affects Versions: 2.22.1
>Reporter: Cservenak, Tamas
>Assignee: Tibor Digana
>Priority: Major
> Fix For: 3.0.0-M1
>
>
> See issue [1], but in short: latest Java8 on Ubuntu/Debian/Mint family of 
> Linuxes (am on Mint, Ubuntu derivative) contains this patch [3], and eforces 
> Manifest class path entries to be relative, as defined in [2].
> Hence, surefire booter and rest of Maven classpath, that uses absolute URLs 
> are simply discarded.
> Example error:
> {noformat}
> # Created at 2018-10-30T21:34:43.339
> Error: Could not find or load main class 
> org.apache.maven.surefire.booter.ForkedBooter{noformat}
> using the new property 
> {{-Djdk.net.URLClassPath.disableClassPathURLCheck=debug}} clearly shows that 
> all the entries from the surefire JAR are simply ignored.
>  
> [1] [https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911925]
> [2] 
> https://docs.oracle.com/javase/8/docs/technotes/guides/jar/jar.html#classpath
> [3] [https://hg.openjdk.java.net/jdk/jdk/rev/27135de165ac]



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

[GitHub] Tibor17 edited a comment on issue #197: SUREFIRE-1588 Patch (Java7)

Tibor17 edited a comment on issue #197: SUREFIRE-1588 Patch (Java7)
URL: https://github.com/apache/maven-surefire/pull/197#issuecomment-435397200
 
 
   @mirabilos 
   It will take 3 days or longer. Sorry, this is the process of Vote for the 
release. So you are welcome to join our mailing list and Vote there for this 
release. I understand how urgent it is for you but this is not my decision that 
you will wait till next week.
   The version 3.0.0-M1 will be available in ASF Nexus. So you can use it from 
there but it is not Central repo.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[jira] [Commented] (SUREFIRE-1588) Surefire manifest jar classloading broken on latest Debian/Ubuntu Java8



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

ASF GitHub Bot commented on SUREFIRE-1588:
--

Tibor17 commented on issue #197: SUREFIRE-1588 Patch (Java7)
URL: https://github.com/apache/maven-surefire/pull/197#issuecomment-435397200
 
 
   @mirabilos 
   It will take 3 days or longer. Sorry, this is the process of Vote for the 
release. So you are welcome to join our mailing list and Vote there for this 
release. I understand how urgent it is for you but this is not my decision that 
you will wait till next week.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Surefire manifest jar classloading broken on latest Debian/Ubuntu Java8
> ---
>
> Key: SUREFIRE-1588
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1588
> Project: Maven Surefire
>  Issue Type: Bug
>Affects Versions: 2.22.1
>Reporter: Cservenak, Tamas
>Assignee: Tibor Digana
>Priority: Major
> Fix For: 3.0.0-M1
>
>
> See issue [1], but in short: latest Java8 on Ubuntu/Debian/Mint family of 
> Linuxes (am on Mint, Ubuntu derivative) contains this patch [3], and eforces 
> Manifest class path entries to be relative, as defined in [2].
> Hence, surefire booter and rest of Maven classpath, that uses absolute URLs 
> are simply discarded.
> Example error:
> {noformat}
> # Created at 2018-10-30T21:34:43.339
> Error: Could not find or load main class 
> org.apache.maven.surefire.booter.ForkedBooter{noformat}
> using the new property 
> {{-Djdk.net.URLClassPath.disableClassPathURLCheck=debug}} clearly shows that 
> all the entries from the surefire JAR are simply ignored.
>  
> [1] [https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911925]
> [2] 
> https://docs.oracle.com/javase/8/docs/technotes/guides/jar/jar.html#classpath
> [3] [https://hg.openjdk.java.net/jdk/jdk/rev/27135de165ac]



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

[GitHub] Tibor17 commented on issue #197: SUREFIRE-1588 Patch (Java7)

Tibor17 commented on issue #197: SUREFIRE-1588 Patch (Java7)
URL: https://github.com/apache/maven-surefire/pull/197#issuecomment-435397200
 
 
   @mirabilos 
   It will take 3 days or longer. Sorry, this is the process of Vote for the 
release. So you are welcome to join our mailing list and Vote there for this 
release. I understand how urgent it is for you but this is not my decision that 
you will wait till next week.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[jira] [Commented] (SUREFIRE-1588) Surefire manifest jar classloading broken on latest Debian/Ubuntu Java8



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

ASF GitHub Bot commented on SUREFIRE-1588:
--

mirabilos commented on issue #197: SUREFIRE-1588 Patch (Java7)
URL: https://github.com/apache/maven-surefire/pull/197#issuecomment-435396229
 
 
   Please ping back when the release (and which ``) is published and 
available from Central, I can test it. (I’m testing a JDK patch in parallel, so 
I have a test env set up.)


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Surefire manifest jar classloading broken on latest Debian/Ubuntu Java8
> ---
>
> Key: SUREFIRE-1588
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1588
> Project: Maven Surefire
>  Issue Type: Bug
>Affects Versions: 2.22.1
>Reporter: Cservenak, Tamas
>Assignee: Tibor Digana
>Priority: Major
> Fix For: 3.0.0-M1
>
>
> See issue [1], but in short: latest Java8 on Ubuntu/Debian/Mint family of 
> Linuxes (am on Mint, Ubuntu derivative) contains this patch [3], and eforces 
> Manifest class path entries to be relative, as defined in [2].
> Hence, surefire booter and rest of Maven classpath, that uses absolute URLs 
> are simply discarded.
> Example error:
> {noformat}
> # Created at 2018-10-30T21:34:43.339
> Error: Could not find or load main class 
> org.apache.maven.surefire.booter.ForkedBooter{noformat}
> using the new property 
> {{-Djdk.net.URLClassPath.disableClassPathURLCheck=debug}} clearly shows that 
> all the entries from the surefire JAR are simply ignored.
>  
> [1] [https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911925]
> [2] 
> https://docs.oracle.com/javase/8/docs/technotes/guides/jar/jar.html#classpath
> [3] [https://hg.openjdk.java.net/jdk/jdk/rev/27135de165ac]



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

[GitHub] mirabilos commented on issue #197: SUREFIRE-1588 Patch (Java7)

mirabilos commented on issue #197: SUREFIRE-1588 Patch (Java7)
URL: https://github.com/apache/maven-surefire/pull/197#issuecomment-435396229
 
 
   Please ping back when the release (and which ``) is published and 
available from Central, I can test it. (I’m testing a JDK patch in parallel, so 
I have a test env set up.)


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[jira] [Commented] (SUREFIRE-1588) Surefire manifest jar classloading broken on latest Debian/Ubuntu Java8



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

ASF GitHub Bot commented on SUREFIRE-1588:
--

Tibor17 commented on issue #197: SUREFIRE-1588 Patch (Java7)
URL: https://github.com/apache/maven-surefire/pull/197#issuecomment-435394570
 
 
   @cstamas 
   It's in master. The log dump was added too.
   I will cut the release.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Surefire manifest jar classloading broken on latest Debian/Ubuntu Java8
> ---
>
> Key: SUREFIRE-1588
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1588
> Project: Maven Surefire
>  Issue Type: Bug
>Affects Versions: 2.22.1
>Reporter: Cservenak, Tamas
>Assignee: Tibor Digana
>Priority: Major
> Fix For: 3.0.0-M1
>
>
> See issue [1], but in short: latest Java8 on Ubuntu/Debian/Mint family of 
> Linuxes (am on Mint, Ubuntu derivative) contains this patch [3], and eforces 
> Manifest class path entries to be relative, as defined in [2].
> Hence, surefire booter and rest of Maven classpath, that uses absolute URLs 
> are simply discarded.
> Example error:
> {noformat}
> # Created at 2018-10-30T21:34:43.339
> Error: Could not find or load main class 
> org.apache.maven.surefire.booter.ForkedBooter{noformat}
> using the new property 
> {{-Djdk.net.URLClassPath.disableClassPathURLCheck=debug}} clearly shows that 
> all the entries from the surefire JAR are simply ignored.
>  
> [1] [https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911925]
> [2] 
> https://docs.oracle.com/javase/8/docs/technotes/guides/jar/jar.html#classpath
> [3] [https://hg.openjdk.java.net/jdk/jdk/rev/27135de165ac]



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

[GitHub] Tibor17 commented on issue #197: SUREFIRE-1588 Patch (Java7)

Tibor17 commented on issue #197: SUREFIRE-1588 Patch (Java7)
URL: https://github.com/apache/maven-surefire/pull/197#issuecomment-435394570
 
 
   @cstamas 
   It's in master. The log dump was added too.
   I will cut the release.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[jira] [Assigned] (SUREFIRE-1588) Surefire manifest jar classloading broken on latest Debian/Ubuntu Java8



 [ 
https://issues.apache.org/jira/browse/SUREFIRE-1588?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tibor Digana reassigned SUREFIRE-1588:
--

Assignee: Tibor Digana

> Surefire manifest jar classloading broken on latest Debian/Ubuntu Java8
> ---
>
> Key: SUREFIRE-1588
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1588
> Project: Maven Surefire
>  Issue Type: Bug
>Affects Versions: 2.22.1
>Reporter: Cservenak, Tamas
>Assignee: Tibor Digana
>Priority: Major
> Fix For: 3.0.0-M1
>
>
> See issue [1], but in short: latest Java8 on Ubuntu/Debian/Mint family of 
> Linuxes (am on Mint, Ubuntu derivative) contains this patch [3], and eforces 
> Manifest class path entries to be relative, as defined in [2].
> Hence, surefire booter and rest of Maven classpath, that uses absolute URLs 
> are simply discarded.
> Example error:
> {noformat}
> # Created at 2018-10-30T21:34:43.339
> Error: Could not find or load main class 
> org.apache.maven.surefire.booter.ForkedBooter{noformat}
> using the new property 
> {{-Djdk.net.URLClassPath.disableClassPathURLCheck=debug}} clearly shows that 
> all the entries from the surefire JAR are simply ignored.
>  
> [1] [https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911925]
> [2] 
> https://docs.oracle.com/javase/8/docs/technotes/guides/jar/jar.html#classpath
> [3] [https://hg.openjdk.java.net/jdk/jdk/rev/27135de165ac]



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

[jira] [Updated] (SUREFIRE-1588) Surefire manifest jar classloading broken on latest Debian/Ubuntu Java8



 [ 
https://issues.apache.org/jira/browse/SUREFIRE-1588?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tibor Digana updated SUREFIRE-1588:
---
Fix Version/s: 3.0.0-M1

> Surefire manifest jar classloading broken on latest Debian/Ubuntu Java8
> ---
>
> Key: SUREFIRE-1588
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1588
> Project: Maven Surefire
>  Issue Type: Bug
>Affects Versions: 2.22.1
>Reporter: Cservenak, Tamas
>Assignee: Tibor Digana
>Priority: Major
> Fix For: 3.0.0-M1
>
>
> See issue [1], but in short: latest Java8 on Ubuntu/Debian/Mint family of 
> Linuxes (am on Mint, Ubuntu derivative) contains this patch [3], and eforces 
> Manifest class path entries to be relative, as defined in [2].
> Hence, surefire booter and rest of Maven classpath, that uses absolute URLs 
> are simply discarded.
> Example error:
> {noformat}
> # Created at 2018-10-30T21:34:43.339
> Error: Could not find or load main class 
> org.apache.maven.surefire.booter.ForkedBooter{noformat}
> using the new property 
> {{-Djdk.net.URLClassPath.disableClassPathURLCheck=debug}} clearly shows that 
> all the entries from the surefire JAR are simply ignored.
>  
> [1] [https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911925]
> [2] 
> https://docs.oracle.com/javase/8/docs/technotes/guides/jar/jar.html#classpath
> [3] [https://hg.openjdk.java.net/jdk/jdk/rev/27135de165ac]



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

[jira] [Commented] (SUREFIRE-1588) Surefire manifest jar classloading broken on latest Debian/Ubuntu Java8



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

ASF GitHub Bot commented on SUREFIRE-1588:
--

cstamas commented on issue #197: SUREFIRE-1588 Patch (Java7)
URL: https://github.com/apache/maven-surefire/pull/197#issuecomment-435387194
 
 
   I just removed the log :)
   
   But go ahead, I dont want to stall


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Surefire manifest jar classloading broken on latest Debian/Ubuntu Java8
> ---
>
> Key: SUREFIRE-1588
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1588
> Project: Maven Surefire
>  Issue Type: Bug
>Affects Versions: 2.22.1
>Reporter: Cservenak, Tamas
>Priority: Major
>
> See issue [1], but in short: latest Java8 on Ubuntu/Debian/Mint family of 
> Linuxes (am on Mint, Ubuntu derivative) contains this patch [3], and eforces 
> Manifest class path entries to be relative, as defined in [2].
> Hence, surefire booter and rest of Maven classpath, that uses absolute URLs 
> are simply discarded.
> Example error:
> {noformat}
> # Created at 2018-10-30T21:34:43.339
> Error: Could not find or load main class 
> org.apache.maven.surefire.booter.ForkedBooter{noformat}
> using the new property 
> {{-Djdk.net.URLClassPath.disableClassPathURLCheck=debug}} clearly shows that 
> all the entries from the surefire JAR are simply ignored.
>  
> [1] [https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911925]
> [2] 
> https://docs.oracle.com/javase/8/docs/technotes/guides/jar/jar.html#classpath
> [3] [https://hg.openjdk.java.net/jdk/jdk/rev/27135de165ac]



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

[GitHub] cstamas commented on issue #197: SUREFIRE-1588 Patch (Java7)

cstamas commented on issue #197: SUREFIRE-1588 Patch (Java7)
URL: https://github.com/apache/maven-surefire/pull/197#issuecomment-435387194
 
 
   I just removed the log :)
   
   But go ahead, I dont want to stall


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[jira] [Commented] (SUREFIRE-1588) Surefire manifest jar classloading broken on latest Debian/Ubuntu Java8



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

ASF GitHub Bot commented on SUREFIRE-1588:
--

Tibor17 commented on issue #197: SUREFIRE-1588 Patch (Java7)
URL: https://github.com/apache/maven-surefire/pull/197#issuecomment-435386856
 
 
   @cstamas I have already done it in my working copy. Is it necessary to log 
it? I removed the log because of what i wrote. But I can accept any of your 
decision of course.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Surefire manifest jar classloading broken on latest Debian/Ubuntu Java8
> ---
>
> Key: SUREFIRE-1588
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1588
> Project: Maven Surefire
>  Issue Type: Bug
>Affects Versions: 2.22.1
>Reporter: Cservenak, Tamas
>Priority: Major
>
> See issue [1], but in short: latest Java8 on Ubuntu/Debian/Mint family of 
> Linuxes (am on Mint, Ubuntu derivative) contains this patch [3], and eforces 
> Manifest class path entries to be relative, as defined in [2].
> Hence, surefire booter and rest of Maven classpath, that uses absolute URLs 
> are simply discarded.
> Example error:
> {noformat}
> # Created at 2018-10-30T21:34:43.339
> Error: Could not find or load main class 
> org.apache.maven.surefire.booter.ForkedBooter{noformat}
> using the new property 
> {{-Djdk.net.URLClassPath.disableClassPathURLCheck=debug}} clearly shows that 
> all the entries from the surefire JAR are simply ignored.
>  
> [1] [https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911925]
> [2] 
> https://docs.oracle.com/javase/8/docs/technotes/guides/jar/jar.html#classpath
> [3] [https://hg.openjdk.java.net/jdk/jdk/rev/27135de165ac]



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

[jira] [Commented] (SUREFIRE-1588) Surefire manifest jar classloading broken on latest Debian/Ubuntu Java8



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

ASF GitHub Bot commented on SUREFIRE-1588:
--

fischey commented on issue #197: SUREFIRE-1588 Patch (Java7)
URL: https://github.com/apache/maven-surefire/pull/197#issuecomment-435386698
 
 
   Details to the Problem from the openJdK bugtracker can be found here: 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911925
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Surefire manifest jar classloading broken on latest Debian/Ubuntu Java8
> ---
>
> Key: SUREFIRE-1588
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1588
> Project: Maven Surefire
>  Issue Type: Bug
>Affects Versions: 2.22.1
>Reporter: Cservenak, Tamas
>Priority: Major
>
> See issue [1], but in short: latest Java8 on Ubuntu/Debian/Mint family of 
> Linuxes (am on Mint, Ubuntu derivative) contains this patch [3], and eforces 
> Manifest class path entries to be relative, as defined in [2].
> Hence, surefire booter and rest of Maven classpath, that uses absolute URLs 
> are simply discarded.
> Example error:
> {noformat}
> # Created at 2018-10-30T21:34:43.339
> Error: Could not find or load main class 
> org.apache.maven.surefire.booter.ForkedBooter{noformat}
> using the new property 
> {{-Djdk.net.URLClassPath.disableClassPathURLCheck=debug}} clearly shows that 
> all the entries from the surefire JAR are simply ignored.
>  
> [1] [https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911925]
> [2] 
> https://docs.oracle.com/javase/8/docs/technotes/guides/jar/jar.html#classpath
> [3] [https://hg.openjdk.java.net/jdk/jdk/rev/27135de165ac]



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

[GitHub] Tibor17 commented on issue #197: SUREFIRE-1588 Patch (Java7)

Tibor17 commented on issue #197: SUREFIRE-1588 Patch (Java7)
URL: https://github.com/apache/maven-surefire/pull/197#issuecomment-435386856
 
 
   @cstamas I have already done it in my working copy. Is it necessary to log 
it? I removed the log because of what i wrote. But I can accept any of your 
decision of course.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] fischey commented on issue #197: SUREFIRE-1588 Patch (Java7)

fischey commented on issue #197: SUREFIRE-1588 Patch (Java7)
URL: https://github.com/apache/maven-surefire/pull/197#issuecomment-435386698
 
 
   Details to the Problem from the openJdK bugtracker can be found here: 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911925
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[jira] [Commented] (SUREFIRE-1588) Surefire manifest jar classloading broken on latest Debian/Ubuntu Java8



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

ASF GitHub Bot commented on SUREFIRE-1588:
--

cstamas commented on issue #197: SUREFIRE-1588 Patch (Java7)
URL: https://github.com/apache/maven-surefire/pull/197#issuecomment-435386084
 
 
   @Tibor17 So, do you want the changes you asked or you are fine? (priv 
method, logging changes, etc)?


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Surefire manifest jar classloading broken on latest Debian/Ubuntu Java8
> ---
>
> Key: SUREFIRE-1588
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1588
> Project: Maven Surefire
>  Issue Type: Bug
>Affects Versions: 2.22.1
>Reporter: Cservenak, Tamas
>Priority: Major
>
> See issue [1], but in short: latest Java8 on Ubuntu/Debian/Mint family of 
> Linuxes (am on Mint, Ubuntu derivative) contains this patch [3], and eforces 
> Manifest class path entries to be relative, as defined in [2].
> Hence, surefire booter and rest of Maven classpath, that uses absolute URLs 
> are simply discarded.
> Example error:
> {noformat}
> # Created at 2018-10-30T21:34:43.339
> Error: Could not find or load main class 
> org.apache.maven.surefire.booter.ForkedBooter{noformat}
> using the new property 
> {{-Djdk.net.URLClassPath.disableClassPathURLCheck=debug}} clearly shows that 
> all the entries from the surefire JAR are simply ignored.
>  
> [1] [https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911925]
> [2] 
> https://docs.oracle.com/javase/8/docs/technotes/guides/jar/jar.html#classpath
> [3] [https://hg.openjdk.java.net/jdk/jdk/rev/27135de165ac]



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

[GitHub] cstamas commented on issue #197: SUREFIRE-1588 Patch (Java7)

cstamas commented on issue #197: SUREFIRE-1588 Patch (Java7)
URL: https://github.com/apache/maven-surefire/pull/197#issuecomment-435386084
 
 
   @Tibor17 So, do you want the changes you asked or you are fine? (priv 
method, logging changes, etc)?


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[jira] [Commented] (SUREFIRE-1588) Surefire manifest jar classloading broken on latest Debian/Ubuntu Java8



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

ASF GitHub Bot commented on SUREFIRE-1588:
--

Tibor17 commented on issue #197: SUREFIRE-1588 Patch (Java7)
URL: https://github.com/apache/maven-surefire/pull/197#issuecomment-435384927
 
 
   ok, I am just running a local build and I will push it to master in few 
minutes only and then I will start the release Vote. Hoping this helps.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Surefire manifest jar classloading broken on latest Debian/Ubuntu Java8
> ---
>
> Key: SUREFIRE-1588
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1588
> Project: Maven Surefire
>  Issue Type: Bug
>Affects Versions: 2.22.1
>Reporter: Cservenak, Tamas
>Priority: Major
>
> See issue [1], but in short: latest Java8 on Ubuntu/Debian/Mint family of 
> Linuxes (am on Mint, Ubuntu derivative) contains this patch [3], and eforces 
> Manifest class path entries to be relative, as defined in [2].
> Hence, surefire booter and rest of Maven classpath, that uses absolute URLs 
> are simply discarded.
> Example error:
> {noformat}
> # Created at 2018-10-30T21:34:43.339
> Error: Could not find or load main class 
> org.apache.maven.surefire.booter.ForkedBooter{noformat}
> using the new property 
> {{-Djdk.net.URLClassPath.disableClassPathURLCheck=debug}} clearly shows that 
> all the entries from the surefire JAR are simply ignored.
>  
> [1] [https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911925]
> [2] 
> https://docs.oracle.com/javase/8/docs/technotes/guides/jar/jar.html#classpath
> [3] [https://hg.openjdk.java.net/jdk/jdk/rev/27135de165ac]



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

[GitHub] Tibor17 commented on issue #197: SUREFIRE-1588 Patch (Java7)

Tibor17 commented on issue #197: SUREFIRE-1588 Patch (Java7)
URL: https://github.com/apache/maven-surefire/pull/197#issuecomment-435384927
 
 
   ok, I am just running a local build and I will push it to master in few 
minutes only and then I will start the release Vote. Hoping this helps.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[jira] [Commented] (SUREFIRE-1588) Surefire manifest jar classloading broken on latest Debian/Ubuntu Java8



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

ASF GitHub Bot commented on SUREFIRE-1588:
--

mirabilos commented on issue #197: SUREFIRE-1588 Patch (Java7)
URL: https://github.com/apache/maven-surefire/pull/197#issuecomment-435384329
 
 
   > @mirabilos
   > We did not break your build. It was change of behavior in JDK itself as 
many other changes since of Java 9 and we only react on these changes one or 
two years.
   
   I know that. I was just asking whether upgrading from 2.x to 3.x will break 
anything except Java 6.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Surefire manifest jar classloading broken on latest Debian/Ubuntu Java8
> ---
>
> Key: SUREFIRE-1588
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1588
> Project: Maven Surefire
>  Issue Type: Bug
>Affects Versions: 2.22.1
>Reporter: Cservenak, Tamas
>Priority: Major
>
> See issue [1], but in short: latest Java8 on Ubuntu/Debian/Mint family of 
> Linuxes (am on Mint, Ubuntu derivative) contains this patch [3], and eforces 
> Manifest class path entries to be relative, as defined in [2].
> Hence, surefire booter and rest of Maven classpath, that uses absolute URLs 
> are simply discarded.
> Example error:
> {noformat}
> # Created at 2018-10-30T21:34:43.339
> Error: Could not find or load main class 
> org.apache.maven.surefire.booter.ForkedBooter{noformat}
> using the new property 
> {{-Djdk.net.URLClassPath.disableClassPathURLCheck=debug}} clearly shows that 
> all the entries from the surefire JAR are simply ignored.
>  
> [1] [https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911925]
> [2] 
> https://docs.oracle.com/javase/8/docs/technotes/guides/jar/jar.html#classpath
> [3] [https://hg.openjdk.java.net/jdk/jdk/rev/27135de165ac]



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

[GitHub] mirabilos commented on issue #197: SUREFIRE-1588 Patch (Java7)

mirabilos commented on issue #197: SUREFIRE-1588 Patch (Java7)
URL: https://github.com/apache/maven-surefire/pull/197#issuecomment-435384329
 
 
   > @mirabilos
   > We did not break your build. It was change of behavior in JDK itself as 
many other changes since of Java 9 and we only react on these changes one or 
two years.
   
   I know that. I was just asking whether upgrading from 2.x to 3.x will break 
anything except Java 6.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[jira] [Commented] (SUREFIRE-1588) Surefire manifest jar classloading broken on latest Debian/Ubuntu Java8



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

ASF GitHub Bot commented on SUREFIRE-1588:
--

Github user asfgit closed the pull request at:

https://github.com/apache/brooklyn-dist/pull/127


> Surefire manifest jar classloading broken on latest Debian/Ubuntu Java8
> ---
>
> Key: SUREFIRE-1588
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1588
> Project: Maven Surefire
>  Issue Type: Bug
>Affects Versions: 2.22.1
>Reporter: Cservenak, Tamas
>Priority: Major
>
> See issue [1], but in short: latest Java8 on Ubuntu/Debian/Mint family of 
> Linuxes (am on Mint, Ubuntu derivative) contains this patch [3], and eforces 
> Manifest class path entries to be relative, as defined in [2].
> Hence, surefire booter and rest of Maven classpath, that uses absolute URLs 
> are simply discarded.
> Example error:
> {noformat}
> # Created at 2018-10-30T21:34:43.339
> Error: Could not find or load main class 
> org.apache.maven.surefire.booter.ForkedBooter{noformat}
> using the new property 
> {{-Djdk.net.URLClassPath.disableClassPathURLCheck=debug}} clearly shows that 
> all the entries from the surefire JAR are simply ignored.
>  
> [1] [https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911925]
> [2] 
> https://docs.oracle.com/javase/8/docs/technotes/guides/jar/jar.html#classpath
> [3] [https://hg.openjdk.java.net/jdk/jdk/rev/27135de165ac]



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

[jira] [Commented] (SUREFIRE-1588) Surefire manifest jar classloading broken on latest Debian/Ubuntu Java8



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

ASF GitHub Bot commented on SUREFIRE-1588:
--

Github user tbouron commented on the issue:

https://github.com/apache/brooklyn-dist/pull/127
  
Same as the others, fixes up the build. Thanks @kemitix  



> Surefire manifest jar classloading broken on latest Debian/Ubuntu Java8
> ---
>
> Key: SUREFIRE-1588
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1588
> Project: Maven Surefire
>  Issue Type: Bug
>Affects Versions: 2.22.1
>Reporter: Cservenak, Tamas
>Priority: Major
>
> See issue [1], but in short: latest Java8 on Ubuntu/Debian/Mint family of 
> Linuxes (am on Mint, Ubuntu derivative) contains this patch [3], and eforces 
> Manifest class path entries to be relative, as defined in [2].
> Hence, surefire booter and rest of Maven classpath, that uses absolute URLs 
> are simply discarded.
> Example error:
> {noformat}
> # Created at 2018-10-30T21:34:43.339
> Error: Could not find or load main class 
> org.apache.maven.surefire.booter.ForkedBooter{noformat}
> using the new property 
> {{-Djdk.net.URLClassPath.disableClassPathURLCheck=debug}} clearly shows that 
> all the entries from the surefire JAR are simply ignored.
>  
> [1] [https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911925]
> [2] 
> https://docs.oracle.com/javase/8/docs/technotes/guides/jar/jar.html#classpath
> [3] [https://hg.openjdk.java.net/jdk/jdk/rev/27135de165ac]



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

[jira] [Commented] (SUREFIRE-1588) Surefire manifest jar classloading broken on latest Debian/Ubuntu Java8



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

ASF GitHub Bot commented on SUREFIRE-1588:
--

Tibor17 commented on issue #197: SUREFIRE-1588 Patch (Java7)
URL: https://github.com/apache/maven-surefire/pull/197#issuecomment-435381394
 
 
   Are there any objections if I proceed with pushing the fix to master?
   Can somebody run a test?
   
   @mirabilos 
   We are not waiting for 3.0. It is already in master. It is not a blocker.
   We are updating all Maven plugins to 3.0 because we have to and there there 
is no problem to accept it. We did not break your build. It was change of 
behavior in JDK itself as many other changes since of Java 9 and we only react 
on these changes one or two years.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Surefire manifest jar classloading broken on latest Debian/Ubuntu Java8
> ---
>
> Key: SUREFIRE-1588
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1588
> Project: Maven Surefire
>  Issue Type: Bug
>Affects Versions: 2.22.1
>Reporter: Cservenak, Tamas
>Priority: Major
>
> See issue [1], but in short: latest Java8 on Ubuntu/Debian/Mint family of 
> Linuxes (am on Mint, Ubuntu derivative) contains this patch [3], and eforces 
> Manifest class path entries to be relative, as defined in [2].
> Hence, surefire booter and rest of Maven classpath, that uses absolute URLs 
> are simply discarded.
> Example error:
> {noformat}
> # Created at 2018-10-30T21:34:43.339
> Error: Could not find or load main class 
> org.apache.maven.surefire.booter.ForkedBooter{noformat}
> using the new property 
> {{-Djdk.net.URLClassPath.disableClassPathURLCheck=debug}} clearly shows that 
> all the entries from the surefire JAR are simply ignored.
>  
> [1] [https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911925]
> [2] 
> https://docs.oracle.com/javase/8/docs/technotes/guides/jar/jar.html#classpath
> [3] [https://hg.openjdk.java.net/jdk/jdk/rev/27135de165ac]



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

[GitHub] Tibor17 commented on issue #197: SUREFIRE-1588 Patch (Java7)

Tibor17 commented on issue #197: SUREFIRE-1588 Patch (Java7)
URL: https://github.com/apache/maven-surefire/pull/197#issuecomment-435381394
 
 
   Are there any objections if I proceed with pushing the fix to master?
   Can somebody run a test?
   
   @mirabilos 
   We are not waiting for 3.0. It is already in master. It is not a blocker.
   We are updating all Maven plugins to 3.0 because we have to and there there 
is no problem to accept it. We did not break your build. It was change of 
behavior in JDK itself as many other changes since of Java 9 and we only react 
on these changes one or two years.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[jira] [Commented] (SUREFIRE-1588) Surefire manifest jar classloading broken on latest Debian/Ubuntu Java8



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

ASF GitHub Bot commented on SUREFIRE-1588:
--

mirabilos commented on issue #197: SUREFIRE-1588 Patch (Java7)
URL: https://github.com/apache/maven-surefire/pull/197#issuecomment-435371608
 
 
   > Why this issue does not exist on Windows?
   
   The issue is caused by a bad backport of some new security features from 
OpenJDK via JDK 10 to JDK 8 in Debian, by the Ubuntu-employed maintainer and 
the Debian security team.
   
   There are a couple new checks for JAR files, and one of them triggers the 
issue. According to someone who analysed the OpenJDK upstream changes, the 
OpenJDK team later disabled that new check by default, but this did not get 
backported to Debian.
   
   So I expect that OpenJDK itself will enable the new check some time in the 
future, at which point it will fail everywhere. For now, it only fails on 
Debian and derivatives, and it’s extremely unlucky that this change was 
forcefully pushed even onto stable release users prematurely, under the 
umbrella of security fixes and “a deliberate upstream change”.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Surefire manifest jar classloading broken on latest Debian/Ubuntu Java8
> ---
>
> Key: SUREFIRE-1588
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1588
> Project: Maven Surefire
>  Issue Type: Bug
>Affects Versions: 2.22.1
>Reporter: Cservenak, Tamas
>Priority: Major
>
> See issue [1], but in short: latest Java8 on Ubuntu/Debian/Mint family of 
> Linuxes (am on Mint, Ubuntu derivative) contains this patch [3], and eforces 
> Manifest class path entries to be relative, as defined in [2].
> Hence, surefire booter and rest of Maven classpath, that uses absolute URLs 
> are simply discarded.
> Example error:
> {noformat}
> # Created at 2018-10-30T21:34:43.339
> Error: Could not find or load main class 
> org.apache.maven.surefire.booter.ForkedBooter{noformat}
> using the new property 
> {{-Djdk.net.URLClassPath.disableClassPathURLCheck=debug}} clearly shows that 
> all the entries from the surefire JAR are simply ignored.
>  
> [1] [https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911925]
> [2] 
> https://docs.oracle.com/javase/8/docs/technotes/guides/jar/jar.html#classpath
> [3] [https://hg.openjdk.java.net/jdk/jdk/rev/27135de165ac]



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

[GitHub] mirabilos commented on issue #197: SUREFIRE-1588 Patch (Java7)

mirabilos commented on issue #197: SUREFIRE-1588 Patch (Java7)
URL: https://github.com/apache/maven-surefire/pull/197#issuecomment-435371608
 
 
   > Why this issue does not exist on Windows?
   
   The issue is caused by a bad backport of some new security features from 
OpenJDK via JDK 10 to JDK 8 in Debian, by the Ubuntu-employed maintainer and 
the Debian security team.
   
   There are a couple new checks for JAR files, and one of them triggers the 
issue. According to someone who analysed the OpenJDK upstream changes, the 
OpenJDK team later disabled that new check by default, but this did not get 
backported to Debian.
   
   So I expect that OpenJDK itself will enable the new check some time in the 
future, at which point it will fail everywhere. For now, it only fails on 
Debian and derivatives, and it’s extremely unlucky that this change was 
forcefully pushed even onto stable release users prematurely, under the 
umbrella of security fixes and “a deliberate upstream change”.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[jira] [Commented] (SUREFIRE-1588) Surefire manifest jar classloading broken on latest Debian/Ubuntu Java8



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

ASF GitHub Bot commented on SUREFIRE-1588:
--

GitHub user kemitix opened a pull request:

https://github.com/apache/brooklyn-dist/pull/127

Fix for SUREFIRE-1588

Latest version of Java 1.8.0_191 enforces that Manifest classpath entries 
be relative.

https://issues.apache.org/jira/browse/SUREFIRE-1588

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/kemitix/brooklyn-dist fix-for-SUREFIRE-1588

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/brooklyn-dist/pull/127.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #127


commit 0d4736ec8e32c9292c0dc3755d01b2de4e086d2b
Author: Paul Campbell 
Date:   2018-11-02T12:56:33Z

Fix for SUREFIRE-1588

Latest version of Java 1.8.0_191 enforces that Manifest classpath entries 
be relative.

https://issues.apache.org/jira/browse/SUREFIRE-1588




> Surefire manifest jar classloading broken on latest Debian/Ubuntu Java8
> ---
>
> Key: SUREFIRE-1588
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1588
> Project: Maven Surefire
>  Issue Type: Bug
>Affects Versions: 2.22.1
>Reporter: Cservenak, Tamas
>Priority: Major
>
> See issue [1], but in short: latest Java8 on Ubuntu/Debian/Mint family of 
> Linuxes (am on Mint, Ubuntu derivative) contains this patch [3], and eforces 
> Manifest class path entries to be relative, as defined in [2].
> Hence, surefire booter and rest of Maven classpath, that uses absolute URLs 
> are simply discarded.
> Example error:
> {noformat}
> # Created at 2018-10-30T21:34:43.339
> Error: Could not find or load main class 
> org.apache.maven.surefire.booter.ForkedBooter{noformat}
> using the new property 
> {{-Djdk.net.URLClassPath.disableClassPathURLCheck=debug}} clearly shows that 
> all the entries from the surefire JAR are simply ignored.
>  
> [1] [https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911925]
> [2] 
> https://docs.oracle.com/javase/8/docs/technotes/guides/jar/jar.html#classpath
> [3] [https://hg.openjdk.java.net/jdk/jdk/rev/27135de165ac]



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

[jira] [Commented] (SUREFIRE-1588) Surefire manifest jar classloading broken on latest Debian/Ubuntu Java8



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

ASF GitHub Bot commented on SUREFIRE-1588:
--

Github user kemitix commented on the issue:

https://github.com/apache/brooklyn-dist/pull/127
  
@tbouron please review


> Surefire manifest jar classloading broken on latest Debian/Ubuntu Java8
> ---
>
> Key: SUREFIRE-1588
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1588
> Project: Maven Surefire
>  Issue Type: Bug
>Affects Versions: 2.22.1
>Reporter: Cservenak, Tamas
>Priority: Major
>
> See issue [1], but in short: latest Java8 on Ubuntu/Debian/Mint family of 
> Linuxes (am on Mint, Ubuntu derivative) contains this patch [3], and eforces 
> Manifest class path entries to be relative, as defined in [2].
> Hence, surefire booter and rest of Maven classpath, that uses absolute URLs 
> are simply discarded.
> Example error:
> {noformat}
> # Created at 2018-10-30T21:34:43.339
> Error: Could not find or load main class 
> org.apache.maven.surefire.booter.ForkedBooter{noformat}
> using the new property 
> {{-Djdk.net.URLClassPath.disableClassPathURLCheck=debug}} clearly shows that 
> all the entries from the surefire JAR are simply ignored.
>  
> [1] [https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911925]
> [2] 
> https://docs.oracle.com/javase/8/docs/technotes/guides/jar/jar.html#classpath
> [3] [https://hg.openjdk.java.net/jdk/jdk/rev/27135de165ac]



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

[jira] [Commented] (SUREFIRE-1588) Surefire manifest jar classloading broken on latest Debian/Ubuntu Java8



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

ASF GitHub Bot commented on SUREFIRE-1588:
--

mirabilos commented on issue #197: SUREFIRE-1588 Patch (Java7)
URL: https://github.com/apache/maven-surefire/pull/197#issuecomment-435369499
 
 
   > Now the API 3.0 is applied. I am working on Java 1.7 and plexus-java@java7 
in branch `3.0.0-M1`, and the release can start today late evening.
   > Btw somebody broke the behavior of maven:shared-utils:3.2.0+. I have to 
use older version 3.1.0.
   
   What does this even mean?
   
   We need a fixed release, and I don’t mind bumping the minimum Java version 
as everything here is Java 8 anyway (with one Java 7 project from another 
team), but what *other* incompatible changes will you introduce in version 
`3.0.0`? We really need a drop-in replacement soon.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Surefire manifest jar classloading broken on latest Debian/Ubuntu Java8
> ---
>
> Key: SUREFIRE-1588
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1588
> Project: Maven Surefire
>  Issue Type: Bug
>Affects Versions: 2.22.1
>Reporter: Cservenak, Tamas
>Priority: Major
>
> See issue [1], but in short: latest Java8 on Ubuntu/Debian/Mint family of 
> Linuxes (am on Mint, Ubuntu derivative) contains this patch [3], and eforces 
> Manifest class path entries to be relative, as defined in [2].
> Hence, surefire booter and rest of Maven classpath, that uses absolute URLs 
> are simply discarded.
> Example error:
> {noformat}
> # Created at 2018-10-30T21:34:43.339
> Error: Could not find or load main class 
> org.apache.maven.surefire.booter.ForkedBooter{noformat}
> using the new property 
> {{-Djdk.net.URLClassPath.disableClassPathURLCheck=debug}} clearly shows that 
> all the entries from the surefire JAR are simply ignored.
>  
> [1] [https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911925]
> [2] 
> https://docs.oracle.com/javase/8/docs/technotes/guides/jar/jar.html#classpath
> [3] [https://hg.openjdk.java.net/jdk/jdk/rev/27135de165ac]



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

[GitHub] mirabilos commented on issue #197: SUREFIRE-1588 Patch (Java7)

mirabilos commented on issue #197: SUREFIRE-1588 Patch (Java7)
URL: https://github.com/apache/maven-surefire/pull/197#issuecomment-435369499
 
 
   > Now the API 3.0 is applied. I am working on Java 1.7 and plexus-java@java7 
in branch `3.0.0-M1`, and the release can start today late evening.
   > Btw somebody broke the behavior of maven:shared-utils:3.2.0+. I have to 
use older version 3.1.0.
   
   What does this even mean?
   
   We need a fixed release, and I don’t mind bumping the minimum Java version 
as everything here is Java 8 anyway (with one Java 7 project from another 
team), but what *other* incompatible changes will you introduce in version 
`3.0.0`? We really need a drop-in replacement soon.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] Tibor17 commented on a change in pull request #197: SUREFIRE-1588 Patch (Java7)

Tibor17 commented on a change in pull request #197: SUREFIRE-1588 Patch (Java7)
URL: https://github.com/apache/maven-surefire/pull/197#discussion_r230360224
 
 

 ##
 File path: 
maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/booterclient/JarManifestForkConfiguration.java
 ##
 @@ -114,7 +115,7 @@ private File createJar( @Nonnull List classPath, 
@Nonnull String startCl
 {
 File file1 = new File( it.next() );
 
-String uri = parent.relativize( file1.toPath() ).toString();
+String uri = URI.create( parent.relativize( file1.toPath() 
).toString() ).toASCIIString();
 
 Review comment:
   AFAIK our users, they won't see any warnings. So. We should write the log 
down to a dump file, see `InPluginProcessDumpSingleton`. I do not think it is 
user error. You need to specify reports dir and pass it to the class because 
the `InPluginProcessDumpSingleton` requires the dir.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[jira] [Commented] (SUREFIRE-1588) Surefire manifest jar classloading broken on latest Debian/Ubuntu Java8



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

ASF GitHub Bot commented on SUREFIRE-1588:
--

Tibor17 commented on a change in pull request #197: SUREFIRE-1588 Patch (Java7)
URL: https://github.com/apache/maven-surefire/pull/197#discussion_r230360224
 
 

 ##
 File path: 
maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/booterclient/JarManifestForkConfiguration.java
 ##
 @@ -114,7 +115,7 @@ private File createJar( @Nonnull List classPath, 
@Nonnull String startCl
 {
 File file1 = new File( it.next() );
 
-String uri = parent.relativize( file1.toPath() ).toString();
+String uri = URI.create( parent.relativize( file1.toPath() 
).toString() ).toASCIIString();
 
 Review comment:
   AFAIK our users, they won't see any warnings. So. We should write the log 
down to a dump file, see `InPluginProcessDumpSingleton`. I do not think it user 
error. You need to specify reports dir and pass it to the class because the 
`InPluginProcessDumpSingleton` requires the dir.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Surefire manifest jar classloading broken on latest Debian/Ubuntu Java8
> ---
>
> Key: SUREFIRE-1588
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1588
> Project: Maven Surefire
>  Issue Type: Bug
>Affects Versions: 2.22.1
>Reporter: Cservenak, Tamas
>Priority: Major
>
> See issue [1], but in short: latest Java8 on Ubuntu/Debian/Mint family of 
> Linuxes (am on Mint, Ubuntu derivative) contains this patch [3], and eforces 
> Manifest class path entries to be relative, as defined in [2].
> Hence, surefire booter and rest of Maven classpath, that uses absolute URLs 
> are simply discarded.
> Example error:
> {noformat}
> # Created at 2018-10-30T21:34:43.339
> Error: Could not find or load main class 
> org.apache.maven.surefire.booter.ForkedBooter{noformat}
> using the new property 
> {{-Djdk.net.URLClassPath.disableClassPathURLCheck=debug}} clearly shows that 
> all the entries from the surefire JAR are simply ignored.
>  
> [1] [https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911925]
> [2] 
> https://docs.oracle.com/javase/8/docs/technotes/guides/jar/jar.html#classpath
> [3] [https://hg.openjdk.java.net/jdk/jdk/rev/27135de165ac]



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

[jira] [Commented] (SUREFIRE-1588) Surefire manifest jar classloading broken on latest Debian/Ubuntu Java8



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

ASF GitHub Bot commented on SUREFIRE-1588:
--

Tibor17 commented on a change in pull request #197: SUREFIRE-1588 Patch (Java7)
URL: https://github.com/apache/maven-surefire/pull/197#discussion_r230360224
 
 

 ##
 File path: 
maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/booterclient/JarManifestForkConfiguration.java
 ##
 @@ -114,7 +115,7 @@ private File createJar( @Nonnull List classPath, 
@Nonnull String startCl
 {
 File file1 = new File( it.next() );
 
-String uri = parent.relativize( file1.toPath() ).toString();
+String uri = URI.create( parent.relativize( file1.toPath() 
).toString() ).toASCIIString();
 
 Review comment:
   AFAIK our users, they won't see any warnings. So. We should write the log 
down to a dump file, see `InPluginProcessDumpSingleton`. I do not think it is 
user error. You need to specify reports dir and pass it to the class because 
the `InPluginProcessDumpSingleton` requires the dir.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Surefire manifest jar classloading broken on latest Debian/Ubuntu Java8
> ---
>
> Key: SUREFIRE-1588
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1588
> Project: Maven Surefire
>  Issue Type: Bug
>Affects Versions: 2.22.1
>Reporter: Cservenak, Tamas
>Priority: Major
>
> See issue [1], but in short: latest Java8 on Ubuntu/Debian/Mint family of 
> Linuxes (am on Mint, Ubuntu derivative) contains this patch [3], and eforces 
> Manifest class path entries to be relative, as defined in [2].
> Hence, surefire booter and rest of Maven classpath, that uses absolute URLs 
> are simply discarded.
> Example error:
> {noformat}
> # Created at 2018-10-30T21:34:43.339
> Error: Could not find or load main class 
> org.apache.maven.surefire.booter.ForkedBooter{noformat}
> using the new property 
> {{-Djdk.net.URLClassPath.disableClassPathURLCheck=debug}} clearly shows that 
> all the entries from the surefire JAR are simply ignored.
>  
> [1] [https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911925]
> [2] 
> https://docs.oracle.com/javase/8/docs/technotes/guides/jar/jar.html#classpath
> [3] [https://hg.openjdk.java.net/jdk/jdk/rev/27135de165ac]



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

[GitHub] Tibor17 commented on a change in pull request #197: SUREFIRE-1588 Patch (Java7)

Tibor17 commented on a change in pull request #197: SUREFIRE-1588 Patch (Java7)
URL: https://github.com/apache/maven-surefire/pull/197#discussion_r230360224
 
 

 ##
 File path: 
maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/booterclient/JarManifestForkConfiguration.java
 ##
 @@ -114,7 +115,7 @@ private File createJar( @Nonnull List classPath, 
@Nonnull String startCl
 {
 File file1 = new File( it.next() );
 
-String uri = parent.relativize( file1.toPath() ).toString();
+String uri = URI.create( parent.relativize( file1.toPath() 
).toString() ).toASCIIString();
 
 Review comment:
   AFAIK our users, they won't see any warnings. So. We should write the log 
down to a dump file, see `InPluginProcessDumpSingleton`. I do not think it user 
error. You need to specify reports dir and pass it to the class because the 
`InPluginProcessDumpSingleton` requires the dir.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[jira] [Commented] (SUREFIRE-1588) Surefire manifest jar classloading broken on latest Debian/Ubuntu Java8



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

ASF GitHub Bot commented on SUREFIRE-1588:
--

Tibor17 commented on a change in pull request #197: SUREFIRE-1588 Patch (Java7)
URL: https://github.com/apache/maven-surefire/pull/197#discussion_r230360224
 
 

 ##
 File path: 
maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/booterclient/JarManifestForkConfiguration.java
 ##
 @@ -114,7 +115,7 @@ private File createJar( @Nonnull List classPath, 
@Nonnull String startCl
 {
 File file1 = new File( it.next() );
 
-String uri = parent.relativize( file1.toPath() ).toString();
+String uri = URI.create( parent.relativize( file1.toPath() 
).toString() ).toASCIIString();
 
 Review comment:
   AFAIK our users, they won't see any warnings. So. We should write the log 
down to a dump file, see `InPluginProcessDumpSingleton`. You need to specify 
reports dir and pass it to the class.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Surefire manifest jar classloading broken on latest Debian/Ubuntu Java8
> ---
>
> Key: SUREFIRE-1588
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1588
> Project: Maven Surefire
>  Issue Type: Bug
>Affects Versions: 2.22.1
>Reporter: Cservenak, Tamas
>Priority: Major
>
> See issue [1], but in short: latest Java8 on Ubuntu/Debian/Mint family of 
> Linuxes (am on Mint, Ubuntu derivative) contains this patch [3], and eforces 
> Manifest class path entries to be relative, as defined in [2].
> Hence, surefire booter and rest of Maven classpath, that uses absolute URLs 
> are simply discarded.
> Example error:
> {noformat}
> # Created at 2018-10-30T21:34:43.339
> Error: Could not find or load main class 
> org.apache.maven.surefire.booter.ForkedBooter{noformat}
> using the new property 
> {{-Djdk.net.URLClassPath.disableClassPathURLCheck=debug}} clearly shows that 
> all the entries from the surefire JAR are simply ignored.
>  
> [1] [https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911925]
> [2] 
> https://docs.oracle.com/javase/8/docs/technotes/guides/jar/jar.html#classpath
> [3] [https://hg.openjdk.java.net/jdk/jdk/rev/27135de165ac]



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

[GitHub] Tibor17 commented on a change in pull request #197: SUREFIRE-1588 Patch (Java7)

Tibor17 commented on a change in pull request #197: SUREFIRE-1588 Patch (Java7)
URL: https://github.com/apache/maven-surefire/pull/197#discussion_r230360224
 
 

 ##
 File path: 
maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/booterclient/JarManifestForkConfiguration.java
 ##
 @@ -114,7 +115,7 @@ private File createJar( @Nonnull List classPath, 
@Nonnull String startCl
 {
 File file1 = new File( it.next() );
 
-String uri = parent.relativize( file1.toPath() ).toString();
+String uri = URI.create( parent.relativize( file1.toPath() 
).toString() ).toASCIIString();
 
 Review comment:
   AFAIK our users, they won't see any warnings. So. We should write the log 
down to a dump file, see `InPluginProcessDumpSingleton`. You need to specify 
reports dir and pass it to the class.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[jira] [Commented] (SUREFIRE-1588) Surefire manifest jar classloading broken on latest Debian/Ubuntu Java8



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

ASF GitHub Bot commented on SUREFIRE-1588:
--

Tibor17 commented on a change in pull request #197: SUREFIRE-1588 Patch (Java7)
URL: https://github.com/apache/maven-surefire/pull/197#discussion_r230358750
 
 

 ##
 File path: 
maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/booterclient/JarManifestForkConfiguration.java
 ##
 @@ -114,7 +115,7 @@ private File createJar( @Nonnull List classPath, 
@Nonnull String startCl
 {
 File file1 = new File( it.next() );
 
-String uri = parent.relativize( file1.toPath() ).toString();
+String uri = URI.create( parent.relativize( file1.toPath() 
).toString() ).toASCIIString();
 
 Review comment:
   Works for me but the annoying are logs because we log every Jar file.
   This can be fixed by using a boolean flag preventing from repeative logs 
with same message.
   Can you segregate the try-catch to a private method?
   I have a question regarding the bug. The build plugin crashed with plugin 
version `2.22.1` on 1.8.0_192? It did not crash on my Windows system. It is 
different experience on Linux?


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Surefire manifest jar classloading broken on latest Debian/Ubuntu Java8
> ---
>
> Key: SUREFIRE-1588
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1588
> Project: Maven Surefire
>  Issue Type: Bug
>Affects Versions: 2.22.1
>Reporter: Cservenak, Tamas
>Priority: Major
>
> See issue [1], but in short: latest Java8 on Ubuntu/Debian/Mint family of 
> Linuxes (am on Mint, Ubuntu derivative) contains this patch [3], and eforces 
> Manifest class path entries to be relative, as defined in [2].
> Hence, surefire booter and rest of Maven classpath, that uses absolute URLs 
> are simply discarded.
> Example error:
> {noformat}
> # Created at 2018-10-30T21:34:43.339
> Error: Could not find or load main class 
> org.apache.maven.surefire.booter.ForkedBooter{noformat}
> using the new property 
> {{-Djdk.net.URLClassPath.disableClassPathURLCheck=debug}} clearly shows that 
> all the entries from the surefire JAR are simply ignored.
>  
> [1] [https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911925]
> [2] 
> https://docs.oracle.com/javase/8/docs/technotes/guides/jar/jar.html#classpath
> [3] [https://hg.openjdk.java.net/jdk/jdk/rev/27135de165ac]



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

[GitHub] Tibor17 commented on a change in pull request #197: SUREFIRE-1588 Patch (Java7)

Tibor17 commented on a change in pull request #197: SUREFIRE-1588 Patch (Java7)
URL: https://github.com/apache/maven-surefire/pull/197#discussion_r230358750
 
 

 ##
 File path: 
maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/booterclient/JarManifestForkConfiguration.java
 ##
 @@ -114,7 +115,7 @@ private File createJar( @Nonnull List classPath, 
@Nonnull String startCl
 {
 File file1 = new File( it.next() );
 
-String uri = parent.relativize( file1.toPath() ).toString();
+String uri = URI.create( parent.relativize( file1.toPath() 
).toString() ).toASCIIString();
 
 Review comment:
   Works for me but the annoying are logs because we log every Jar file.
   This can be fixed by using a boolean flag preventing from repeative logs 
with same message.
   Can you segregate the try-catch to a private method?
   I have a question regarding the bug. The build plugin crashed with plugin 
version `2.22.1` on 1.8.0_192? It did not crash on my Windows system. It is 
different experience on Linux?


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[jira] [Commented] (SUREFIRE-1574) Communication between surefire plugin and its forks corrupted by test code



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

Tibor Digana commented on SUREFIRE-1574:


It is our need to fix too but we have received very urgent issues. So. It
is about priority. But as I said, we need to use sockets which is important
for us as well.

On Fri, Nov 2, 2018 at 1:10 PM Arnoud Glimmerveen (JIRA) 



> Communication between surefire plugin and its forks corrupted by test code
> --
>
> Key: SUREFIRE-1574
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1574
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Maven Surefire Plugin
>Affects Versions: 2.22.0
> Environment: Maven 3.5.4
> Surefire 2.22.0
> Pax Exam 4.12.0
>Reporter: Arnoud Glimmerveen
>Assignee: Tibor Digana
>Priority: Blocker
> Fix For: 3.0.0-M3
>
>
> In a setup with maven-surefire-plugin 2.22.0 with PAX Exam 4.12.0 I 
> occasionally see that the Maven build takes about 30 seconds longer than 
> expected. The source of this additional 30 seconds is a timeout used to 
> eventually terminate a fork if it does not terminate by itself.
> I have traced the cause of this failure to terminate to the Thread inside the 
> fork receiving commands from the maven plugin (silently) terminating with an 
> IOException. This is triggered by the validation logic inside 
> MasterProcessCommand to check for commands without payload (NOOP, BYE_ACK) 
> that there is actually no data send. If some other code reads data from the 
> same `System.in` InputStream, the MasterProcessCommand.decode method may read 
> data belonging to subsequent commands.
> Relying on the assumption that the Surefire logic in the forked process is 
> the only one reading from the 'shared resource' `System.in` makes it 
> vulnerable to this corruption. I see that the catch clause of IOException in 
> CommandReader also reports this, though I did not see the '[SUREFIRE] std/in 
> stream corrupted' error in my runs.
> Some of the solutions I thought of:
>  * Replacing the communication protocol (also mentioned here)
>  * Have the CommandRunnable hold an exclusive lock on `System.in` for the 
> entire run() (wrapping the entire run with synchronized(System.in) {}) to 
> ensure no other thread can read from the InputStream (as the individual read 
> methods of BufferedInputStream used for System.in as synchronized as well). 
> This is a risky move though, as I guess there is no guarantee that System.in 
> is always implemented by BufferedInputStream.
> I have prepared a project that demonstrates this behaviour: 
> [https://github.com/glimmerveen/fork-test] . The timeout behaviour is visible 
> as the test results are reported on the stdout of Maven, but the build 
> process does not continue for another 30 seconds or so. Note that the 
> corruption does not always happen.
> Note that I reported this as blocking not necessarily because of the 
> additional time it takes for the build to execute, but due to the fact that 
> when the fork is terminated by the timeout, frameworks like JaCoCo don't get 
> the opportunity to output their results.



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

[jira] [Commented] (SUREFIRE-1574) Communication between surefire plugin and its forks corrupted by test code

2018-11-02 Thread Arnoud Glimmerveen (JIRA)



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

Arnoud Glimmerveen commented on SUREFIRE-1574:
--

[~tibor17]: In my case the consuming of stdin in de forked process is done by 
the OSGi test library Pax Exam. Each test class forks a new JVM, running an 
OSGi container and a probe executing the actual test. I am just a user of this 
library, so I am not familiar with the exact rationale of this library reading 
from stdin. I would guess it was done in an attempt to make the actual forking 
of the process transparent for an external actor: _if_ someone would send 
something to the stdin of the test (in my case running the process forked by 
the maven-surefire-plugin) the Pax Exam library running in that process would 
transparently forward this to the process it forked for running the actual OSGi 
based test.

I guess it is debatable who is actually at fault here. My proposal would be to 
ensure that the maven-surefire-plugin is not susceptible for these kind of 
(mis)uses of shared resources such as stdin/stdout and use different means to 
communicate between the maven-surefire-plugin and the processes it forks.

> Communication between surefire plugin and its forks corrupted by test code
> --
>
> Key: SUREFIRE-1574
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1574
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Maven Surefire Plugin
>Affects Versions: 2.22.0
> Environment: Maven 3.5.4
> Surefire 2.22.0
> Pax Exam 4.12.0
>Reporter: Arnoud Glimmerveen
>Assignee: Tibor Digana
>Priority: Blocker
> Fix For: 3.0.0-M3
>
>
> In a setup with maven-surefire-plugin 2.22.0 with PAX Exam 4.12.0 I 
> occasionally see that the Maven build takes about 30 seconds longer than 
> expected. The source of this additional 30 seconds is a timeout used to 
> eventually terminate a fork if it does not terminate by itself.
> I have traced the cause of this failure to terminate to the Thread inside the 
> fork receiving commands from the maven plugin (silently) terminating with an 
> IOException. This is triggered by the validation logic inside 
> MasterProcessCommand to check for commands without payload (NOOP, BYE_ACK) 
> that there is actually no data send. If some other code reads data from the 
> same `System.in` InputStream, the MasterProcessCommand.decode method may read 
> data belonging to subsequent commands.
> Relying on the assumption that the Surefire logic in the forked process is 
> the only one reading from the 'shared resource' `System.in` makes it 
> vulnerable to this corruption. I see that the catch clause of IOException in 
> CommandReader also reports this, though I did not see the '[SUREFIRE] std/in 
> stream corrupted' error in my runs.
> Some of the solutions I thought of:
>  * Replacing the communication protocol (also mentioned here)
>  * Have the CommandRunnable hold an exclusive lock on `System.in` for the 
> entire run() (wrapping the entire run with synchronized(System.in) {}) to 
> ensure no other thread can read from the InputStream (as the individual read 
> methods of BufferedInputStream used for System.in as synchronized as well). 
> This is a risky move though, as I guess there is no guarantee that System.in 
> is always implemented by BufferedInputStream.
> I have prepared a project that demonstrates this behaviour: 
> [https://github.com/glimmerveen/fork-test] . The timeout behaviour is visible 
> as the test results are reported on the stdout of Maven, but the build 
> process does not continue for another 30 seconds or so. Note that the 
> corruption does not always happen.
> Note that I reported this as blocking not necessarily because of the 
> additional time it takes for the build to execute, but due to the fact that 
> when the fork is terminated by the timeout, frameworks like JaCoCo don't get 
> the opportunity to output their results.



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

[jira] [Updated] (MRESOLVER-63) FileTransformer#transformData(File) should also throw TransformException



 [ 
https://issues.apache.org/jira/browse/MRESOLVER-63?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robert Scholte updated MRESOLVER-63:

Labels: up-for-grabs  (was: )

> FileTransformer#transformData(File) should also throw TransformException
> 
>
> Key: MRESOLVER-63
> URL: https://issues.apache.org/jira/browse/MRESOLVER-63
> Project: Maven Resolver
>  Issue Type: Improvement
>  Components: resolver
>Affects Versions: 1.3.1
>Reporter: Robert Scholte
>Priority: Major
>  Labels: up-for-grabs
> Fix For: 1.3.2
>
>
> 1.3.1 introduced the FileTransformer to allow on-the-fly transforming of data.
> For XML files it makes sense to use XMLFilters and create an XMLReader. This 
> can throw a SAXException, which is a checked exception, which shouldn't be 
> rethrown as an IOException.
> Better to introduce a new Exception to handle this case properly.
> Assuming this class isn't used anywhere yet, it should be good to introduce 
> it asap.



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

[jira] [Created] (MRESOLVER-63) FileTransformer#transformData(File) should also throw TransformException

Robert Scholte created MRESOLVER-63:
---

 Summary: FileTransformer#transformData(File) should also throw 
TransformException
 Key: MRESOLVER-63
 URL: https://issues.apache.org/jira/browse/MRESOLVER-63
 Project: Maven Resolver
  Issue Type: Improvement
  Components: resolver
Affects Versions: 1.3.1
Reporter: Robert Scholte
 Fix For: 1.3.2


1.3.1 introduced the FileTransformer to allow on-the-fly transforming of data.

For XML files it makes sense to use XMLFilters and create an XMLReader. This 
can throw a SAXException, which is a checked exception, which shouldn't be 
rethrown as an IOException.

Better to introduce a new Exception to handle this case properly.

Assuming this class isn't used anywhere yet, it should be good to introduce it 
asap.



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

[jira] [Commented] (SUREFIRE-1541) SurefireBooterForkException: The forked VM terminated without properly saying goodbye. VM crash or System.exit called?

2018-11-02 Thread Anton (JIRA)



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

Anton commented on SUREFIRE-1541:
-

h3. maven:3.5.4-jdk-8 surefire 2.22.1 - FAILED

https://gitlab.com/anton_patsev/java-junit-sample/-/jobs/115721004
h3. maven:3.5.3-jdk-8 surefire 2.22.1 - SUCCESS

https://gitlab.com/anton_patsev/java-junit-sample/-/jobs/115721102

> SurefireBooterForkException: The forked VM terminated without properly saying 
> goodbye. VM crash or System.exit called?
> --
>
> Key: SUREFIRE-1541
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1541
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Maven Surefire Plugin
>Affects Versions: 2.22.0
>Reporter: Anghel Botos
>Priority: Major
>
> Attempting to run integration tests using maven-failsafe-plugin with 
> {{-Dmaven.failsafe.debug=false}} yields the following stacktrace:
>  
> {noformat}
> [ERROR] ExecutionException The forked VM terminated without properly saying 
> goodbye. VM crash or System.exit called?
> [ERROR] Command was cmd.exe /X /C ""C:\Program 
> Files\Java\jdk1.8.0_121\jre\bin\java" false -jar 
> C:\Users\ANGHEL~1.BOT\AppData\Local\Temp\surefire8539836821793811485\surefirebooter6734575521909210279.jar
>  C:\Users\anghel.botos\AppData\Local\Temp\surefire8539836821793811485 
> 2018-07-24T11-18-12_704-jvmRun1 surefire7184511894589995478tmp 
> surefire_411836142070426630764tmp"
> [ERROR] Error occurred in starting fork, check output in log
> [ERROR] Process Exit Code: 1
> [ERROR] at 
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.awaitResultsDone(ForkStarter.java:494)
> [ERROR] at 
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.runSuitesForkPerTestSet(ForkStarter.java:441)
> [ERROR] at 
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:293)
> [ERROR] at 
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:245)
> {noformat}
>  
> The issue is the "free-floating" {{false}} that appears in the command line 
> used to start a new JVM. I've traced down the issue to 
> {{org.apache.maven.plugin.surefire.AbstractSurefireMojo#getEffectiveDebugForkedProcess}}
>  where the following code can be found:
> {code:java}
> String debugForkedProcess = getDebugForkedProcess();
> if ( "true".equals( debugForkedProcess ) )
> {
> return "-Xdebug -Xnoagent -Djava.compiler=NONE"
> + " 
> -Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=5005";
> }
> return debugForkedProcess;
> {code}
> ...which is quite..."unexpected" to see that one can pass in a value of 
> {{true}}, but not a value of {{false}}.
> Please fix with a proper parsing of true/false values for the 
> {{maven.failsafe.debug}} property.



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

[jira] [Closed] (SUREFIRE-1499) VM crash with Alpine linux and openjdk



 [ 
https://issues.apache.org/jira/browse/SUREFIRE-1499?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tibor Digana closed SUREFIRE-1499.
--
Resolution: Not A Bug

Not a bug with Version 2.22.1 - see user's answer.

> VM crash with Alpine linux and openjdk
> --
>
> Key: SUREFIRE-1499
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1499
> Project: Maven Surefire
>  Issue Type: Bug
>Reporter: Dave Syer
>Assignee: Tibor Digana
>Priority: Major
>
> I have seen other similar looking issues, but none that are obviously crisply 
> the same (https://issues.apache.org/jira/browse/SUREFIRE-1303, 
> https://issues.apache.org/jira/browse/SUREFIRE-1408, 
> https://issues.apache.org/jira/browse/SUREFIRE-1478). This is pretty easy to 
> reproduce with just docker. Here's a sample that shows the problem 
> [https://github.com/scratches/surefire-crash.] The README tells you how to 
> fiddle around to work around it (downgrade surefire, or change the JDK).
>  
> Copied from there:
> {noformat}
> # ./mvnw install
> ...
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-surefire-plugin:2.20.1:test (default-test) on 
> project appo: There are test failures.
> [ERROR] 
> [ERROR] Please refer to /source/target/surefire-reports for the individual 
> test results.
> [ERROR] Please refer to dump files (if any exist) [date]-jvmRun[N].dump, 
> [date].dumpstream and [date]-jvmRun[N].dumpstream.
> [ERROR] The forked VM terminated without properly saying goodbye. VM crash or 
> System.exit called?
> [ERROR] Command was /bin/sh -c cd /source && 
> /usr/lib/jvm/java-1.8-openjdk/jre/bin/java -jar 
> /source/target/surefire/surefirebooter3510938747541906908.jar 
> /source/target/surefire 2018-03-12T08-53-57_688-jvmRun1 
> surefire77870329121965774tmp surefire_03692097491311877891tmp
> [ERROR] Error occurred in starting fork, check output in log
> [ERROR] Process Exit Code: 1
> [ERROR] org.apache.maven.surefire.booter.SurefireBooterForkException: The 
> forked VM terminated without properly saying goodbye. VM crash or System.exit 
> called?
> [ERROR] Command was /bin/sh -c cd /source && 
> /usr/lib/jvm/java-1.8-openjdk/jre/bin/java -jar 
> /source/target/surefire/surefirebooter3510938747541906908.jar 
> /source/target/surefire 2018-03-12T08-53-57_688-jvmRun1 
> surefire77870329121965774tmp surefire_03692097491311877891tmp
> [ERROR] Error occurred in starting fork, check output in log
> [ERROR] Process Exit Code: 1
> [ERROR]   at 
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:686)
> [ERROR]   at 
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:535)
> [ERROR]   at 
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:280)
> [ERROR]   at 
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:245)
> [ERROR]   at 
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider(AbstractSurefireMojo.java:1124)
> [ERROR]   at 
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:954)
> [ERROR]   at 
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute(AbstractSurefireMojo.java:832)
> [ERROR]   at 
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
> [ERROR]   at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
> [ERROR]   at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:154)
> [ERROR]   at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:146)
> [ERROR]   at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:117)
> [ERROR]   at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:81)
> [ERROR]   at 
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
> [ERROR]   at 
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
> [ERROR]   at 
> org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:309)
> [ERROR]   at 
> org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:194)
> [ERROR]   at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:107)
> [ERROR]   at org.apache.maven.cli.MavenCli.execute(MavenCli.java:955)
> [ERROR]   at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:290)
> [ERROR]   at org.apache.maven.cli.MavenCli.main(MavenCli.java:194)
> [ERROR]   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [ERROR]   at 
>

[jira] [Assigned] (SUREFIRE-1499) VM crash with Alpine linux and openjdk



 [ 
https://issues.apache.org/jira/browse/SUREFIRE-1499?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tibor Digana reassigned SUREFIRE-1499:
--

Assignee: Tibor Digana

> VM crash with Alpine linux and openjdk
> --
>
> Key: SUREFIRE-1499
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1499
> Project: Maven Surefire
>  Issue Type: Bug
>Reporter: Dave Syer
>Assignee: Tibor Digana
>Priority: Major
>
> I have seen other similar looking issues, but none that are obviously crisply 
> the same (https://issues.apache.org/jira/browse/SUREFIRE-1303, 
> https://issues.apache.org/jira/browse/SUREFIRE-1408, 
> https://issues.apache.org/jira/browse/SUREFIRE-1478). This is pretty easy to 
> reproduce with just docker. Here's a sample that shows the problem 
> [https://github.com/scratches/surefire-crash.] The README tells you how to 
> fiddle around to work around it (downgrade surefire, or change the JDK).
>  
> Copied from there:
> {noformat}
> # ./mvnw install
> ...
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-surefire-plugin:2.20.1:test (default-test) on 
> project appo: There are test failures.
> [ERROR] 
> [ERROR] Please refer to /source/target/surefire-reports for the individual 
> test results.
> [ERROR] Please refer to dump files (if any exist) [date]-jvmRun[N].dump, 
> [date].dumpstream and [date]-jvmRun[N].dumpstream.
> [ERROR] The forked VM terminated without properly saying goodbye. VM crash or 
> System.exit called?
> [ERROR] Command was /bin/sh -c cd /source && 
> /usr/lib/jvm/java-1.8-openjdk/jre/bin/java -jar 
> /source/target/surefire/surefirebooter3510938747541906908.jar 
> /source/target/surefire 2018-03-12T08-53-57_688-jvmRun1 
> surefire77870329121965774tmp surefire_03692097491311877891tmp
> [ERROR] Error occurred in starting fork, check output in log
> [ERROR] Process Exit Code: 1
> [ERROR] org.apache.maven.surefire.booter.SurefireBooterForkException: The 
> forked VM terminated without properly saying goodbye. VM crash or System.exit 
> called?
> [ERROR] Command was /bin/sh -c cd /source && 
> /usr/lib/jvm/java-1.8-openjdk/jre/bin/java -jar 
> /source/target/surefire/surefirebooter3510938747541906908.jar 
> /source/target/surefire 2018-03-12T08-53-57_688-jvmRun1 
> surefire77870329121965774tmp surefire_03692097491311877891tmp
> [ERROR] Error occurred in starting fork, check output in log
> [ERROR] Process Exit Code: 1
> [ERROR]   at 
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:686)
> [ERROR]   at 
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:535)
> [ERROR]   at 
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:280)
> [ERROR]   at 
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:245)
> [ERROR]   at 
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider(AbstractSurefireMojo.java:1124)
> [ERROR]   at 
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:954)
> [ERROR]   at 
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute(AbstractSurefireMojo.java:832)
> [ERROR]   at 
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
> [ERROR]   at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
> [ERROR]   at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:154)
> [ERROR]   at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:146)
> [ERROR]   at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:117)
> [ERROR]   at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:81)
> [ERROR]   at 
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
> [ERROR]   at 
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
> [ERROR]   at 
> org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:309)
> [ERROR]   at 
> org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:194)
> [ERROR]   at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:107)
> [ERROR]   at org.apache.maven.cli.MavenCli.execute(MavenCli.java:955)
> [ERROR]   at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:290)
> [ERROR]   at org.apache.maven.cli.MavenCli.main(MavenCli.java:194)
> [ERROR]   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [ERROR]   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> [ERROR]   at

[jira] [Commented] (SUREFIRE-1499) VM crash with Alpine linux and openjdk



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

Tibor Digana commented on SUREFIRE-1499:


??So I guess this can be closed if people can just upgrade, but I'm not sure 
what relevance testing on Ubuntu or maven library images has.??
It's easy. The plugin is tested with Maven 3+ and should work for Maven 2.2.1 
because Surefire  2.x uses Maven API 2.2.1. No preference over platform, only 
Java 1.6+ but we are testing on 1.7+ and Ubuntu/Windows Server 2008. We have 
turned the Surefire project to Maven 3.0 API few hours ago, so I guess we can 
expect a new release of Version 3.0.0-M1 in after several days.

> VM crash with Alpine linux and openjdk
> --
>
> Key: SUREFIRE-1499
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1499
> Project: Maven Surefire
>  Issue Type: Bug
>Reporter: Dave Syer
>Priority: Major
>
> I have seen other similar looking issues, but none that are obviously crisply 
> the same (https://issues.apache.org/jira/browse/SUREFIRE-1303, 
> https://issues.apache.org/jira/browse/SUREFIRE-1408, 
> https://issues.apache.org/jira/browse/SUREFIRE-1478). This is pretty easy to 
> reproduce with just docker. Here's a sample that shows the problem 
> [https://github.com/scratches/surefire-crash.] The README tells you how to 
> fiddle around to work around it (downgrade surefire, or change the JDK).
>  
> Copied from there:
> {noformat}
> # ./mvnw install
> ...
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-surefire-plugin:2.20.1:test (default-test) on 
> project appo: There are test failures.
> [ERROR] 
> [ERROR] Please refer to /source/target/surefire-reports for the individual 
> test results.
> [ERROR] Please refer to dump files (if any exist) [date]-jvmRun[N].dump, 
> [date].dumpstream and [date]-jvmRun[N].dumpstream.
> [ERROR] The forked VM terminated without properly saying goodbye. VM crash or 
> System.exit called?
> [ERROR] Command was /bin/sh -c cd /source && 
> /usr/lib/jvm/java-1.8-openjdk/jre/bin/java -jar 
> /source/target/surefire/surefirebooter3510938747541906908.jar 
> /source/target/surefire 2018-03-12T08-53-57_688-jvmRun1 
> surefire77870329121965774tmp surefire_03692097491311877891tmp
> [ERROR] Error occurred in starting fork, check output in log
> [ERROR] Process Exit Code: 1
> [ERROR] org.apache.maven.surefire.booter.SurefireBooterForkException: The 
> forked VM terminated without properly saying goodbye. VM crash or System.exit 
> called?
> [ERROR] Command was /bin/sh -c cd /source && 
> /usr/lib/jvm/java-1.8-openjdk/jre/bin/java -jar 
> /source/target/surefire/surefirebooter3510938747541906908.jar 
> /source/target/surefire 2018-03-12T08-53-57_688-jvmRun1 
> surefire77870329121965774tmp surefire_03692097491311877891tmp
> [ERROR] Error occurred in starting fork, check output in log
> [ERROR] Process Exit Code: 1
> [ERROR]   at 
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:686)
> [ERROR]   at 
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:535)
> [ERROR]   at 
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:280)
> [ERROR]   at 
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:245)
> [ERROR]   at 
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider(AbstractSurefireMojo.java:1124)
> [ERROR]   at 
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:954)
> [ERROR]   at 
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute(AbstractSurefireMojo.java:832)
> [ERROR]   at 
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
> [ERROR]   at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
> [ERROR]   at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:154)
> [ERROR]   at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:146)
> [ERROR]   at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:117)
> [ERROR]   at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:81)
> [ERROR]   at 
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
> [ERROR]   at 
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
> [ERROR]   at 
> org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:309)
> [ERROR]   at 
> org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:194)
> [ERROR]

[jira] [Commented] (SUREFIRE-1541) SurefireBooterForkException: The forked VM terminated without properly saying goodbye. VM crash or System.exit called?

2018-11-02 Thread Anton (JIRA)



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

Anton commented on SUREFIRE-1541:
-

If i use maven:3.3.9-jdk8 surefire 2.22.1 - i dont get error

https://gitlab.com/anton_patsev/java-junit-sample/-/jobs/115700267

> SurefireBooterForkException: The forked VM terminated without properly saying 
> goodbye. VM crash or System.exit called?
> --
>
> Key: SUREFIRE-1541
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1541
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Maven Surefire Plugin
>Affects Versions: 2.22.0
>Reporter: Anghel Botos
>Priority: Major
>
> Attempting to run integration tests using maven-failsafe-plugin with 
> {{-Dmaven.failsafe.debug=false}} yields the following stacktrace:
>  
> {noformat}
> [ERROR] ExecutionException The forked VM terminated without properly saying 
> goodbye. VM crash or System.exit called?
> [ERROR] Command was cmd.exe /X /C ""C:\Program 
> Files\Java\jdk1.8.0_121\jre\bin\java" false -jar 
> C:\Users\ANGHEL~1.BOT\AppData\Local\Temp\surefire8539836821793811485\surefirebooter6734575521909210279.jar
>  C:\Users\anghel.botos\AppData\Local\Temp\surefire8539836821793811485 
> 2018-07-24T11-18-12_704-jvmRun1 surefire7184511894589995478tmp 
> surefire_411836142070426630764tmp"
> [ERROR] Error occurred in starting fork, check output in log
> [ERROR] Process Exit Code: 1
> [ERROR] at 
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.awaitResultsDone(ForkStarter.java:494)
> [ERROR] at 
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.runSuitesForkPerTestSet(ForkStarter.java:441)
> [ERROR] at 
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:293)
> [ERROR] at 
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:245)
> {noformat}
>  
> The issue is the "free-floating" {{false}} that appears in the command line 
> used to start a new JVM. I've traced down the issue to 
> {{org.apache.maven.plugin.surefire.AbstractSurefireMojo#getEffectiveDebugForkedProcess}}
>  where the following code can be found:
> {code:java}
> String debugForkedProcess = getDebugForkedProcess();
> if ( "true".equals( debugForkedProcess ) )
> {
> return "-Xdebug -Xnoagent -Djava.compiler=NONE"
> + " 
> -Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=5005";
> }
> return debugForkedProcess;
> {code}
> ...which is quite..."unexpected" to see that one can pass in a value of 
> {{true}}, but not a value of {{false}}.
> Please fix with a proper parsing of true/false values for the 
> {{maven.failsafe.debug}} property.



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

[jira] [Commented] (SUREFIRE-1588) Surefire manifest jar classloading broken on latest Debian/Ubuntu Java8



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

ASF GitHub Bot commented on SUREFIRE-1588:
--

Github user asfgit closed the pull request at:

https://github.com/apache/brooklyn-server/pull/1012


> Surefire manifest jar classloading broken on latest Debian/Ubuntu Java8
> ---
>
> Key: SUREFIRE-1588
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1588
> Project: Maven Surefire
>  Issue Type: Bug
>Affects Versions: 2.22.1
>Reporter: Cservenak, Tamas
>Priority: Major
>
> See issue [1], but in short: latest Java8 on Ubuntu/Debian/Mint family of 
> Linuxes (am on Mint, Ubuntu derivative) contains this patch [3], and eforces 
> Manifest class path entries to be relative, as defined in [2].
> Hence, surefire booter and rest of Maven classpath, that uses absolute URLs 
> are simply discarded.
> Example error:
> {noformat}
> # Created at 2018-10-30T21:34:43.339
> Error: Could not find or load main class 
> org.apache.maven.surefire.booter.ForkedBooter{noformat}
> using the new property 
> {{-Djdk.net.URLClassPath.disableClassPathURLCheck=debug}} clearly shows that 
> all the entries from the surefire JAR are simply ignored.
>  
> [1] [https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911925]
> [2] 
> https://docs.oracle.com/javase/8/docs/technotes/guides/jar/jar.html#classpath
> [3] [https://hg.openjdk.java.net/jdk/jdk/rev/27135de165ac]



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

[jira] [Commented] (SUREFIRE-1588) Surefire manifest jar classloading broken on latest Debian/Ubuntu Java8