You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@ant.apache.org by "Maarten Coene (JIRA)" <ji...@apache.org> on 2011/03/16 00:15:29 UTC

[jira] Resolved: (IVY-1268) Valid Path does not work for Filesystem Resolver

     [ https://issues.apache.org/jira/browse/IVY-1268?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Maarten Coene resolved IVY-1268.
--------------------------------

    Resolution: Fixed
      Assignee: Maarten Coene

I had a similar issue last week on solaris which I couldn't reproduce on Windows. I was able to submit a patch in SVN trunk that fixes that specific problem. But I think it will also solve yours. Could you try it out in your environment?

thanks,
Maarten

> Valid Path does not work for Filesystem Resolver
> ------------------------------------------------
>
>                 Key: IVY-1268
>                 URL: https://issues.apache.org/jira/browse/IVY-1268
>             Project: Ivy
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 2.2.0
>         Environment: CentOS5
>            Reporter: Jonathan Williams
>            Assignee: Maarten Coene
>            Priority: Minor
>
> I'm using Ivy 2.2.0 in my current project. I've specified a filesystem resolver and I was playing around with how the root directory to look under for the ivy and artifact patterns is derived. Through playing around with the path, I encountered some odd/buggy behavior where I could specify a valid path but would fail to resolve the file.
> <ivysettings>
> <properties file="../../properties/path.properties"/>
> <property name="repo.dir" value="${filesystem.repo.root}"/>
> <resolvers>
> <filesystem name="local" m2compatible="true">
>                 <ivy pattern="${repo.dir}/[organisation]/[module]/ivy.xml"/>
>                 <artifact pattern="${repo.dir}/[organisation]/[module]/[artifact].[ext]"/>
> </filesystem>
> </resolvers>
> </ivysettings>
> path.properties is a file generated by a script prior to building. Originally I was hardcoding the value for ${filesystem.repo.root} in the generating script, but I wanted to start deriving the path. When I generated the path, the resolve suddenly started failing. However, at the command line, I was able to copy the jar and ivy file from the repo manually using 'cp' and the output of the failed call to ivy:retrieve, meaning the path was valid, but the resolve was failing.
> module not found: org.slf4j#slf4j;1.6.1
> [ivy:retrieve]     ==== local: tried
> [ivy:retrieve]       /opt/workspace/ums/UMS/main/build/developer/../.cache/../../../lib/org/slf4j/slf4j/1.6.1/ivy.xml
> [ivy:retrieve]       -- artifact org.slf4j#slf4j;1.6.1!slf4j.jar:
> [ivy:retrieve]       /opt/workspace/ums/UMS/main/build/developer/../.cache/../../../lib/org/slf4j/slf4j/1.6.1/slf4j-1.6.1-jar.jar
> However, a path like /opt/workspace/ums/UMS/main/build/developer/../../../lib/org/slf4j/slf4j/1.6.1/ivy.xml resolves just fine and my build works.
> The same behavior holds true if I specify the path directly in the ivy and artifact pattern, so it isn't an issue with the path.properties file.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira