I left out the generification of Filter, because NoFilter is a singleton. I'll be leaving out attribute Maps (global or local), because their values can be Strings or Matchers (this is where the story with IvyDE started, I was not sure what to expect from one such Map).
Anything else that is pretty unambiguous can be generified just to clear out the room. Once that is done, the remaining cases must be thoroughly discussed. I added binary compatibility checks to stress the point that generification does not break binary compatibility as long as erasures stay the same. Gintas 2017-06-20 13:35 GMT+02:00 Jaikiran Pai <jai.forums2...@gmail.com>: > Gintas, can you list the exact nature of changes for some specific classes > that you think this effort might involve? I know you already sent me some > samples, but it would be good if the rest know what kind of changes are > involved. > > Personally, my opinion on this is - if it’s internal implementation > details that this change involves (like private fields or methods of > certain classes), it’s fine to do that in the upcoming release. But if it’s > more than that, then IMO, we should hold on to that for a bit and evaluate > it in some subsequent release so that we don’t do too many changes without > evaluating the kind of impact it has on the external libraries that use Ivy. > > Ultimately, I believe this will come down to a case-by-case basis. > > -Jaikiran > > On 19-Jun-2017, at 10:12 AM, Gintautas Grigelionis < > g.grigelio...@gmail.com> wrote: > > During a discussion about goals for Ivy 2.5, I mentioned generics [1]. > I was looking into the matter because I was investigating how IvyDE hooks > into Ivy and I didn't quite like what I saw. > I'd like to generify Ivy as much as possible for 2.5 (staying binary > compatible, of course) so that decisions for the next release could be more > informed. > > Should you agree, I'd finish the work with two more commits (one for core > and one for plugins package) -- I pushed two commits already that ended up > in PR #45. > > Now, I'll digress, but I believe it's worth mentioning. Apart from > generics, there's one last thing I'd like to have in Ivy 2.5, and that's > SVG in Ivy reports. I only heard one opinion (which was positive) about the > non-limbless ant in vectorised Ivy logo, and no protests, so I take it as a > silent approval :-) BTW I hope asciidoc can inline SVG in HTML, although > some repeating icons would better be placed in CSS (as mentioned in > comments to PR #39). > > [1] > http://mail-archives.apache.org/mod_mbox/ant-dev/201705.mbox/% > 3CCALVNWHXiZPVJmKimTB9Qxo9u6%2BNX%2Br7Kpmk3uvZvqtUxLQpekQ% > 40mail.gmail.com%3E > > Gintas > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org > For additional commands, e-mail: dev-h...@ant.apache.org > >
