[
https://issues.apache.org/jira/browse/IVY-1522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16018703#comment-16018703
]
ASF GitHub Bot commented on IVY-1522:
-------------------------------------
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 attributes (via patterns of course) for
file names. That's not the goal of this PR.
I haven't ever tested the issue at hand on Windows, so I can't say one way
or the other, but the issue noted in the JIRA was apparently working in a
previous version of Ivy. This PR is an attempt to do 2 things:
- Let the previously working user project, work again.
- Change the implementation detail in that method, which is changed in this
commit, to use a different way to identify file system root, instead of relying
on the presence of a specific character to determine that. So irrespective of
whether we support the colon (and other similar characters), this change
probably still is worth it.
> Ivy 2.4.0 improperly handles modules with colon (:) in version
> --------------------------------------------------------------
>
> Key: IVY-1522
> URL: https://issues.apache.org/jira/browse/IVY-1522
> Project: Ivy
> Issue Type: Bug
> Components: Core
> Affects Versions: 2.4.0
> Reporter: Daniel Holmes
> Priority: Critical
>
> This was not an issue in 2.2.0.
> I have some modules in my project which produce debian .deb files and those
> modules versions include a colon ':' in the version because the version
> scheme was reset, so an epoch is set.
> Also for this module the ivy.xml declaration uses extends tag, and in
> processing the parent location, this code in FileUtil which is called during
> a FileUtil.normalize() is causing the : in the resolve parent file name to
> have the ':' replaced with a ':/'.
> The comment on the it seems to explain that it is trying to handle a
> Windows/NetWare case, but the assumption to process any colon in the path is
> too broad and is negatively affecting my case which is executing on a linux
> system. Even on windows, this would only be attempting to address a drive
> letter case, right, where colon would occur only after a single letter in the
> path?
> private static String[] dissect(String path) {
> char sep = File.separatorChar;
> path = path.replace('/', sep).replace('\\', sep);
> // // make sure we are dealing with an absolute path
> // if (!isAbsolutePath(path)) {
> // throw new BuildException(path + " is not an absolute path");
> // }
> String root = null;
> int colon = path.indexOf(':');
> if (colon > 0) { // && (ON_DOS || ON_NETWARE)) {
> int next = colon + 1;
> root = path.substring(0, next);
> char[] ca = path.toCharArray();
> root += sep;
> // remove the initial separator; the root has it.
> next = (ca[next] == sep) ? next + 1 : next;
> StringBuffer sbPath = new StringBuffer();
> // Eliminate consecutive slashes after the drive spec:
> for (int i = next; i < ca.length; i++) {
> if (ca[i] != sep || ca[i - 1] != sep) {
> sbPath.append(ca[i]);
> }
> }
> path = sbPath.toString();
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
