[ http://issues.apache.org/jira/browse/IVY-353?page=comments#action_12460713 ] Eric Crahen commented on IVY-353: ---------------------------------
Hey John, I use the useOrigin attribute wiht resolve and cachepath as you mentioned is your workaround. I was wondering if you could tell me more about the use case you have where you prefer to use retrieve. So far I've been able to use cachepath w/o trouble, but maybe you have hit a snag that I haven't yet... I don't know if its worth the trouble, but you could possibly detect Jakarta Commons IO and if its there, symlink (use Class.forName maybe) and if its not you could resort to copies. Might give me people the best of both worlds, it will always work - and if you have the extra dependency, then you get extra benefits (like you can resolve with ssh if you have jsch, webdav w/ commons vfs, etc.) > ivy:retrieve should be able to create symlinks > ---------------------------------------------- > > Key: IVY-353 > URL: http://issues.apache.org/jira/browse/IVY-353 > Project: Ivy > Issue Type: Wish > Components: Core > Affects Versions: 1.4.1 > Environment: Linux > Reporter: John Williams > Attachments: retrieve-symlinks.patch > > > It would be helpful if the "retrieve" task had an option to create symlinks > on systems that support them. The symlinks could point to either the cache > or a local repository (is useOrigin=true). > My company has a very long number of small projects, many of which depend on > some fairly large artifacts, so copying everything would be too slow and use > up too much disk space to be practical. (We work around this now by using > the "cachepath" task for instead of retrieve.) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
