2017-09-24 15:03 GMT+02:00 Nicolas Lalevée <nicolas.lale...@hibnet.org>:

>
> > Le 11 sept. 2017 à 21:45, Gintautas Grigelionis <g.grigelio...@gmail.com>
> a écrit :
> >
> > I'd like to have https://issues.apache.org/jira/browse/IVY-1420
> included in
> > the upcoming release.
>
> Every bug is important, but I think releasing often is more important.
> Apart from IVY-1485 which is kind of special, I think we should release
> what we have.
>

I need about a week (maybe less) for IVY-1420. It would be nice at least to
fix the inconsistency in the documentation (I can commit that separately --
do I need to open a Jira issue?).


> > There were few opinions about using SVG graphics, so I'm not sure whether
> > the proposals could just simply be merged. It would be nice to refresh
> the
> > site for the 10th anniversary of graduation from the incubator, though.
>
> I had a quick look, but as commented in an earlier email, the commit in
> your PR brings a lot of stuff. I haven’t noticed anything wrong about the
> SVG stuff (I was worried about the huge IvyLogo.java duplicating the svg
> file, but it was nicely documented that it was generated and how, so it is
> OK). But if you want a more proper review, please make a dedicated PR.
>

AFAICS PR-55 is self-contained. It adds an SVG logo + an icon class where
SVG is converted to Java 2D in order to avoid carrying Batik around for
doing the same stuff on the fly. The corresponding bitmaps are/can be
removed. Then, the same SVG logo is inlined in XSL fo resolve report along
with 4 other inlined SVG icons that replace the bitmaps (which fixes
IVY-922). CSS is adjusted. I cannot see how the PR could be reduced further.

There is a separate PR-60 which adds SVG inlined in CSS to the menus (and
removes the corresponding bitmaps). The fix for IVY-450, which concerns
menus as well, is in a separate commit.

> Finally, there is a contentious issue of API change regarding the use of
> > generics. Arrays of generics is a no-no in Java [1]. Thus, the method in
> > question should be deprecated. IMHO, the suggested mitigation by
> providing
> > a default implementation of the new method in terms of the old one in the
> > abstract class is sufficient for the use cases found in the wild.
>
> IIRC, we agree to a least make the change in a backward compatible way,
> and then have a deeper discussion (vote?) about an API break. Are we still
> on track ?
>

The change can be made in a completely backward compatible way in Java 9,
which has interface methods. Until then, interface changes will cause
trouble for those who implement the interface directly rather than
extending some class. That's the whole issue, unless I missed something. We
need to change that API though... I guess that would be appreciated on
Scala/SBT side.

Gintas


> Nicolas
>
> >
> > Gintas
> >
> > [1] https://docs.oracle.com/javase/tutorial/java/generics/restri
> ctions.html
> >
> > 2017-09-11 17:05 GMT+02:00 Jaikiran Pai <jai.forums2...@gmail.com>:
> >
> >> It's been a while since we have decided to revive the Ivy project and
> work
> >> towards a usable release. Since then, we have fixed a good number of
> bugs,
> >> added some enhancements and updated the documentation (we also switched
> to
> >> asciidoc based docs internally). When we started this, the goal was to
> >> reach a certain state where we can do a release. At this point, IMO, we
> are
> >> _almost_ there to do the release. I say almost because, there's one
> >> specific bug that I want to be fixed in this release -
> >> https://issues.apache.org/jira/browse/IVY-1485. There's been a
> discussion
> >> about what it involves and why it isn't an easy fix in this mailing list
> >> before. I have been working on it and as was expected, it's a bit
> complex
> >> and since it touches a critical part of the code, I don't want to rush
> it.
> >>
> >> The past few weeks, I have been shifting between this issue and fixing
> >> certain other issues that have been reported in JIRA. But at this
> point, I
> >> plan to just focus on this single issue (and one minor task involving
> >> reviewing the tutorial docs), before I personally consider things done
> for
> >> this release.
> >>
> >> -Jaikiran
> >>
> >>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> 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
>
>

Reply via email to