There might be some issues with Cygwin, see Eclipse/JGit discussion [1] Gintas
[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=354367 2017-07-27 10:44 GMT+02:00 Jan Matèrne (jhm) <apa...@materne.de>: > If the new Java version supports the symlink creation and it's an > implementation detail > of Ivy (so not part of an API other could use) I am in favour of getting > rid of the old > implementation. > Getting rid of that means being more standard compliant and having less to > maintain. ;) > > Jan > > > > > -----Ursprüngliche Nachricht----- > > Von: Nicolas Lalevée [mailto:nicolas.lale...@hibnet.org] > > Gesendet: Mittwoch, 26. Juli 2017 18:19 > > An: Ant Developers List > > Betreff: Re: Ivy - Move to symlink creation standard Java API? > > > > > > > Le 26 juil. 2017 à 15:25, Jaikiran Pai <jai.forums2...@gmail.com> a > > écrit : > > > > > > I was looking into a JIRA related to symlinking in Ivy and realized > > that (for reasons noted in the docs and the implementation) > > ourimplementation of symlinking relies on launching a process from > > within the JVM to invoke a shell command to create the symlinks. > > "retrieve" task is the only one that deals with symlink creation, from > > what I can see. Furthermore, knowing that this operation is expensive, > > we even had to introduce an additional optionfor that task to allow > > "mass symlinking"[1] so that we launch a single process to create N > > symlinks instead of N processes. > > > > > > In short, the current implementation of symlinking in Ivy is > > expensive for reasons that have been known. Now that we have moved to > > Java 7, which has a standard APIfor symlink creation[2], I think we > > should just change our internal implementation to use this new standard > > API.Of course, we continue to fail to create symlinks on systems that > > don't support it, just like we do now, except that we let the Java API > > implementation handle those details. > > > > > > Furthermore, once we move to thisstandard API, I don't think we need > > the "symlinkmass" option onthe retrieve task anymore since the whole > > purpose of it was to avoid launching N processes. So I think we can > > deprecate that option in the upcoming release. > > > > > > Any thoughts? > > > > Sounds good to me. > > > > Nicolas > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional > > commands, e-mail: dev-h...@ant.apache.org > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org > For additional commands, e-mail: dev-h...@ant.apache.org > >
