Ivy upcoming release - where we stand

classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|

Ivy upcoming release - where we stand

Jaikiran Pai
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Ivy upcoming release - where we stand

Gintautas Grigelionis
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 <[hidden email]>:

> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Ivy upcoming release - where we stand

Gintautas Grigelionis
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 <[hidden email]>:

> 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 <[hidden email]>:
>
>> 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: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
Reply | Threaded
Open this post in threaded view
|

Re: Ivy upcoming release - where we stand

Gintautas Grigelionis
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
Reply | Threaded
Open this post in threaded view
|

Re: Ivy upcoming release - where we stand

Gintautas Grigelionis
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 <[hidden email]>:

> 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
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Ivy upcoming release - where we stand

Gintautas Grigelionis
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 <[hidden email]>:

> 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 <[hidden email]>:
>
>> 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
>>
>>
>
Reply | Threaded
Open this post in threaded view
|

Re: Ivy upcoming release - where we stand

Gintautas Grigelionis
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 <[hidden email]>:

> 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 <[hidden email]>:
>
>> 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 <[hidden email]>
>> :
>>
>>> 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
>>>
>>>
>>
>
Reply | Threaded
Open this post in threaded view
|

Re: Ivy upcoming release - where we stand

Gintautas Grigelionis
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 <[hidden email]>:

> 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 <[hidden email]>
> :
>
>> 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 <[hidden email]>
>> :
>>
>>> 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 <[hidden email]
>>> >:
>>>
>>>> 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
>>>>
>>>>
>>>
>>
>
Reply | Threaded
Open this post in threaded view
|

Re: Ivy upcoming release - where we stand

Nicolas Lalevée
In reply to this post by Jaikiran Pai

> Le 11 sept. 2017 à 17:05, Jaikiran Pai <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Ivy upcoming release - where we stand

Nicolas Lalevée
In reply to this post by Gintautas Grigelionis

> Le 11 sept. 2017 à 21:45, Gintautas Grigelionis <[hidden email]> 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 <[hidden email]>:
>
>> 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: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Ivy upcoming release - where we stand

Nicolas Lalevée
In reply to this post by Gintautas Grigelionis

> Le 19 sept. 2017 à 06:37, Gintautas Grigelionis <[hidden email]> 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 <[hidden email]>:
>
>> 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 <[hidden email]>:
>>
>>> 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: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>>
>>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Ivy upcoming release - where we stand

Gintautas Grigelionis
In reply to this post by Nicolas Lalevée
2017-09-24 15:03 GMT+02:00 Nicolas Lalevée <[hidden email]>:

>
> > Le 11 sept. 2017 à 21:45, Gintautas Grigelionis <[hidden email]>
> 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 <[hidden email]>:
> >
> >> 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: [hidden email]
> >> For additional commands, e-mail: [hidden email]
> >>
> >>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Ivy upcoming release - where we stand

Jaikiran Pai
In reply to this post by Gintautas Grigelionis
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 <[hidden email]>:
>
>> 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 <[hidden email]>:
>>
>>> 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: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

AW: Ivy upcoming release - where we stand

Jan Matèrne (jhm)
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:[hidden email]]
> Gesendet: Montag, 25. September 2017 07:16
> An: [hidden email]
> 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
> <[hidden email]>:
> >
> >> 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 <[hidden email]>:
> >>
> >>> 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: [hidden email] For
> >>> additional commands, e-mail: [hidden email]
> >>>
> >>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email] For additional
> commands, e-mail: [hidden email]



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Ivy upcoming release - where we stand

Gintautas Grigelionis
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) <[hidden email]>:

> 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:[hidden email]]
> > Gesendet: Montag, 25. September 2017 07:16
> > An: [hidden email]
> > 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
> > <[hidden email]>:
> > >
> > >> 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 <[hidden email]>:
> > >>
> > >>> 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: [hidden email] For
> > >>> additional commands, e-mail: [hidden email]
> > >>>
> > >>>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email] For additional
> > commands, e-mail: [hidden email]
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

AW: Ivy upcoming release - where we stand

Jan Matèrne (jhm)
> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Ivy upcoming release - where we stand

Gintautas Grigelionis
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) <[hidden email]>:

> > 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>