On 2018-02-18, Gintautas Grigelionis wrote: > 2018-02-18 20:30 GMT+01:00 Stefan Bodewig <bode...@apache.org>:
>> On 2018-02-18, Gintautas Grigelionis wrote: >>> - https://github.com/apache/ant-ivy/pull/63 (has to do with choice of >>> generics, with are not set in stone yet); >> changes the generic type of an argument of a public method inside a >> public class. > That's obvious. Any suggestions? I'm not familiar with the Ivy code base so all I can suggest is along general lines of "think about a different approach" and "document the break of backwards compatibility if unavoidable". This case is specifically tricky as you will only run into problems at runtime (unless you recompile your code) thanks to type erasure. Existing compiled code that invokes doesCallersExclude with a Stack of ModuleRevisionIds will be allowed to call the method. >> - https://github.com/apache/ant-ivy/pull/64 (in production at TomTom; >>> should we look for a more general solution, or just document that >>> preemptive authentication restricts to basic scheme?); >> adds a new method to a public interface (URLHandler). > Java 8, then. Not my call. >>> - https://github.com/apache/ant-ivy/pull/67 (a one-liner; anybody >>> sees some side effects?) >> I don't understand the issue. Is this a documented way of using Ivy or >> why would anybody expect it to be possible to invoke Ant via the Ivy >> jar? > Somebody was interested enough to open a JIRA issue. And the case is around > the use which is definitely documented. Let me rephrase. Is this a use-case the Ivy developers want to support? Stefan --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
