The new module can/may require jdk8. It may even be possible to build the
provider with an older jdk - it depends on what they do in JUnit 8; most of
the lambda stuff can be used from older versions - but if they expose jdk8
types on public api's there's not much alternative. From a practical point
> JUnit 4 End Of Life
>
> I have a strong reason to use Java 8 in Surefire project.
> For more information read this
> https://github.com/junit-team/junit-lambda/issues/31
Hi Tibor,
Wouldn't it be enough to only build the new Junit-5 provider with
source/target level 8 (if that would even be nec
Am 2015-12-14 um 12:52 schrieb Tibor Digana:
JUnit 4 End Of Life
I have a strong reason to use Java 8 in Surefire project.
For more information read this
https://github.com/junit-team/junit-lambda/issues/31
Terrible policy. EoL is announced several months for a proper and
important framework
Am 2015-12-14 um 01:16 schrieb Tibor Digana:
i agree with stephenc that major version change = API change.
the longer we put off updating the baseline JDK *in core* the worse the
pain will be in 2-3 years for us when developing and maintaining our plugins
We can always open a Vote but then so
JUnit 4 End Of Life
I have a strong reason to use Java 8 in Surefire project.
For more information read this
https://github.com/junit-team/junit-lambda/issues/31
Cheers
Tibor
On Mon, Dec 14, 2015 at 1:16 AM, Tibor Digana-2 [via Maven] <
ml-node+s40175n5854925...@n5.nabble.com> wrote:
> i agree
i agree with stephenc that major version change = API change.
>> the longer we put off updating the baseline JDK *in core* the worse the
pain will be in 2-3 years for us when developing and maintaining our plugins
We can always open a Vote but then some users may loose a fix been
important for th
Hi,
Sorry for coming in late to the discussion...
Personally I would prefer to stay on Java 7 for a bit longer. Java 9
looks like its going to be delayed for 6 months:
http://mail.openjdk.java.net/pipermail/jdk9-dev/2015-December/003149.html
As always the opinion of those who work on the code ma
On 2 December 2015 at 09:07, Fred Cooke wrote:
> "You can run maven with Java 8 right now, so it is not a change in any way
> for those users."
>
> This equates to ruling out developers who are forced to use older JDKs/JREs
> if you look at it the other way.
>
Actually you are misusing my argume
2015-12-02 9:38 GMT+01:00 Stephen Connolly
:
> If we look at our JVM company history, IIRC
>
> 2.0 = Java 1.4
> 2.1 = Java 1.4
> 2.2 = Java 1.5
> 3.0 = Java 1.5
> 3.1 = Java 1.6
> 3.2 = Java 1.6
> 3.3 = Java 1.7
>
>
It looks like 3.4 will be 1.7 and 3.5 1.8 :)
Having worked with 1.8 since long b
"You can run maven with Java 8 right now, so it is not a change in any way
for those users."
This equates to ruling out developers who are forced to use older JDKs/JREs
if you look at it the other way.
"I agree that jumping to Java 8 would be unwise. I think we can wait until
4.x. Don’t get me wr
If we look at our JVM company history, IIRC
2.0 = Java 1.4
2.1 = Java 1.4
2.2 = Java 1.5
3.0 = Java 1.5
3.1 = Java 1.6
3.2 = Java 1.6
3.3 = Java 1.7
(I may have the jump versions out as this is from memory on my phone)
So historically we have viewed bumping the minimum Java version as a minor
ch
Java 7 is not EOL: it's not free Oracle updates
if you look at slide 16 of our slides from ApacheCON [1], you'll see that
Oracle has even longer support period for Java versions than IBM: the only
difference is on the free period, that is more limited over time = nowadays
only strict 3 years
T
from source code point of view, you don't need to change anything to compile
with JDK 8, true
But what we showed with Arnaud in our ApacheCON demo (sorry to tell a lot
about it, but that was the topic...), JDK 8 compiler may introduce Java 8 API
references into bytecode from source that don't h
from a communication point of view, this one makes sense
Regards,
Hervé
Le mardi 1 décembre 2015 11:52:14 Mark Derricutt a écrit :
> On 1 Dec 2015, at 11:44, Stephen Connolly wrote:
> > In my view there are some advantages to using the 4.0.x version number as
> > a
> > Java 8 bump... namely that
Java 7 is not EOL: it's not free Oracle updates
if you look at slide 16 of our slides from ApacheCON [1], you'll see that
Oracle has even longer support period for Java versions than IBM: the only
difference is on the free period, that is more limited over time = nowadays
only strict 3 years
T
My 2c:
Our shop has all of the infrastructure on Ubuntu (for better or worse) and
no LTS Ubuntu version exists with Java 8.
So for now we (and anyone else using Ubuntu) are stuck with a few options:
1) stay with 12.04/14.04 and J7
2) backport J8 to 14.04 and/or use a PPA
3) use a non-LTS stable
On 1 Dec 2015, at 20:10, Kristian Rosenvold wrote:
> If we are to stay aligned with current practice, jdk8 should be a
> minor release. As for the actual topic of "should" we switch, i'm
> always in favour of moving forwards. But not in any religious sense.
Minor or patch? i.e 3.3.9 is current,
My take is that if we bump version to 4.x we have to include some more
(major) features other than just a requirement of Java 8 as it doesn't
provide any real benefit for the user, which I'm sure they would expect
from a new major version.
If we would like to align Maven version with pom model ver
I disagree. Changing system requirements in a minor release is kind of
weird so I'd rather say that the current practice is problematic. I
actually don't know the rationale to require Java8 in the codebase but if
we do it please let's label that as a major release.
S.
On Tue, Dec 1, 2015 at 8:10
Technically, JDK8 is entirely undramatic for maven; I'm having a hard
time understanding why it should trigger any api changes or any other
"4.0" reasons.
I cannot make heads or tails of the supposed versioning policy, the
language is too convoluted for me or I'm just not smart enough.
If we are
+1 for Java 8 and the version bump to 4.x,.communicates the change more
clearly.
Regards
Mirko
--
Sent from my mobile
On Nov 30, 2015 23:44, "Stephen Connolly"
wrote:
> I have no issues if we want to call the next version 4.0.x rather than
> 3.4.x
>
> In my view there are some advantages to usi
Java 8 is fine by me, no matter what you label the next version, might as
well label is "4".
Gary
On Mon, Nov 30, 2015 at 1:18 PM, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:
> Picking up from
>
> http://mail-archives.apache.org/mod_mbox/maven-dev/201511.mbox/%3CCA%2BnPnMyjogmqRwe
I'd like to see Java 8 in maven core too. I don't particularly care if
it will be 3.4.x or 4.0.x.
--
Regards,
Igor
On Mon, Nov 30, 2015, at 05:52 PM, Mark Derricutt wrote:
> On 1 Dec 2015, at 11:44, Stephen Connolly wrote:
>
> > In my view there are some advantages to using the 4.0.x version nu
On 1 Dec 2015, at 11:44, Stephen Connolly wrote:
> In my view there are some advantages to using the 4.0.x version number as a
> Java 8 bump... namely that leaves the modelVersion 5.0 changes to Maven 5.0
Why that sounds like a cunning plan coming together!
+1
--
Mark Derricutt
http://ww
I have no issues if we want to call the next version 4.0.x rather than 3.4.x
In my view there are some advantages to using the 4.0.x version number as a
Java 8 bump... namely that leaves the modelVersion 5.0 changes to Maven 5.0
And let's face it, it will just be less confusing to users to say "T
Switching to java 1.8 ==> +1 from my side
But please use a major version increase, to clearly communicate that change.
Besides the already mentioned arguments from the core developers, are their
any numbers on the user base available?
I mean:
select 'java.version' from 'maven_users', where day(las
I agree that jumping to Java 8 would be unwise. I think we can wait until 4.x.
Don’t get me wrong, I’d prefer to use Java 8 and I do for almost everything
else but I don’t think there’s any dire rush.
> On Nov 30, 2015, at 2:00 PM, Michael Osipov wrote:
>
> Am 2015-11-30 um 22:18 schrieb Steph
As I spoke with Andreas and Kristian about my ideas now I am going to
forward this email to Maven mailinglist.
I can see the opportunity of Java 8 but I don't say that all artifacts must
be necessarily compiled with Java8. I can imaging few of them which make
sense.
This is the email and you can te
Am 2015-11-30 um 22:18 schrieb Stephen Connolly:
Picking up from
http://mail-archives.apache.org/mod_mbox/maven-dev/201511.mbox/%3CCA%2BnPnMyjogmqRweYbxLuULLB9ve2P6MPcQuH%2BPkxcNn-oN4GPg%40mail.gmail.com%3E
(and my follow up to that but archive.apache.org is being a tad slow)
Here is our policy:
Great, it's that time of year again :-).
I'm all for bumping the Java version, although I have no apparent need for
it. But Java 8 opens so many doors, as Stephen listed... And who knows how
long we'll live with 3.4.x.
In the end, usually users who are stuck with an old JDK for their code
either
Picking up from
http://mail-archives.apache.org/mod_mbox/maven-dev/201511.mbox/%3CCA%2BnPnMyjogmqRweYbxLuULLB9ve2P6MPcQuH%2BPkxcNn-oN4GPg%40mail.gmail.com%3E
(and my follow up to that but archive.apache.org is being a tad slow)
Here is our policy:
The development line of Maven core should require
31 matches
Mail list logo
