[GitHub] ant-ivy issue #57: fix last inconsistencies in generics

2017-08-07 Thread twogee
Github user twogee commented on the issue: https://github.com/apache/ant-ivy/pull/57 @nlalevee, we already broke a few things by going Java 7 (and gained native symlinks 😉). For more examples, look at commons-lang3 breaking off commons-text and introducing escapeHtml3 and

[GitHub] ant-ivy issue #57: fix last inconsistencies in generics

2017-08-06 Thread nlalevee
Github user nlalevee commented on the issue: https://github.com/apache/ant-ivy/pull/57 @twogee, you have looked into the open sources softwares that use Ivy, but Ivy is under the ASL, not the GPL, it might be used in some closed, commercial products :) So we cannot know for sure

[GitHub] ant-ivy issue #57: fix last inconsistencies in generics

2017-08-02 Thread twogee
Github user twogee commented on the issue: https://github.com/apache/ant-ivy/pull/57 Thanks for clarifying. My point was that the use of the method is limited to two classes: `SearchEngine` and `ChainResolver` (because it is essentially a proxy). A quick search seems

[GitHub] ant-ivy issue #57: fix last inconsistencies in generics

2017-08-02 Thread jaikiran
Github user jaikiran commented on the issue: https://github.com/apache/ant-ivy/pull/57 Hi Gintas, To be clear - what I meant/proposed in the dev list was: - It's fine to have all the changes related to introducing that new method with Java generics on the

[GitHub] ant-ivy issue #57: fix last inconsistencies in generics

2017-07-28 Thread twogee
Github user twogee commented on the issue: https://github.com/apache/ant-ivy/pull/57 Is this sufficient, or should I add an extra check in `ChainResolver` ``` if (resolver instanceof AbstractResolver || hasGenericMethod(resolver)) { ... }

[GitHub] ant-ivy issue #57: fix last inconsistencies in generics

2017-07-28 Thread twogee
Github user twogee commented on the issue: https://github.com/apache/ant-ivy/pull/57 The same applies to `ChainResolver` (which should check resolver type as suggested by @jaikiran); actually, all custom resolvers that do not extend `AbstractResolver` could be wrapped in chain

[GitHub] ant-ivy issue #57: fix last inconsistencies in generics

2017-07-28 Thread twogee
Github user twogee commented on the issue: https://github.com/apache/ant-ivy/pull/57 The methods in `AbstractResolver` must be defined the other way around: the default implementation of the method with new signature should call the method with the old signature. May I amend the

[GitHub] ant-ivy issue #57: fix last inconsistencies in generics

2017-07-28 Thread twogee
Github user twogee commented on the issue: https://github.com/apache/ant-ivy/pull/57 BTW, the old method is still there, the implementation is in the abstract class, `AbstractResolver`. --- If your project is set up for it, you can reply to this email and have your reply appear on

[GitHub] ant-ivy issue #57: fix last inconsistencies in generics

2017-07-28 Thread twogee
Github user twogee commented on the issue: https://github.com/apache/ant-ivy/pull/57 The new method is taken from `AbstractOSGiResolver` where a corresponding method is made public. All resolvers implement only the new method and the fallback for the deprecated method is moved to

[GitHub] ant-ivy issue #57: fix last inconsistencies in generics

2017-07-28 Thread jaikiran
Github user jaikiran commented on the issue: https://github.com/apache/ant-ivy/pull/57 Overall, this looks fine to me. I just need some inputs from the rest of the team on one specific change, for which I have raised a dev list thread