Re: Would Commons Lang on Java 8 be a problem for the Apache Maven project?

Commons lang could commit to providing patch releases/bug fixes in a maintenance series of the existing line for that purpose. Then it'd be totally fine to do whatever they liked in the new version with major incremented. On Mon, Sep 26, 2016 at 3:20 AM, Robert Scholte

Re: Would Commons Lang on Java 8 be a problem for the Apache Maven project?

On Sun, 25 Sep 2016 16:11:22 +0200, Benedikt Ritter wrote: Hello Robert, just watched your JavaOne presentation. Very interesting :-) thanks! Robert Scholte schrieb am So., 25. Sep. 2016 um 13:48 Uhr: It depends. If you are changing existing

Re: Would Commons Lang on Java 8 be a problem for the Apache Maven project?

Hello Robert, just watched your JavaOne presentation. Very interesting :-) Robert Scholte schrieb am So., 25. Sep. 2016 um 13:48 Uhr: > It depends. If you are changing existing methods to only work with Java8, > that would be a problem (read: we cannot upgrade). If you

Re: Would Commons Lang on Java 8 be a problem for the Apache Maven project?

Hello Tibor, Tibor Digana schrieb am So., 25. Sep. 2016 um 10:27 Uhr: > What a new API is needed from commons-lang:3.7 in Maven? > Do we need to have something from the latest commons-lang and latest JDK ? > Benedikt, can you provide us with API changes on the web so

Re: ComparableVersionTest

So let's think how this would work in a project dependency tree world... For each node in the tree we would need to provide: 1. Any coordinates of artifacts that are provided by this artifact (or a compatible implementation is provided)... in most cases this will be empty, but still 2. Any

Re: ComparableVersionTest

Le dimanche 25 septembre 2016 13:21:27 Karl Heinz Marbaise a écrit : > If you start thinking about version comparison in detail (I have > started with this a little bit ;-( ) it will become really a > nightmare...and really hard... > > What happens with artifacts in your repository manager if

Re: ComparableVersionTest

>>I think we could make a kind of an interface to delegate the real comparison to an user implemented thing (via extensions)We could make the api and use the current implementation as a default ? This was my thought as well. It can be really a nightmare, as I understood as well, which is

Re: Early Access build 136 for JDK 9 & JDK 9 with Project Jigsaw are available on java.net

Hi Rory, I've just tested my multirelease demo project and can confirm that 8165723 is fixed in 9-ea+136-jigsaw. thanks, Robert On Tue, 20 Sep 2016 12:02:26 +0200, Rory O'Donnell wrote: Hi Robert & Kristian, Early Access b136 for JDK 9 is available on

Re: Would Commons Lang on Java 8 be a problem for the Apache Maven project?

It depends. If you are changing existing methods to only work with Java8, that would be a problem (read: we cannot upgrade). If you have both Java8 and pre-Java8 implementations, either by reflection or proper encapsulated code it'll work for us. We do it ourselves too[1] for us it would

Re: ComparableVersionTest

Hi Hervé, Hi Tibor, On 25/09/16 12:05, Hervé BOUTEMY wrote: yes, letting people implement their own version comparison algorithm is a dream I have for a long time: this would avoid immediate complaints, or change our answer to complaints This is a point... but I fear this will be complex

Re: ComparableVersionTest

Hi Hervé, On 25/09/16 11:54, Hervé BOUTEMY wrote: +1 don't hesitate to apply the change I don't know why I didn't make it when I did the test: I was looking for some too complex generics instead of simply using the effective type... I have the same situations myself ...I'm in the

Re: ComparableVersionTest

yes, letting people implement their own version comparison algorithm is a dream I have for a long time: this would avoid immediate complaints, or change our answer to complaints but I fear this will be complex to document (and honestly, this would require per-artifact configuration, since the

Re: ComparableVersionTest

+1 don't hesitate to apply the change I don't know why I didn't make it when I did the test: I was looking for some too complex generics instead of simply using the effective type... thank you for this improvement, multiple eyes is really a good feature :) Regards, Hervé Le samedi 24

Re: ComparableVersionTest

As for instance comparing 6.1 > 6.1H. A good example would be 1.2.3 > 1.2.3-RC1 but Maven may receive a new Jira request where 6.1H breaks something else, and therefore never ending story to change comparator. That now you have to always change implementation by users requests in Jira. I know that

Re: ComparableVersionTest

Hi Tibor, maybe you misunderstand my request...I would like to have review on the code in comparison to the original ComparableVersionTest which uses Comparator as return type which produces warnings in IDE about raw types which I tried to fix...and now I would like to have someone taken a

Re: ComparableVersionTest

If it just works, ok. But I am thinking of different topic related to Versions. Since Versions have been discussed in Jira even before I am thinking if it is more suitable to let the users write some script as versions-comparator.bsh in Bean Shell in folder ".mvn". On Sat, Sep 24, 2016 at 7:13

Re: Would Commons Lang on Java 8 be a problem for the Apache Maven project?

What a new API is needed from commons-lang:3.7 in Maven? Do we need to have something from the latest commons-lang and latest JDK ? Benedikt, can you provide us with API changes on the web so that we would better understand. I understand that commons might be needed in the integration test classes

Would Commons Lang on Java 8 be a problem for the Apache Maven project?

Hi, at the Apache Commons Project we're currently discussing where we can host utility classes for working with the features introduced in Java 8. One proposal add this to Commons Lang [1]. Since Apache Maven makes use of Commons Lang, I would like to know whether it would be a problem for you if