There is a preliminary test in [1] and the failure in [2].
The best I can do is to leave the IT as-is, put a max boundary 3.5.4)
and add a new IT for the Path solution. The unit test would be
assertFalse() accompanied with a new test for this issue.
Moreover, I will check for baseUri.startsWith("file:///") because
everything else is dynamic.
Note: this issue isn't related to Windows only, but Unix too.
Funny fact, Git fails also:
PS D:\Entwicklung\Projekte> git clone
file:///D:/Entwicklung/git-repos/toll tlll2
Cloning into 'tlll2'...
warning: You appear to have cloned an empty repository.
PS D:\Entwicklung\Projekte> git clone
file:/D:/Entwicklung/git-repos/toll tlll2
Cloning into 'tlll2'...
ssh: Could not resolve hostname file: Name or service not known
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.
PS D:\Entwicklung\Projekte>
[1]
https://github.com/apache/maven/commit/b10e8b5089a5ad3d7d29d649638adca91ec8de6d#diff-b0d22c4444c54350aef9f53a9472a674R1092-
[2]
https://builds.apache.org/job/maven-box/job/maven/job/MNG-6386/2/testReport/junit/org.apache.maven.project/PomConstructionTest/testInterpolationOfValidBaseUri/
Am 2018-05-02 um 10:41 schrieb Robert Scholte:
I don't see a new test[1][2], only rewrites to confirm there's no
regression.
I understand the issue, but we just need to be sure that nobody in the
future thinks that File.toURI() is short for File.toPath().toUri()
Robert
[1]
https://github.com/apache/maven/commit/43b34598629f086523a333dc18665389643832a5
[2]
https://github.com/apache/maven-integration-testing/commit/5e18bb18784585dfc822038f5229785d439c677b
On Tue, 01 May 2018 23:22:59 +0200, Michael Osipov <micha...@apache.org>
wrote:
Am 2018-05-01 um 19:40 schrieb Robert Scholte:
Hi Michael,
to me it looks like the tests don't proof there's an issue.
I only see that testDir.toURI() being replaced with
testDir.toPath().toUri() while the actual value stays the same.
No, it doesn't on Windows. File#toURI() is broken. Please see the
issue description.
The current behavior will give with SCM:
PS D:\Entwicklung\Projekte\maven-scm> svn ls
file:/D:/Entwicklung/svn-repos/scm-svn-test-at-sign
svn: E020024: Error resolving case of
'file:\D:\Entwicklung\svn-repos\scm-svn-test-at-sign'
while the proper (new) havior will produce a valid URI:
PS D:\Entwicklung\Projekte\maven-scm> svn ls
file:///D:/Entwicklung/svn-repos/scm-svn-test-at-sign
branches/
tags/
trunk/
See also [1] and [2] on the wrong implementation of File#toURI().
I would expect at least one new test that fails now, but will succeed
with the change.
That's right. I have added a test, it should fail on Windows. Before
merging back to trunk, I'd adapt for Windows and Unix-like.
Michael
[1] https://stackoverflow.com/a/17870390/696632
[2] https://blogs.msdn.microsoft.com/ie/2006/12/06/file-uris-in-windows/
On Tue, 01 May 2018 13:07:22 +0200, Michael Osipov
<micha...@apache.org> wrote:
Folks,
who seconds MNG-6386 for 3.5.4 which I have found during SCM-877.
${project.baseUri} is an invalid URL. NIO2 offers a solution for that.
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
