You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by Jaikiran Pai <ja...@gmail.com> on 2017/09/11 15:05:34 UTC
Ivy upcoming release - where we stand
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-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Ivy upcoming release - where we stand
Posted by Nicolas Lalevée <ni...@hibnet.org>.
> Le 11 sept. 2017 à 17:05, Jaikiran Pai <ja...@gmail.com> a écrit :
>
> 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.
I don’t want to rush it either, but it was IVY-1485 which reanimated the community. I would be disappointed it a fix is not included for that bug.
We can be several to look at it. Don’t hesitate to show some work in progress or ask for help.
Nicolas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Ivy upcoming release - where we stand
Posted by Gintautas Grigelionis <g....@gmail.com>.
2017-09-24 15:03 GMT+02:00 Nicolas Lalevée <ni...@hibnet.org>:
>
> > Le 11 sept. 2017 à 21:45, Gintautas Grigelionis <g....@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 <ja...@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-unsubscribe@ant.apache.org
> >> For additional commands, e-mail: dev-help@ant.apache.org
> >>
> >>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>
>
Re: Ivy upcoming release - where we stand
Posted by Nicolas Lalevée <ni...@hibnet.org>.
> Le 11 sept. 2017 à 21:45, Gintautas Grigelionis <g....@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.
> 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.
> 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 ?
Nicolas
>
> Gintas
>
> [1] https://docs.oracle.com/javase/tutorial/java/generics/restrictions.html
>
> 2017-09-11 17:05 GMT+02:00 Jaikiran Pai <ja...@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-unsubscribe@ant.apache.org
>> For additional commands, e-mail: dev-help@ant.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Ivy upcoming release - where we stand
Posted by Nicolas Lalevée <ni...@hibnet.org>.
> Le 19 sept. 2017 à 06:37, Gintautas Grigelionis <g....@gmail.com> a écrit :
>
> I would like to propose upgrading BouncyCastle to at least 1.57 [1] to
> include all security and PGP/GPG related fixes.
+1
Nicolas
>
> Gintas
>
> [1] https://www.bouncycastle.org/releasenotes.html
>
> 2017-09-11 21:45 GMT+02:00 Gintautas Grigelionis <g....@gmail.com>:
>
>> I'd like to have https://issues.apache.org/jira/browse/IVY-1420 included
>> in the upcoming release.
>>
>> 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.
>>
>> 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.
>>
>> Gintas
>>
>> [1] https://docs.oracle.com/javase/tutorial/java/generics/
>> restrictions.html
>>
>> 2017-09-11 17:05 GMT+02:00 Jaikiran Pai <ja...@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-unsubscribe@ant.apache.org
>>> For additional commands, e-mail: dev-help@ant.apache.org
>>>
>>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Ivy upcoming release - where we stand
Posted by Gintautas Grigelionis <g....@gmail.com>.
Continuing software archaeology: confmappingoverride is in both
dependencies and configurations in ivy.xsd on 1.4.x branch.
Gintas
2017-09-24 7:11 GMT+02:00 Gintautas Grigelionis <g....@gmail.com>:
> I carry on talking to myself:-) according to ivy.xsd, all three attributes
> can be used on both dependencies and configurations. So, it's the
> documentation that must be adjusted accordingly... any opinions whether
> that deserves a separate Jira issue?
>
> Gintas
>
> 2017-09-23 17:10 GMT+02:00 Gintautas Grigelionis <g....@gmail.com>
> :
>
>> Re IVY-1420/IVY-1437: there's yet another bug related to duplicated
>> defaultconf/defaultconfmapping attributes.
>>
>> The specification says that confmappingoverride belongs to
>> configurations. The way XmlModuleDescriptorUpdater looks -- check out
>> startDependencies method -- it is set in dependencies element.
>>
>> So, what is the best solution: warn that attribute will be ignored or
>> allow the same attributes for dependencies and configurations?
>>
>> Gintas
>>
>> 2017-09-19 7:54 GMT+02:00 Gintautas Grigelionis <g....@gmail.com>
>> :
>>
>>> I believe the reason of having the same attributes in different sections
>>> of Ivy files is being able to inherit them selectively; thus they must be
>>> remain in the same section where they were set originally.
>>>
>>> Gintas
>>>
>>> 2017-09-19 7:42 GMT+02:00 Gintautas Grigelionis <g.grigelionis@gmail.com
>>> >:
>>>
>>>> Looking at IVY-1420/IVY-1437 it appears that defaultconf and
>>>> defaultconfmapping attributes were first used with dependencies and were
>>>> duplicated in configurations afterwards; would it be sufficient to put them
>>>> only on dependencies (that's how current code works)? I would be very
>>>> grateful for any useful pointers regarding the design of these features.
>>>>
>>>> Gintas
>>>>
>>>>
>>>
>>
>
Re: Ivy upcoming release - where we stand
Posted by Gintautas Grigelionis <g....@gmail.com>.
I carry on talking to myself:-) according to ivy.xsd, all three attributes
can be used on both dependencies and configurations. So, it's the
documentation that must be adjusted accordingly... any opinions whether
that deserves a separate Jira issue?
Gintas
2017-09-23 17:10 GMT+02:00 Gintautas Grigelionis <g....@gmail.com>:
> Re IVY-1420/IVY-1437: there's yet another bug related to duplicated
> defaultconf/defaultconfmapping attributes.
>
> The specification says that confmappingoverride belongs to configurations.
> The way XmlModuleDescriptorUpdater looks -- check out startDependencies
> method -- it is set in dependencies element.
>
> So, what is the best solution: warn that attribute will be ignored or
> allow the same attributes for dependencies and configurations?
>
> Gintas
>
> 2017-09-19 7:54 GMT+02:00 Gintautas Grigelionis <g....@gmail.com>:
>
>> I believe the reason of having the same attributes in different sections
>> of Ivy files is being able to inherit them selectively; thus they must be
>> remain in the same section where they were set originally.
>>
>> Gintas
>>
>> 2017-09-19 7:42 GMT+02:00 Gintautas Grigelionis <g....@gmail.com>
>> :
>>
>>> Looking at IVY-1420/IVY-1437 it appears that defaultconf and
>>> defaultconfmapping attributes were first used with dependencies and were
>>> duplicated in configurations afterwards; would it be sufficient to put them
>>> only on dependencies (that's how current code works)? I would be very
>>> grateful for any useful pointers regarding the design of these features.
>>>
>>> Gintas
>>>
>>>
>>
>
Re: Ivy upcoming release - where we stand
Posted by Gintautas Grigelionis <g....@gmail.com>.
Re IVY-1420/IVY-1437: there's yet another bug related to duplicated
defaultconf/defaultconfmapping attributes.
The specification says that confmappingoverride belongs to configurations.
The way XmlModuleDescriptorUpdater looks -- check out startDependencies
method -- it is set in dependencies element.
So, what is the best solution: warn that attribute will be ignored or allow
the same attributes for dependencies and configurations?
Gintas
2017-09-19 7:54 GMT+02:00 Gintautas Grigelionis <g....@gmail.com>:
> I believe the reason of having the same attributes in different sections
> of Ivy files is being able to inherit them selectively; thus they must be
> remain in the same section where they were set originally.
>
> Gintas
>
> 2017-09-19 7:42 GMT+02:00 Gintautas Grigelionis <g....@gmail.com>:
>
>> Looking at IVY-1420/IVY-1437 it appears that defaultconf and
>> defaultconfmapping attributes were first used with dependencies and were
>> duplicated in configurations afterwards; would it be sufficient to put them
>> only on dependencies (that's how current code works)? I would be very
>> grateful for any useful pointers regarding the design of these features.
>>
>> Gintas
>>
>>
>
Re: Ivy upcoming release - where we stand
Posted by Gintautas Grigelionis <g....@gmail.com>.
I believe the reason of having the same attributes in different sections of
Ivy files is being able to inherit them selectively; thus they must be
remain in the same section where they were set originally.
Gintas
2017-09-19 7:42 GMT+02:00 Gintautas Grigelionis <g....@gmail.com>:
> Looking at IVY-1420/IVY-1437 it appears that defaultconf and
> defaultconfmapping attributes were first used with dependencies and were
> duplicated in configurations afterwards; would it be sufficient to put them
> only on dependencies (that's how current code works)? I would be very
> grateful for any useful pointers regarding the design of these features.
>
> Gintas
>
>
Re: Ivy upcoming release - where we stand
Posted by Gintautas Grigelionis <g....@gmail.com>.
Looking at IVY-1420/IVY-1437 it appears that defaultconf and
defaultconfmapping attributes were first used with dependencies and were
duplicated in configurations afterwards; would it be sufficient to put them
only on dependencies (that's how current code works)? I would be very
grateful for any useful pointers regarding the design of these features.
Gintas
Re: Ivy upcoming release - where we stand
Posted by Gintautas Grigelionis <g....@gmail.com>.
I'd rather deprecate as much as possible for 2.5.0, so that deprecated
stuff could be removed in 3.0 :-)
Gintas
2017-09-25 14:51 GMT+02:00 Jan Matèrne (jhm) <ap...@materne.de>:
> > I'm closing in on IVY-1420; it's Willem's patch + writeInheritedItems
> > for entire inherited configurations/dependencies blocks (and another
> > test case for that).
>
> good.
>
>
> > PR-57 breaks BC but mitigates that except for a special case. Anyway,
> > why must every release be a drop-in replacement for the previous one?
>
> It does not have to.
> With a drop-in replacement it is easier to update for the users. ;-)
> And with the upcoming 2.5.0 I would it make as easy as possible, because
> it is the first release after a long time.
>
> We could discuss major or BC-breaking changes after that. Maybe call the
> next release 3.x ...
>
>
> Jan
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>
>
AW: Ivy upcoming release - where we stand
Posted by "Jan Matèrne (jhm)" <ap...@materne.de>.
> I'm closing in on IVY-1420; it's Willem's patch + writeInheritedItems
> for entire inherited configurations/dependencies blocks (and another
> test case for that).
good.
> PR-57 breaks BC but mitigates that except for a special case. Anyway,
> why must every release be a drop-in replacement for the previous one?
It does not have to.
With a drop-in replacement it is easier to update for the users. ;-)
And with the upcoming 2.5.0 I would it make as easy as possible, because it is the first release after a long time.
We could discuss major or BC-breaking changes after that. Maybe call the next release 3.x ...
Jan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Ivy upcoming release - where we stand
Posted by Gintautas Grigelionis <g....@gmail.com>.
Sounds good.
I'm closing in on IVY-1420; it's Willem's patch + writeInheritedItems for
entire inherited configurations/dependencies blocks (and another test case
for that).
PR-57 breaks BC but mitigates that except for a special case. Anyway, why
must every release be a drop-in replacement for the previous one?
Gintas
2017-09-25 13:42 GMT+02:00 Jan Matèrne (jhm) <ap...@materne.de>:
> I recap the todo list before a 2.5.0 release:
>
> - https://issues.apache.org/jira/browse/IVY-1485
> Incorrect revision of dependencies put in to delivered Ivy files
> Status: Jaikiran wanted to focus on that (11.09.2017)
> prio: stopper ("but it was IVY-1485 which reanimated the community")
>
> - https://issues.apache.org/jira/browse/IVY-1420
> defaultconfmapping on <configurations/> element is not written to
> delivered ivy file
> Status: "I need about a week"
> prio: should be included
>
> - SVG-graphics
> Status:
> prio: should be included, as it seems to be nearly finished (for me)
>
> - upgrading BouncyCastle
> Status: done
>
> - IVY-1420/IVY-1437, defaultconf/defaultconfmapping/confmappingoverride
> attributes
> "according to ivy.xsd, all three attributes can be used on both
> dependencies and configurations.
> So, it's the documentation that must be adjusted accordingly"
> Status: open
> prio: maybe delay (and open a Jira ticket)
>
> - https://github.com/apache/ant-ivy/pull/60
> use Unicode glyphs or SVG data URLs instead of bitmaps
> Status: review required
> prio: should be included (as part of the "svg-bulk")
>
> - https://github.com/apache/ant-ivy/pull/57
> fix the last inconsistencies in generics
> Status: This includes a change which breaks BC
> prio: solve that or delay (this PR should not delay the new version in
> my opinion)
>
> - https://github.com/apache/ant-ivy/pull/55
> use the vectorised logo
> Status: nearly finished (missing header)
> prio: include that as is nearly finished
>
>
> Some comments/updates?
>
>
> Jan
>
>
> > -----Ursprüngliche Nachricht-----
> > Von: Jaikiran Pai [mailto:jai.forums2013@gmail.com]
> > Gesendet: Montag, 25. September 2017 07:16
> > An: dev@ant.apache.org
> > Betreff: Re: Ivy upcoming release - where we stand
> >
> > Since the latest released version of that library is 1.58, I think we
> > should use that version, unless there's a specific reason to not use
> > it.
> > A quick compilation of Ivy with this library and checking their docs
> > for JDK compatibility suggested no issues with 1.58.
> >
> > -Jaikiran
> >
> >
> > On 19/09/17 10:07 AM, Gintautas Grigelionis wrote:
> > > I would like to propose upgrading BouncyCastle to at least 1.57 [1]
> > to
> > > include all security and PGP/GPG related fixes.
> > >
> > > Gintas
> > >
> > > [1] https://www.bouncycastle.org/releasenotes.html
> > >
> > > 2017-09-11 21:45 GMT+02:00 Gintautas Grigelionis
> > <g....@gmail.com>:
> > >
> > >> I'd like to have https://issues.apache.org/jira/browse/IVY-1420
> > >> included in the upcoming release.
> > >>
> > >> 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.
> > >>
> > >> 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.
> > >>
> > >> Gintas
> > >>
> > >> [1] https://docs.oracle.com/javase/tutorial/java/generics/
> > >> restrictions.html
> > >>
> > >> 2017-09-11 17:05 GMT+02:00 Jaikiran Pai <ja...@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-unsubscribe@ant.apache.org For
> > >>> additional commands, e-mail: dev-help@ant.apache.org
> > >>>
> > >>>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org For additional
> > commands, e-mail: dev-help@ant.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>
>
AW: Ivy upcoming release - where we stand
Posted by "Jan Matèrne (jhm)" <ap...@materne.de>.
I recap the todo list before a 2.5.0 release:
- https://issues.apache.org/jira/browse/IVY-1485
Incorrect revision of dependencies put in to delivered Ivy files
Status: Jaikiran wanted to focus on that (11.09.2017)
prio: stopper ("but it was IVY-1485 which reanimated the community")
- https://issues.apache.org/jira/browse/IVY-1420
defaultconfmapping on <configurations/> element is not written to delivered ivy file
Status: "I need about a week"
prio: should be included
- SVG-graphics
Status:
prio: should be included, as it seems to be nearly finished (for me)
- upgrading BouncyCastle
Status: done
- IVY-1420/IVY-1437, defaultconf/defaultconfmapping/confmappingoverride attributes
"according to ivy.xsd, all three attributes can be used on both dependencies and configurations.
So, it's the documentation that must be adjusted accordingly"
Status: open
prio: maybe delay (and open a Jira ticket)
- https://github.com/apache/ant-ivy/pull/60
use Unicode glyphs or SVG data URLs instead of bitmaps
Status: review required
prio: should be included (as part of the "svg-bulk")
- https://github.com/apache/ant-ivy/pull/57
fix the last inconsistencies in generics
Status: This includes a change which breaks BC
prio: solve that or delay (this PR should not delay the new version in my opinion)
- https://github.com/apache/ant-ivy/pull/55
use the vectorised logo
Status: nearly finished (missing header)
prio: include that as is nearly finished
Some comments/updates?
Jan
> -----Ursprüngliche Nachricht-----
> Von: Jaikiran Pai [mailto:jai.forums2013@gmail.com]
> Gesendet: Montag, 25. September 2017 07:16
> An: dev@ant.apache.org
> Betreff: Re: Ivy upcoming release - where we stand
>
> Since the latest released version of that library is 1.58, I think we
> should use that version, unless there's a specific reason to not use
> it.
> A quick compilation of Ivy with this library and checking their docs
> for JDK compatibility suggested no issues with 1.58.
>
> -Jaikiran
>
>
> On 19/09/17 10:07 AM, Gintautas Grigelionis wrote:
> > I would like to propose upgrading BouncyCastle to at least 1.57 [1]
> to
> > include all security and PGP/GPG related fixes.
> >
> > Gintas
> >
> > [1] https://www.bouncycastle.org/releasenotes.html
> >
> > 2017-09-11 21:45 GMT+02:00 Gintautas Grigelionis
> <g....@gmail.com>:
> >
> >> I'd like to have https://issues.apache.org/jira/browse/IVY-1420
> >> included in the upcoming release.
> >>
> >> 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.
> >>
> >> 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.
> >>
> >> Gintas
> >>
> >> [1] https://docs.oracle.com/javase/tutorial/java/generics/
> >> restrictions.html
> >>
> >> 2017-09-11 17:05 GMT+02:00 Jaikiran Pai <ja...@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-unsubscribe@ant.apache.org For
> >>> additional commands, e-mail: dev-help@ant.apache.org
> >>>
> >>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org For additional
> commands, e-mail: dev-help@ant.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Ivy upcoming release - where we stand
Posted by Jaikiran Pai <ja...@gmail.com>.
Since the latest released version of that library is 1.58, I think we
should use that version, unless there's a specific reason to not use it.
A quick compilation of Ivy with this library and checking their docs for
JDK compatibility suggested no issues with 1.58.
-Jaikiran
On 19/09/17 10:07 AM, Gintautas Grigelionis wrote:
> I would like to propose upgrading BouncyCastle to at least 1.57 [1] to
> include all security and PGP/GPG related fixes.
>
> Gintas
>
> [1] https://www.bouncycastle.org/releasenotes.html
>
> 2017-09-11 21:45 GMT+02:00 Gintautas Grigelionis <g....@gmail.com>:
>
>> I'd like to have https://issues.apache.org/jira/browse/IVY-1420 included
>> in the upcoming release.
>>
>> 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.
>>
>> 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.
>>
>> Gintas
>>
>> [1] https://docs.oracle.com/javase/tutorial/java/generics/
>> restrictions.html
>>
>> 2017-09-11 17:05 GMT+02:00 Jaikiran Pai <ja...@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-unsubscribe@ant.apache.org
>>> For additional commands, e-mail: dev-help@ant.apache.org
>>>
>>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Ivy upcoming release - where we stand
Posted by Gintautas Grigelionis <g....@gmail.com>.
I would like to propose upgrading BouncyCastle to at least 1.57 [1] to
include all security and PGP/GPG related fixes.
Gintas
[1] https://www.bouncycastle.org/releasenotes.html
2017-09-11 21:45 GMT+02:00 Gintautas Grigelionis <g....@gmail.com>:
> I'd like to have https://issues.apache.org/jira/browse/IVY-1420 included
> in the upcoming release.
>
> 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.
>
> 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.
>
> Gintas
>
> [1] https://docs.oracle.com/javase/tutorial/java/generics/
> restrictions.html
>
> 2017-09-11 17:05 GMT+02:00 Jaikiran Pai <ja...@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-unsubscribe@ant.apache.org
>> For additional commands, e-mail: dev-help@ant.apache.org
>>
>>
>
Re: Ivy upcoming release - where we stand
Posted by Gintautas Grigelionis <g....@gmail.com>.
I'd like to have https://issues.apache.org/jira/browse/IVY-1420 included in
the upcoming release.
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.
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.
Gintas
[1] https://docs.oracle.com/javase/tutorial/java/generics/restrictions.html
2017-09-11 17:05 GMT+02:00 Jaikiran Pai <ja...@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-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>
>