[GitHub] jglick opened a new pull request #198: [SUREFIRE-1588] Correcting relativization logic to produce valid URIs on Windows

[GitBox <gi...@apache.org>]

jglick opened a new pull request #198: [SUREFIRE-1588] Correcting relativization logic to produce valid URIs on Windows
URL: https://github.com/apache/maven-surefire/pull/198
 
 
   Amends #197 or the commits it turned in to. The root issue is that `Path.relativize` uses a native path separator while `URI.path` expects `/`.
   
   Observed errors running Jenkins functional tests on a Windows CI machine in which the system temporary directory (used for the booter as of [SUREFIRE-1400](https://issues.apache.org/jira/browse/SUREFIRE-1400)) used the same drive as the local repository, and Surefire thus attempted relativization.
   
   (When the drives were different, it falls back to the original behavior of using absolute paths, which still works at least on the Windows JDK 8u191. This made it harder for me to reproduce at first. Passing `-Djava.io.tmpdir=…` to `mvn` allows it to be reproduced locally, and to confirm that the test passes when using a snapshot version of Surefire.)
   
   The problem was that `Class-Path` entries included nonsense URIs with components like `..%5C` rather than `../`. The Java class loader is apparently able to load classes from the result, but then the `Class.protectionDomain.codeSource.location` is weird.
   
   @Tibor17 @cstamas

----------------------------------------------------------------
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:
users@infra.apache.org


With regards,
Apache Git Services