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
wrote:
> On Sun, 25 Sep 20
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 methods to only work with
Java8,
that wou
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 have both Java8
> and pre
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 that we would
> better under
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 coord
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 you
>>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 worse
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 java.net, summary of
changes
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 be
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 t
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 implementa
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 l
+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 septembr
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
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 loo
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 PM,
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
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
18 matches
Mail list logo