AW: Ivy - Move to symlink creation standard Java API?
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 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
Re: Ivy - Move to symlink creation standard Java API?
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) : > 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 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 > >
Re: Ivy - Move to symlink creation standard Java API?
I did a few simple tests on Windows 7 + Cygwin and NIO.2 seems to work just fine (if privilege to create symlinks is granted). +1 Gintas 2017-07-27 11:40 GMT+02:00 Gintautas Grigelionis : > 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) : > >> 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 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 >> >> >
[GitHub] ant-ivy pull request #55: use vectorised logo
GitHub user twogee opened a pull request: https://github.com/apache/ant-ivy/pull/55 use vectorised logo I'd like to remove downloaded.gif, error.gif, evicted.gif and searched.gif as well. Maybe we could vote on colours for downloaded and evicted ð if green is too dark or fuchsia is too garish (I took it because it's one of "safe" colours). You can merge this pull request into a Git repository by running: $ git pull https://github.com/twogee/ant-ivy svg-logo Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ant-ivy/pull/55.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #55 commit 4fc1b04068194894decd755db032a6ed91063b6e Author: twogee Date: 2017-07-27T13:32:44Z use vectorised logo --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: Ivy - Move to symlink creation standard Java API?
Thank you for testing that kind of setup. I have now pushed a commit which does the necessary changes to use Java standard API and also deprecates that use of symlinkmass option (which is no longer relevant) of the retrieve task. The testcases have been updated to make sure the tests are run on all systems (earlier they used to be run only on specific systems) and the logic in the tests has been updated to do a more robust check on ability to create symbolic links. I have also updated the documentation and release notes to note and explain the deprecation of the symlinkmass option. -Jaikiran On 27/07/17 5:07 PM, Gintautas Grigelionis wrote: I did a few simple tests on Windows 7 + Cygwin and NIO.2 seems to work just fine (if privilege to create symlinks is granted). +1 Gintas 2017-07-27 11:40 GMT+02:00 Gintautas Grigelionis : 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) : 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 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 - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: AW: Ivy - Move to symlink creation standard Java API?
On 27/07/17 2:14 PM, Jan Matèrne (jhm) wrote: Getting rid of that means being more standard compliant and having less to maintain. ;) Agreed. Plus the fact that our previous implementation of this feature relied on the presence of the "ln" command on the systems, which effectively ruled out this feature on native Windows completely. With the usage of the standard API, that's no longer the case. -Jaikiran - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
[GitHub] ant-ivy pull request #:
Github user twogee commented on the pull request: https://github.com/apache/ant-ivy/commit/366fb741f0772c8309f9dfe963f6032b091d7b89#commitcomment-23334637 Perhaps `UnsupportedOperationException` would be a useful heuristic? --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
[GitHub] ant-ivy pull request #:
Github user jaikiran commented on the pull request: https://github.com/apache/ant-ivy/commit/366fb741f0772c8309f9dfe963f6032b091d7b89#commitcomment-23334838 Do you mean for the `symlinkmass` deprecation? In this release, I just wanted it to be deprecated with a log message showing up so that it doesn't blow up existing builds where user might be using that option. Internally, setting that option to `true` in the upcoming version will be same as setting the `symlink` to `true` and that's intentional to allow backward compatibility for at least one or two releases till users have a chance to remove that option in their builds. A few releases down the line, we will just remove that option and that will result in a relevant exception. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
[GitHub] ant-ivy issue #53: Suppressed warnings
Github user jaikiran commented on the issue: https://github.com/apache/ant-ivy/pull/53 Commit https://github.com/apache/ant-ivy/pull/53/commits/414651c8841a09a9d9d4b0365ee8e7227fba8429 in this PR has now been merged to upstream https://github.com/apache/ant-ivy/commit/1a283ab1be5b495f5be8cf6c2ab2b96453dd32f9 It had a merge conflict against latest upstream master which I had to resolve during the review/merge. At this point, the only remaining commit that needs review in this PR is this one https://github.com/apache/ant-ivy/pull/53/commits/b7c26ac4ea31369e7c0945aea8552280857f951a. Given that this hasn't been rebased against latest master branch, can you please close this PR and reopen a new one containing this one single commit, rebased against latest master. That commit includes changes to many files, so having it rebased against latest master will help review it properly. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Is CacheResolver relevant?
There's this JIRA issue https://issues.apache.org/jira/browse/IVY-804 where the user reports a genuine bug in our typedef.properties file where we list the "cache" property twice with different values. Once to consider the element as a resolver and the other to consider the element as the cache configurations. This is a genuine bug and I suspect what this implies is that the "cache resolver" has never worked in the past decade (that's when this entry was added). Furthermore, although there's a CacheResolver[1] which represents this element, I don't see any references to that class in our code and no tests either. Also, our documentation doesn't mention it either. There's a JIRA[2] asking for the docs to be updated to explain this resolver. Is this resolver being used and should this be supported? If it has to be supported, from what I see, it will involve fixing this typedef.properties and adding some kind of enhancement to our Ivy settings parser so that it can uniquely understand what this duplicated "cache" name means in different context. Probably won't be easy, but if we do want to support this, I think that's what we will have to do. On the other hand, if we don't have to support this, then I can just remove it from that typedef.properties file. [1] https://github.com/apache/ant-ivy/blob/master/src/java/org/apache/ivy/plugins/resolver/CacheResolver.java [2] https://issues.apache.org/jira/browse/IVY-804 -Jaikiran - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: Is CacheResolver relevant?
On 27/07/17 9:34 PM, Jaikiran Pai wrote: There's a JIRA[2] asking for the docs to be updated to explain this resolver. ... [2] https://issues.apache.org/jira/browse/IVY-804 I meant this JIRA which asks for it to be documented https://issues.apache.org/jira/browse/IVY-612 -Jaikiran - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
[GitHub] ant-ivy pull request #:
Github user twogee commented on the pull request:
https://github.com/apache/ant-ivy/commit/6607bdcb3ba69d2ab4f41be6292cc5a6df6365ba#commitcomment-23339716
In URLHandlerDispatcher,
```
@Override
public void download(final URL src, final File dest, final
CopyProgressListener l) throws IOException {
this.download(src, dest, l);
}
@Override
public void upload(final File src, final URL dest, final
CopyProgressListener l) throws IOException {
this.upload(src, dest, l);
}
```
look like recursion? Surely a default timeout constraint is missing?
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org
[GitHub] ant-ivy issue #53: Suppressed warnings
Github user twogee commented on the issue: https://github.com/apache/ant-ivy/pull/53 With all due respect, there are some refactorings worth attention IMHO. Besides, some deprecations need to be followed through ð --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
[GitHub] ant-ivy pull request #56: use “Maven 2” consistently
GitHub user twogee opened a pull request: https://github.com/apache/ant-ivy/pull/56 use âMaven 2â consistently You can merge this pull request into a Git repository by running: $ git pull https://github.com/twogee/ant-ivy maven-2-in-asciidoc Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ant-ivy/pull/56.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #56 commit 43c4b48d2f0cbac6c0a8fda4b98f599202de9678 Author: twogee Date: 2017-07-27T19:32:14Z use âMaven 2â consistently --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
[GitHub] ant-ivy pull request #57: fix last inconsistencies in generics
GitHub user twogee opened a pull request: https://github.com/apache/ant-ivy/pull/57 fix last inconsistencies in generics ... use collections, not arrays You can merge this pull request into a Git repository by running: $ git pull https://github.com/twogee/ant-ivy consistent-generics Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ant-ivy/pull/57.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #57 commit e849096d3fb0070b0e4d5d387e38a2b7a42ebf8e Author: twogee Date: 2017-07-27T19:38:15Z fix last inconsistencies in generics (use collections, not arrays) --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
[GitHub] ant-ivy pull request #:
Github user twogee commented on the pull request: https://github.com/apache/ant-ivy/commit/366fb741f0772c8309f9dfe963f6032b091d7b89#commitcomment-23340291 Sorry for a terse suggestion, I meant we could provide more information to the end user about the symlink/symlinkmass now that the former could be made to work on NTFS 3.1; but that's an excess if the focus is on deprecation. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: Ivy logo as SVG
In case you missed among all GitHub chat: the SVG (and Draw 2D :-) logo has arrived as PR-55. A shoutout to Flamingo project ( https://github.com/kirill-grouchnikov/flamingo) and its SVG transcoder (http://ebourg.github.io/flamingo-svg-transcoder/). Gintas 2017-06-08 16:46 GMT+02:00 Dominique Devienne : > On Thu, Jun 8, 2017 at 4:35 PM, Gintautas Grigelionis < > g.grigelio...@gmail.com> wrote: > > > https://drive.google.com/open?id=0B2mVPD7ZO6sdcDFkX1lQdHJWZVRwU > > UdSSXI1VnF3bk5xTFhF > > > I like it! --DD >
[GitHub] ant-ivy pull request #56: use “Maven 2” consistently
Github user asfgit closed the pull request at: https://github.com/apache/ant-ivy/pull/56 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: Is CacheResolver relevant?
Perhaps another JIRA issue [1] would cast some light? [1] https://issues.apache.org/jira/browse/IVY-1227 Gintas 2017-07-27 18:10 GMT+02:00 Jaikiran Pai : > > On 27/07/17 9:34 PM, Jaikiran Pai wrote: > >> There's a JIRA[2] asking for the docs to be updated to explain this >> resolver. >> >> ... >> [2] https://issues.apache.org/jira/browse/IVY-804 >> > I meant this JIRA which asks for it to be documented > https://issues.apache.org/jira/browse/IVY-612 > > > -Jaikiran > > - > To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org > For additional commands, e-mail: dev-h...@ant.apache.org > >
Re: Is CacheResolver relevant?
Here's a relevant discussion [1] with Xavier himself explaining the reason for cache resolver being there. [1] http://apache-ivy.996301.n3.nabble.com/Does-Ivy-really-have-a-cache-resolver-td3648.html Gintas P.S. It's unrelated, but, while researching, I came across this issue: [1] https://github.com/sbt/sbt/issues/368 Perhaps it's worth looking into? 2017-07-28 7:44 GMT+02:00 Gintautas Grigelionis : > Perhaps another JIRA issue [1] would cast some light? > > [1] https://issues.apache.org/jira/browse/IVY-1227 > > Gintas > > 2017-07-27 18:10 GMT+02:00 Jaikiran Pai : > >> >> On 27/07/17 9:34 PM, Jaikiran Pai wrote: >> >>> There's a JIRA[2] asking for the docs to be updated to explain this >>> resolver. >>> >>> ... >>> [2] https://issues.apache.org/jira/browse/IVY-804 >>> >> I meant this JIRA which asks for it to be documented >> https://issues.apache.org/jira/browse/IVY-612 >> >> >> -Jaikiran >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org >> For additional commands, e-mail: dev-h...@ant.apache.org >> >> >
