[
https://issues.apache.org/jira/browse/IVY-1475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16047673#comment-16047673
]
ASF GitHub Bot commented on IVY-1475:
-------------------------------------
Github user jaikiran commented on the issue:
https://github.com/apache/ant-ivy/pull/38
>> requireCommonBaseDir:
>> could we replace firstPath by base==null?
>> line 115: additional comment:
>> 'fail fast: ...'
>> line 117: 'finally we got ...'
Done and PR updated
>> getBaseDir:
>>
>> Rename parameter to file1 and file2. For me it seems that both
parameters are indepent from each other. 'base' implies that it's itself a
parent of the other.
You are right about that. So I changed the param names and updated the
javadoc too. Please have a look in the updated PR and let me know if it makes
sense now.
>> you changed the semantic of the method:
>> base==null && file==null --> old=NPE, new=null (ok with me ;)
>> base==null && file!=null --> old=file.paren, new=null (incompatible
change)
>> base!=null && file==null --> both=null
>> base!=null && file!=null --> both=commonBase
>> could be static, maybe moved to a FileUtil-class
When I started implementing the changes for this bug fix, I had a look at
this method and its references. In reality, this `getBaseDir` essentially
can/should be a private method. The only reason why it's package private right
now is to have access to this method in a test case. There are no other
references to this and given that this is a package private method, there's no
other way this method can be by any other (external) code then that specific
package. Given this background, I decided to intentionally make that
incompatible semantic change so that it now fits in with the expectations of
how we want it to behave. Do you think that should be good enough reason to go
ahead with this change in semantics of this method?
> ivy:cachefileset fails with String index out of range on Windows
> ----------------------------------------------------------------
>
> Key: IVY-1475
> URL: https://issues.apache.org/jira/browse/IVY-1475
> Project: Ivy
> Issue Type: Bug
> Components: Ant
> Affects Versions: 2.4.0-RC1
> Environment: Windows
> Reporter: Patrice Matignon
>
> On Windows, the ant task <ivy:cachefileset /> can fail with the stack trace
> below, when the resolve includes artifacts located in separate directories in
> separate drives (e.g. c:\ivy2/cache/... ; d:\ivy2\cache ).
> The underlying issue is that cachefileset is an ant fileset and as such it
> requires a base dir.
> Nevertheless, the implementation for this ant task doesn't handle this
> scenario properly: it attempts to find the common base dir for all the
> resolved artifacts, except that every time it runs into a conflicting
> artifacts, it just loses the information and ends up reporting an invalid
> base dir, which causes a fatal StringIndexOutOfBoundsException later in that
> task.
> A sample stacktrace (the actual reported index varies):
> C:\src\trunk\build.xml:839: impossible to build ivy cache fileset:
> java.lang.StringIndexOutOfBoundsException: String index out of range: -24
> at java.lang.String.substring(String.java:1937)
> at java.lang.String.substring(String.java:1904)
> at org.apache.ivy.ant.IvyCacheFileset.getPath(IvyCacheFileset.java:114)
> at org.apache.ivy.ant.IvyCacheFileset.doExecute(IvyCacheFileset.java:82)
> at org.apache.ivy.ant.IvyTask.execute(IvyTask.java:271)
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
