You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Michael Osipov <mi...@apache.org> on 2018/05/01 11:07:22 UTC
Second MNG-6386
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-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Second MNG-6386
Posted by Michael Osipov <mi...@apache.org>.
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 <mi...@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
>>> <mi...@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-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Second MNG-6386
Posted by Robert Scholte <rf...@apache.org>.
+1
Robert
On Sat, 05 May 2018 13:46:45 +0200, Michael Osipov <mi...@apache.org>
wrote:
> Am 2018-05-05 um 13:23 schrieb Stephen Connolly:
>> On Sat 5 May 2018 at 09:13, Michael Osipov <mi...@apache.org> wrote:
>>
>>> Am 2018-05-05 um 09:15 schrieb Stephen Connolly:
>>>> On Thu 3 May 2018 at 22:10, Michael Osipov <mi...@apache.org>
>>>> wrote:
>>>>
>>>>> 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
>>>>>
>>>>> Robert,
>>>>>
>>>>> done some more digging and added unit and integration tests to it:
>>>>>
>>>>>
>>> https://github.com/apache/maven/commit/9d29bb4d91e9545a9b5bc2957646ad42d5add210
>>>>>
>>>>>
>>> https://github.com/apache/maven-integration-testing/commit/1f4912cda5f49b6ba36a2693bb5c1701ea4d9b86
>>>>>
>>>>> Though, the IT reasonably runs on Unix if UTF-8 is set as
>>>>> file.encoding.
>>>>> I have also updated the ticket with more description.
>>>>>
>>>>> I think that this issue should be pushed to 3.6.0.
>>>>
>>>>
>>>> Unclear why you think it should be dropped from 3.5.4. We’re not
>>>> changing
>>>> an API, only fixing a bug...
>>>
>>> This fix introduces a change in behavior. It might be unexpected in a
>>> fix release. If we are still OK for 3.5.4 then I am fine too.
>> Well if we are worried about any change in behaviour then we
>> shouldn’t make
>> any changes ever.
>> The question is whether this is “significant”.
>> One of my objections to semver is that it only focuses on APIs... so
>> under
>> semver:
>> 1. No breaking API method signature changes => no major version bump
>> 2. No new API methods => no minor version bump
>> 3. Must be patch
>> Now in the case of Maven, I argue for semver is a poor fit, largely
>> because
>> we have multiple APIs, SPIs and UIs each of which have different
>> measures
>> of breaking changes... but we only have one version number
>> We need to get 3.5.4 with the jansi fix out... simple bug fixes are
>> fine
>> for 3.5.4 too.
>> then we focus on the next version (3.6.x or 4.0.x) and move on... but
>> we
>> need to move the baseline to Java 8 at this stage and get Java 10
>> support
>> better (both of which i’d like to see in a 4.0.x so if we are missing
>> those
>> then it would be 3.6.x)
>
> Agreed, I'll move it to 3.5.4.
>
> Any other objections from someone else?
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Second MNG-6386
Posted by Michael Osipov <mi...@apache.org>.
Am 2018-05-05 um 13:23 schrieb Stephen Connolly:
> On Sat 5 May 2018 at 09:13, Michael Osipov <mi...@apache.org> wrote:
>
>> Am 2018-05-05 um 09:15 schrieb Stephen Connolly:
>>> On Thu 3 May 2018 at 22:10, Michael Osipov <mi...@apache.org> wrote:
>>>
>>>> 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
>>>>
>>>> Robert,
>>>>
>>>> done some more digging and added unit and integration tests to it:
>>>>
>>>>
>> https://github.com/apache/maven/commit/9d29bb4d91e9545a9b5bc2957646ad42d5add210
>>>>
>>>>
>> https://github.com/apache/maven-integration-testing/commit/1f4912cda5f49b6ba36a2693bb5c1701ea4d9b86
>>>>
>>>> Though, the IT reasonably runs on Unix if UTF-8 is set as file.encoding.
>>>> I have also updated the ticket with more description.
>>>>
>>>> I think that this issue should be pushed to 3.6.0.
>>>
>>>
>>> Unclear why you think it should be dropped from 3.5.4. We’re not changing
>>> an API, only fixing a bug...
>>
>> This fix introduces a change in behavior. It might be unexpected in a
>> fix release. If we are still OK for 3.5.4 then I am fine too.
>
>
> Well if we are worried about any change in behaviour then we shouldn’t make
> any changes ever.
>
> The question is whether this is “significant”.
>
> One of my objections to semver is that it only focuses on APIs... so under
> semver:
>
> 1. No breaking API method signature changes => no major version bump
> 2. No new API methods => no minor version bump
> 3. Must be patch
>
> Now in the case of Maven, I argue for semver is a poor fit, largely because
> we have multiple APIs, SPIs and UIs each of which have different measures
> of breaking changes... but we only have one version number
>
> We need to get 3.5.4 with the jansi fix out... simple bug fixes are fine
> for 3.5.4 too.
>
> then we focus on the next version (3.6.x or 4.0.x) and move on... but we
> need to move the baseline to Java 8 at this stage and get Java 10 support
> better (both of which i’d like to see in a 4.0.x so if we are missing those
> then it would be 3.6.x)
Agreed, I'll move it to 3.5.4.
Any other objections from someone else?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Second MNG-6386
Posted by Stephen Connolly <st...@gmail.com>.
On Sat 5 May 2018 at 09:13, Michael Osipov <mi...@apache.org> wrote:
> Am 2018-05-05 um 09:15 schrieb Stephen Connolly:
> > On Thu 3 May 2018 at 22:10, Michael Osipov <mi...@apache.org> wrote:
> >
> >> 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
> >>
> >> Robert,
> >>
> >> done some more digging and added unit and integration tests to it:
> >>
> >>
> https://github.com/apache/maven/commit/9d29bb4d91e9545a9b5bc2957646ad42d5add210
> >>
> >>
> https://github.com/apache/maven-integration-testing/commit/1f4912cda5f49b6ba36a2693bb5c1701ea4d9b86
> >>
> >> Though, the IT reasonably runs on Unix if UTF-8 is set as file.encoding.
> >> I have also updated the ticket with more description.
> >>
> >> I think that this issue should be pushed to 3.6.0.
> >
> >
> > Unclear why you think it should be dropped from 3.5.4. We’re not changing
> > an API, only fixing a bug...
>
> This fix introduces a change in behavior. It might be unexpected in a
> fix release. If we are still OK for 3.5.4 then I am fine too.
Well if we are worried about any change in behaviour then we shouldn’t make
any changes ever.
The question is whether this is “significant”.
One of my objections to semver is that it only focuses on APIs... so under
semver:
1. No breaking API method signature changes => no major version bump
2. No new API methods => no minor version bump
3. Must be patch
Now in the case of Maven, I argue for semver is a poor fit, largely because
we have multiple APIs, SPIs and UIs each of which have different measures
of breaking changes... but we only have one version number
We need to get 3.5.4 with the jansi fix out... simple bug fixes are fine
for 3.5.4 too.
then we focus on the next version (3.6.x or 4.0.x) and move on... but we
need to move the baseline to Java 8 at this stage and get Java 10 support
better (both of which i’d like to see in a 4.0.x so if we are missing those
then it would be 3.6.x)
>
> Michael
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
> --
Sent from my phone
Re: Second MNG-6386
Posted by Michael Osipov <mi...@apache.org>.
Am 2018-05-05 um 09:15 schrieb Stephen Connolly:
> On Thu 3 May 2018 at 22:10, Michael Osipov <mi...@apache.org> wrote:
>
>> 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
>>
>> Robert,
>>
>> done some more digging and added unit and integration tests to it:
>>
>> https://github.com/apache/maven/commit/9d29bb4d91e9545a9b5bc2957646ad42d5add210
>>
>> https://github.com/apache/maven-integration-testing/commit/1f4912cda5f49b6ba36a2693bb5c1701ea4d9b86
>>
>> Though, the IT reasonably runs on Unix if UTF-8 is set as file.encoding.
>> I have also updated the ticket with more description.
>>
>> I think that this issue should be pushed to 3.6.0.
>
>
> Unclear why you think it should be dropped from 3.5.4. We’re not changing
> an API, only fixing a bug...
This fix introduces a change in behavior. It might be unexpected in a
fix release. If we are still OK for 3.5.4 then I am fine too.
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Second MNG-6386
Posted by Stephen Connolly <st...@gmail.com>.
On Thu 3 May 2018 at 22:10, Michael Osipov <mi...@apache.org> wrote:
> 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
>
> Robert,
>
> done some more digging and added unit and integration tests to it:
>
> https://github.com/apache/maven/commit/9d29bb4d91e9545a9b5bc2957646ad42d5add210
>
> https://github.com/apache/maven-integration-testing/commit/1f4912cda5f49b6ba36a2693bb5c1701ea4d9b86
>
> Though, the IT reasonably runs on Unix if UTF-8 is set as file.encoding.
> I have also updated the ticket with more description.
>
> I think that this issue should be pushed to 3.6.0.
Unclear why you think it should be dropped from 3.5.4. We’re not changing
an API, only fixing a bug...
>
> Are those tests sufficient for you?
>
> Michael
> > On Tue, 01 May 2018 23:22:59 +0200, Michael Osipov <mi...@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
> >>> <mi...@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-unsubscribe@maven.apache.org
> >>>> For additional commands, e-mail: dev-help@maven.apache.org
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: dev-help@maven.apache.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
> --
Sent from my phone
Re: Second MNG-6386
Posted by Michael Osipov <mi...@apache.org>.
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
Robert,
done some more digging and added unit and integration tests to it:
https://github.com/apache/maven/commit/9d29bb4d91e9545a9b5bc2957646ad42d5add210
https://github.com/apache/maven-integration-testing/commit/1f4912cda5f49b6ba36a2693bb5c1701ea4d9b86
Though, the IT reasonably runs on Unix if UTF-8 is set as file.encoding.
I have also updated the ticket with more description.
I think that this issue should be pushed to 3.6.0.
Are those tests sufficient for you?
Michael
> On Tue, 01 May 2018 23:22:59 +0200, Michael Osipov <mi...@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
>>> <mi...@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-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Second MNG-6386
Posted by Robert Scholte <rf...@apache.org>.
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 <mi...@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
>> <mi...@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-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Second MNG-6386
Posted by Michael Osipov <mi...@apache.org>.
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 <mi...@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-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Second MNG-6386
Posted by Robert Scholte <rf...@apache.org>.
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.
I would expect at least one new test that fails now, but will succeed with
the change.
thanks,
Robert
On Tue, 01 May 2018 13:07:22 +0200, Michael Osipov <mi...@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-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org