Github user nlalevee commented on the issue:
https://github.com/apache/ant-ivy/pull/20
merged. Thank both of you.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and
Github user jaikiran commented on the issue:
https://github.com/apache/ant-ivy/pull/20
I've now updated this PR to not focus on the usage of `:` in versions and
instead test the FileUtil's method itself.
---
If your project is set up for it, you can reply to this email and have
Github user jaikiran commented on the issue:
https://github.com/apache/ant-ivy/pull/20
>> So @jaikiran, would you consider rewrite the unit test to just test
FileUtil.dissect ?
Yes, certainly. I will update this PR with the testcase tomorrow.
---
If your project is set up
Github user nlalevee commented on the issue:
https://github.com/apache/ant-ivy/pull/20
So let's get out of scope of this PR the support of weird characters in
version, organisation or module name. Especially since the set of supported
characters depends on the filesystem, which is
Github user twogee commented on the issue:
https://github.com/apache/ant-ivy/pull/20
On the second thought, if PR changes the way to identify the system root,
then the test cases should be specifically for that, not for parsing of
versions with reserved/unsafe URL characters.
---
Github user twogee commented on the issue:
https://github.com/apache/ant-ivy/pull/20
"Making something that worked previously on a specific platform in specific
circumstances work again" is not a good argument, especially when the coverage
of the test case is incomplete. Unless this
Github user jaikiran commented on the issue:
https://github.com/apache/ant-ivy/pull/20
I think both me and Nicolas agree that this "fix" isn't going to solve the
case where this and other similar characters can't be fully supported as long
as we are using the module descriptor
Github user twogee commented on the issue:
https://github.com/apache/ant-ivy/pull/20
I can assure you that colon in version has NEVER have worked on Windows.
Test case
```
import java.io.*;
public class TestColonNTFS {
public static void main(String[]
Github user nlalevee commented on the issue:
https://github.com/apache/ant-ivy/pull/20
I agree with you both.
Ivy has never specified a version scheme, and it is kind of its strength,
it can be compatible with a lot of use case. We should continue to do so.
But we shouldn't
Github user twogee commented on the issue:
https://github.com/apache/ant-ivy/pull/20
I am afraid that Ivy allows for a misfeature here. Note that you must test
this on Windows because colon is not allowed in NTFS filenames:
https://kb.acronis.com/content/39790
---
If your project
Github user jaikiran commented on the issue:
https://github.com/apache/ant-ivy/pull/20
The latest build completed successfully
https://builds.apache.org/job/Ivy-GithubPR/15/console.
Coming to the question:
> Why not sticking only to well-known versioning schemes:
Github user jaikiran commented on the issue:
https://github.com/apache/ant-ivy/pull/20
Looking at the logs, the BasicURLHandler seems to have crashed because the
Jenkins process was killed due to:
```
[junit] Running org.apache.ivy.util.url.BasicURLHandlerTest
Github user nlalevee commented on the issue:
https://github.com/apache/ant-ivy/pull/20
I have increased the timeout to 20m
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
Github user twogee commented on the issue:
https://github.com/apache/ant-ivy/pull/20
BasicURLHandler crashed... ":" need to be URL encoded?
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have
14 matches
Mail list logo