Re: [DISCUSS] Java version requirement for Mavan 3.4.x

[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

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 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 them in old version of Maven @ Java 7.
>
> Maybe another argument to jump to Java 8.
> @all Do you see any Java 8 API which is terribly important?
> hint: immutable objects, date time API, Files
>
>
> On Wed, Dec 2, 2015 at 10:17 AM, Stephen Connolly <
> [hidden email] >
> wrote:
>
> > On 2 December 2015 at 09:07, Fred Cooke <[hidden email]
> > 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 argument. My point there was whether a bump
> to
> > Java 8 should be a bump in major or minor version number.
> >
> > What I am saying is that you can argue that it isn't a major change
> because
> > our API remains compatible and we are just removing JVMs that are no
> longer
> > supported.
> >
> >
> > >
> > > "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."
> > >
> > > As per usual, Jason has it right, IMO.
> > >
> > > Don't forget Maven is a tool, and as with libs, the decision to push
> > > everything above you upward is a dangerous one. As far as tools go in
> J
> > > land, they don't come much more foundational than Maven.
> > >
> >
> > There are two points I would like to make:
> >
> > 1. If you and your team have a need for a Java 6 or 7 version of Maven,
> > please step up and continue to maintain those versions. We are not going
> to
> > drop support in the plugins (where most of the stuff matters) for Java 6
> > any time soon... and if you are in a restricted environment you likely
> > cannot pick up new features easily anyway... CALL TO ACTION: We need
> people
> > prepared to maintain the older release lines
> >
> > 2. Think of the plugins in 2-3 years. Right now, to build a plugin and
> test
> > it against the supported lines I sometimes have to go and set up a VM
> > running an old version of linux and then pull a JDK 1.5 from the archive
> on
> > oracle's download site because the installer doesn't work on newer
> versions
> > of linux and there is no installer on my primary development platform...
> > Similarly I need to do dancing games with older versions of windows...
> Now
> > roll forward 2-3 years... will I be similarly constrained to get a Java
> 7?
> > At least Java 8 is supported until September 2017... we can expect that
> it
> > will be somewhat easy to get a Java 8 for most platforms for at least
> > another 6-12 months before you start to hit the need for running VMs...
> 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
> >
> >
> >
> > >
> > > Regards,
> > >
> > > Fred.
> > >
> > > On Wed, Dec 2, 2015 at 9:38 PM, Stephen Connolly <
> > > [hidden email] >
> wrote:
> > >
> > > > 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
> > > > change. The only strong argument I can see for running with 4.0 is
> to
> > > align
> > > > the modelVersion... On the other hand actually having a maven
> version
> > > > number that matches the modelVersion might cause confusion in
> users...
> > > The
> > > > "oh this is moselVersion 4.0.0 so you need to use at least Maven
> 4"...
> > On
> > > > the one hand, great for adoption and we will want that for
> modelVersion
> > > > 5.0.0... On the other hand it gives a false impression...
> > > >
> > > > So the question really becomes how intrinsic a part of the maven API
> is
> > > the
> > > > baseline Java version.
> > > >
> > > > You can run maven with Java 8 right now, so it is not a change in
> any
> > way
> > > > for those users.
> > > >
> > > > We do have to start to 

Re: [DISCUSS] Java version requirement for Mavan 3.4.x

[Kristian Rosenvold]

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
of view, it's slightly inconvenient to be the only project requiring jdk8
(but someone has to be first, so...)

But initially it should be only the new provider with an upped language
level.

Kristian




2015-12-14 21:41 GMT+01:00 Andreas Gudian :

> > 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 necessary) and switch the
> animal-sniffer to JDK 8 signatures only for that module? Or move that
> provider to its own repository with its own JDK 8 build...
>
> In any case, I don't think we'd have a strict requirement to move all of
> surefire to Java 8 bytecode only because of a new test provider - or a
> dependency thereof. Sure it would be cool to go full Java 8 in Surefire,
> but I don't think we can or should pull that off.
>

Re: [DISCUSS] Java version requirement for Mavan 3.4.x

[Michael Osipov]

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 some users may loose a fix been
important for them in old version of Maven @ Java 7.

Maybe another argument to jump to Java 8.
@all Do you see any Java 8 API which is terribly important?
hint: immutable objects, date time API, Files


Unless someone is going to rewrite code with real benefit, I see need to 
bump just to have Java 8 source code.


Michael


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [DISCUSS] Java version requirement for Mavan 3.4.x

[Michael Osipov]

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 like JUnit. I see no announcement.


Just because JUnit 5 requires 8 doesn't mean that the rest has to.
Many folks will stick with 4.x for a long time.

Michael


On Mon, Dec 14, 2015 at 1:16 AM, Tibor Digana-2 [via Maven] <
ml-node+s40175n5854925...@n5.nabble.com> wrote:


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 them in old version of Maven @ Java 7.

Maybe another argument to jump to Java 8.
@all Do you see any Java 8 API which is terribly important?
hint: immutable objects, date time API, Files


On Wed, Dec 2, 2015 at 10:17 AM, Stephen Connolly <
[hidden email] >
wrote:


On 2 December 2015 at 09:07, Fred Cooke <[hidden email]

> 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 argument. My point there was whether a bump

to

Java 8 should be a bump in major or minor version number.

What I am saying is that you can argue that it isn't a major change

because

our API remains compatible and we are just removing JVMs that are no

longer

supported.




"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."

As per usual, Jason has it right, IMO.

Don't forget Maven is a tool, and as with libs, the decision to push
everything above you upward is a dangerous one. As far as tools go in

J

land, they don't come much more foundational than Maven.



There are two points I would like to make:

1. If you and your team have a need for a Java 6 or 7 version of Maven,
please step up and continue to maintain those versions. We are not going

to

drop support in the plugins (where most of the stuff matters) for Java 6
any time soon... and if you are in a restricted environment you likely
cannot pick up new features easily anyway... CALL TO ACTION: We need

people

prepared to maintain the older release lines

2. Think of the plugins in 2-3 years. Right now, to build a plugin and

test

it against the supported lines I sometimes have to go and set up a VM
running an old version of linux and then pull a JDK 1.5 from the archive

on

oracle's download site because the installer doesn't work on newer

versions

of linux and there is no installer on my primary development platform...
Similarly I need to do dancing games with older versions of windows...

Now

roll forward 2-3 years... will I be similarly constrained to get a Java

7?

At least Java 8 is supported until September 2017... we can expect that

it

will be somewhat easy to get a Java 8 for most platforms for at least
another 6-12 months before you start to hit the need for running VMs...

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





Regards,

Fred.

On Wed, Dec 2, 2015 at 9:38 PM, Stephen Connolly <
[hidden email] >

wrote:



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

change. The only strong argument I can see for running with 4.0 is

to

align

the modelVersion... On the other hand actually having a maven

version

number that matches the modelVersion might cause confusion in

users...

The

"oh this is moselVersion 4.0.0 so you need to use at least Maven

4"...

On

the one hand, great for adoption and we will want that for

modelVersion

5.0.0... On the other hand it gives a false impression...

So the question really becomes how intrinsic a part of the maven API

is

the

baseline Java version.

You can run maven with Java 8 right now, so it is not a change in

any

way

for those users.

We do have to start to recognise the risk of dependencies compiled

with

JDK

8... IOW when releasing bits of Maven we strictly require the

release

manager to use the base Java version. That puts restrictions on what

the

developers can use.

The base version for plugins 

Re: [DISCUSS] Java version requirement for Mavan 3.4.x

[Andreas Gudian]

> 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 necessary) and switch the
animal-sniffer to JDK 8 signatures only for that module? Or move that
provider to its own repository with its own JDK 8 build...

In any case, I don't think we'd have a strict requirement to move all of
surefire to Java 8 bytecode only because of a new test provider - or a
dependency thereof. Sure it would be cool to go full Java 8 in Surefire,
but I don't think we can or should pull that off.

Re: [DISCUSS] Java version requirement for Mavan 3.4.x

[Dennis Lundberg]

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 matters more than
the opinion of us who don't though.


2015-11-30 22:18 GMT+01:00 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:
>
> The development line of Maven core should require a minimum JRE version
>> that is no older than 18 months after the end of Oracle's public updates
>> for that JRE version at the time that the first version of the development
>> line was released, but may require a higher minimum JRE version if other
>> requirements dictate a higher JRE version
>
>
> (Source:
> https://cwiki.apache.org/confluence/display/MAVEN/Version+number+policy)
>
> OK, so it's a draft policy... but we've all been silent on the draft, so
> lazy consensus!
>
> Now in http://www.oracle.com/technetwork/java/javase/eol-135779.html they
> state:
>
> after April 2015, Oracle will not post further updates of Java SE 7 to its
>> public download sites
>
>
> So per our (draft) version number policy, we can keep Java 7 as the
> baseline :-( or we can choose to upgrade code to Java 8 (because we want to
> use lambdas... there's a requirement)
>
>
> So assuming we bump the master branch of Maven core to 3.4.0, what Java
> version do we want to use as the baseline?
>
> There are thankfully only two options:
>
> Java 7
>   + Not actually changing things
>   + May make it easier to drive adoption
>   - Still can't use newer language features in core
>   - Java 7 is EOL and it may get harder for developers to source JDKs to
> test and develop against
>
> Java 8
>   + We're not as old hat any more
>   + We can use lambdas
>   + We can use Nashorn (may make integrating with Node easier... certainly
> could make integrating with JavaScript tooling easier)
>   + EOL for Java 8 is at least Sep 2017 (and may be later)
>   - May be harder to drive adoption in shops that have issues upgrading
> Java (but toolchains and they likely wouldn't upgrade to 3.4.x anyway
> unless there are features dragging their change controlled heels over the
> line)
>
> So...
>
> Let's have a heated debate!
>
> -Stephen
>
> P.S.
>
>   I'm waiting for Chris to chime in about how IBM is still supporting Java
> 1.3 or something like that ;-)



-- 
Dennis Lundberg

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [DISCUSS] Java version requirement for Mavan 3.4.x

[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 some users may loose a fix been
important for them in old version of Maven @ Java 7.

Maybe another argument to jump to Java 8.
@all Do you see any Java 8 API which is terribly important?
hint: immutable objects, date time API, Files


On Wed, Dec 2, 2015 at 10:17 AM, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

> 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 argument. My point there was whether a bump to
> Java 8 should be a bump in major or minor version number.
>
> What I am saying is that you can argue that it isn't a major change because
> our API remains compatible and we are just removing JVMs that are no longer
> supported.
>
>
> >
> > "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."
> >
> > As per usual, Jason has it right, IMO.
> >
> > Don't forget Maven is a tool, and as with libs, the decision to push
> > everything above you upward is a dangerous one. As far as tools go in J
> > land, they don't come much more foundational than Maven.
> >
>
> There are two points I would like to make:
>
> 1. If you and your team have a need for a Java 6 or 7 version of Maven,
> please step up and continue to maintain those versions. We are not going to
> drop support in the plugins (where most of the stuff matters) for Java 6
> any time soon... and if you are in a restricted environment you likely
> cannot pick up new features easily anyway... CALL TO ACTION: We need people
> prepared to maintain the older release lines
>
> 2. Think of the plugins in 2-3 years. Right now, to build a plugin and test
> it against the supported lines I sometimes have to go and set up a VM
> running an old version of linux and then pull a JDK 1.5 from the archive on
> oracle's download site because the installer doesn't work on newer versions
> of linux and there is no installer on my primary development platform...
> Similarly I need to do dancing games with older versions of windows... Now
> roll forward 2-3 years... will I be similarly constrained to get a Java 7?
> At least Java 8 is supported until September 2017... we can expect that it
> will be somewhat easy to get a Java 8 for most platforms for at least
> another 6-12 months before you start to hit the need for running VMs... 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
>
>
>
> >
> > Regards,
> >
> > Fred.
> >
> > On Wed, Dec 2, 2015 at 9:38 PM, Stephen Connolly <
> > stephen.alan.conno...@gmail.com> wrote:
> >
> > > 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
> > > change. The only strong argument I can see for running with 4.0 is to
> > align
> > > the modelVersion... On the other hand actually having a maven version
> > > number that matches the modelVersion might cause confusion in users...
> > The
> > > "oh this is moselVersion 4.0.0 so you need to use at least Maven 4"...
> On
> > > the one hand, great for adoption and we will want that for modelVersion
> > > 5.0.0... On the other hand it gives a false impression...
> > >
> > > So the question really becomes how intrinsic a part of the maven API is
> > the
> > > baseline Java version.
> > >
> > > You can run maven with Java 8 right now, so it is not a change in any
> way
> > > for those users.
> > >
> > > We do have to start to recognise the risk of dependencies compiled with
> > JDK
> > > 8... IOW when releasing bits of Maven we strictly require the release
> > > manager to use the base Java version. That puts restrictions on what
> the
> > > developers can use.
> > >
> > > The base version for plugins will always lag behind the base version
> for
> > > core. So, for example, plugins are only now getting up to Java 1.6 as a
> > > baseline... But it is getting harder for me to get a Java 6 to compile
> > > with... I know for building the animal sniffer signatures I couldn't
> get
> > > JDKs that could be installed on my primary OS at the time (Linux) down
> > > below 1.4... With some 

Re: [DISCUSS] Java version requirement for Mavan 3.4.x

[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

(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
change. The only strong argument I can see for running with 4.0 is to align
the modelVersion... On the other hand actually having a maven version
number that matches the modelVersion might cause confusion in users... The
"oh this is moselVersion 4.0.0 so you need to use at least Maven 4"... On
the one hand, great for adoption and we will want that for modelVersion
5.0.0... On the other hand it gives a false impression...

So the question really becomes how intrinsic a part of the maven API is the
baseline Java version.

You can run maven with Java 8 right now, so it is not a change in any way
for those users.

We do have to start to recognise the risk of dependencies compiled with JDK
8... IOW when releasing bits of Maven we strictly require the release
manager to use the base Java version. That puts restrictions on what the
developers can use.

The base version for plugins will always lag behind the base version for
core. So, for example, plugins are only now getting up to Java 1.6 as a
baseline... But it is getting harder for me to get a Java 6 to compile
with... I know for building the animal sniffer signatures I couldn't get
JDKs that could be installed on my primary OS at the time (Linux) down
below 1.4... With some VMs I was able to get down to 1.3 for some JVMs and
one set of 1.2 signatures. I can't get a Java 1.5 for my Mac... The 1.6 is
getting hard we to install... So 1.7 is an effective baseline unless I
develop in a VM... What will the story be in 2-3 years? The choice we make
now affects that future.

JDK 9 or 10 will drop support for at least -target 1.6 and perhaps -target
1.7 so as I see it we have to start being more aggressive whether that
starts now or in 6 months when JDK 9 comes out is a timing question only
IMHO

On Wednesday 2 December 2015, Hervé BOUTEMY  wrote:

> 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 have any JDK 8 reference
> See bonus demo [1] for a demo :)
>
> This is the first time in JDK history that such a behaviour happens: using
> JDK
> 8 instead of JDK 7 for launching Maven/javac does not give same result
> (unless
> using toolchains, of course).
>
> That's why I currently fear with JDK 8 that people will get some unexpected
> failures. And during the conf, for a few attendees, this demo gave a "now I
> understand what happened to me on one of my builds..." reaction
>
> Regards,
>
> Hervé
>
> [1]
> https://github.com/MavenDemo/java-evolving-en/blob/master/toolchains/bonus.sh
>
> Le mardi 1 décembre 2015 08:10:51 Kristian Rosenvold a écrit :
> > 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 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.
> >
> >
> > Kristian
> >
> > 2015-12-01 6:59 GMT+01:00 Mirko Friedenhagen  >:
> > > +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 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 "To
> > >> build
> > >> a modelVersion 5.0 pom you need Maven 5"
> > >>
> > >> So if there is strong interest in jumping to Java 8 perhaps we just
> bite
> > >> the bullet and jump to Maven 4.0 with Java 8 now and then we can start
> > >> the
> > >> model version 5.0 debate in earnest as we plan the features for Maven
> 5.0
> > >> ;-)
> > >>
> > >> -Stephen
> > >>
> > >> On 30 November 2015 at 22:25, Jason van Zyl  > wrote:
> > >> > 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 

Re: [DISCUSS] Java version requirement for Mavan 3.4.x

[Kristian Rosenvold]

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 before the official release , I'd just
like to point out that 1.8 really does not change much regarding maven
core. it will really only affect a handful of people actually writing code
within maven core. So there is really very little reason to be overly
aggressive in upgrading (unless we think it can attract people to work on
core). I also doubt very much that we'll be adding that many
lambda-specific api's to maven core any time soon. There'll probably be
various function-oriented method popping up in shared code and other libs,
but that's quite some time off.

Stephen's comments about overall tool support for 1.6 is probably the most
important thing here. I suspect the length of our stay on 1.6 minimum for
plugins will be very very short. So I'd say move core to 1.8 and all
plugins to 1.7 in 6 months time.

Kristian

Re: [DISCUSS] Java version requirement for Mavan 3.4.x

[Stephen Connolly]

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 argument. My point there was whether a bump to
Java 8 should be a bump in major or minor version number.

What I am saying is that you can argue that it isn't a major change because
our API remains compatible and we are just removing JVMs that are no longer
supported.


>
> "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."
>
> As per usual, Jason has it right, IMO.
>
> Don't forget Maven is a tool, and as with libs, the decision to push
> everything above you upward is a dangerous one. As far as tools go in J
> land, they don't come much more foundational than Maven.
>

There are two points I would like to make:

1. If you and your team have a need for a Java 6 or 7 version of Maven,
please step up and continue to maintain those versions. We are not going to
drop support in the plugins (where most of the stuff matters) for Java 6
any time soon... and if you are in a restricted environment you likely
cannot pick up new features easily anyway... CALL TO ACTION: We need people
prepared to maintain the older release lines

2. Think of the plugins in 2-3 years. Right now, to build a plugin and test
it against the supported lines I sometimes have to go and set up a VM
running an old version of linux and then pull a JDK 1.5 from the archive on
oracle's download site because the installer doesn't work on newer versions
of linux and there is no installer on my primary development platform...
Similarly I need to do dancing games with older versions of windows... Now
roll forward 2-3 years... will I be similarly constrained to get a Java 7?
At least Java 8 is supported until September 2017... we can expect that it
will be somewhat easy to get a Java 8 for most platforms for at least
another 6-12 months before you start to hit the need for running VMs... 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



>
> Regards,
>
> Fred.
>
> On Wed, Dec 2, 2015 at 9:38 PM, Stephen Connolly <
> stephen.alan.conno...@gmail.com> wrote:
>
> > 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
> > change. The only strong argument I can see for running with 4.0 is to
> align
> > the modelVersion... On the other hand actually having a maven version
> > number that matches the modelVersion might cause confusion in users...
> The
> > "oh this is moselVersion 4.0.0 so you need to use at least Maven 4"... On
> > the one hand, great for adoption and we will want that for modelVersion
> > 5.0.0... On the other hand it gives a false impression...
> >
> > So the question really becomes how intrinsic a part of the maven API is
> the
> > baseline Java version.
> >
> > You can run maven with Java 8 right now, so it is not a change in any way
> > for those users.
> >
> > We do have to start to recognise the risk of dependencies compiled with
> JDK
> > 8... IOW when releasing bits of Maven we strictly require the release
> > manager to use the base Java version. That puts restrictions on what the
> > developers can use.
> >
> > The base version for plugins will always lag behind the base version for
> > core. So, for example, plugins are only now getting up to Java 1.6 as a
> > baseline... But it is getting harder for me to get a Java 6 to compile
> > with... I know for building the animal sniffer signatures I couldn't get
> > JDKs that could be installed on my primary OS at the time (Linux) down
> > below 1.4... With some VMs I was able to get down to 1.3 for some JVMs
> and
> > one set of 1.2 signatures. I can't get a Java 1.5 for my Mac... The 1.6
> is
> > getting hard we to install... So 1.7 is an effective baseline unless I
> > develop in a VM... What will the story be in 2-3 years? The choice we
> make
> > now affects that future.
> >
> > JDK 9 or 10 will drop support for at least -target 1.6 and perhaps
> -target
> > 1.7 so as I see it we have to start being more aggressive whether that
> > starts now or in 6 months when JDK 9 comes out is a timing question only
> > IMHO
> >
> > On Wednesday 2 December 2015, Hervé BOUTEMY 
> wrote:
> >
> > > from source code point of view, you don't need to change anything to
> > > compile
> > > with JDK 8, true
> > >
> > > But what we 

Re: [DISCUSS] Java version requirement for Mavan 3.4.x

[Fred Cooke]

"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 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."

As per usual, Jason has it right, IMO.

Don't forget Maven is a tool, and as with libs, the decision to push
everything above you upward is a dangerous one. As far as tools go in J
land, they don't come much more foundational than Maven.

Regards,

Fred.

On Wed, Dec 2, 2015 at 9:38 PM, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

> 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
> change. The only strong argument I can see for running with 4.0 is to align
> the modelVersion... On the other hand actually having a maven version
> number that matches the modelVersion might cause confusion in users... The
> "oh this is moselVersion 4.0.0 so you need to use at least Maven 4"... On
> the one hand, great for adoption and we will want that for modelVersion
> 5.0.0... On the other hand it gives a false impression...
>
> So the question really becomes how intrinsic a part of the maven API is the
> baseline Java version.
>
> You can run maven with Java 8 right now, so it is not a change in any way
> for those users.
>
> We do have to start to recognise the risk of dependencies compiled with JDK
> 8... IOW when releasing bits of Maven we strictly require the release
> manager to use the base Java version. That puts restrictions on what the
> developers can use.
>
> The base version for plugins will always lag behind the base version for
> core. So, for example, plugins are only now getting up to Java 1.6 as a
> baseline... But it is getting harder for me to get a Java 6 to compile
> with... I know for building the animal sniffer signatures I couldn't get
> JDKs that could be installed on my primary OS at the time (Linux) down
> below 1.4... With some VMs I was able to get down to 1.3 for some JVMs and
> one set of 1.2 signatures. I can't get a Java 1.5 for my Mac... The 1.6 is
> getting hard we to install... So 1.7 is an effective baseline unless I
> develop in a VM... What will the story be in 2-3 years? The choice we make
> now affects that future.
>
> JDK 9 or 10 will drop support for at least -target 1.6 and perhaps -target
> 1.7 so as I see it we have to start being more aggressive whether that
> starts now or in 6 months when JDK 9 comes out is a timing question only
> IMHO
>
> On Wednesday 2 December 2015, Hervé BOUTEMY  wrote:
>
> > 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 have any JDK 8 reference
> > See bonus demo [1] for a demo :)
> >
> > This is the first time in JDK history that such a behaviour happens:
> using
> > JDK
> > 8 instead of JDK 7 for launching Maven/javac does not give same result
> > (unless
> > using toolchains, of course).
> >
> > That's why I currently fear with JDK 8 that people will get some
> unexpected
> > failures. And during the conf, for a few attendees, this demo gave a
> "now I
> > understand what happened to me on one of my builds..." reaction
> >
> > Regards,
> >
> > Hervé
> >
> > [1]
> >
> https://github.com/MavenDemo/java-evolving-en/blob/master/toolchains/bonus.sh
> >
> > Le mardi 1 décembre 2015 08:10:51 Kristian Rosenvold a écrit :
> > > 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 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.
> > >
> > >
> > > Kristian
> > >
> > > 2015-12-01 6:59 GMT+01:00 Mirko Friedenhagen  > >:
> > > > +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"
> > > > >
> > > >
> > > > 

Re: [DISCUSS] Java version requirement for Mavan 3.4.x

[Hervé BOUTEMY]

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 leaves the modelVersion 5.0 changes to Maven
> > 5.0
> 
> Why that sounds like a cunning plan coming together!
> 
> +1


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [DISCUSS] Java version requirement for Mavan 3.4.x

[Hervé BOUTEMY]

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 have any JDK 8 reference
See bonus demo [1] for a demo :)

This is the first time in JDK history that such a behaviour happens: using JDK 
8 instead of JDK 7 for launching Maven/javac does not give same result (unless 
using toolchains, of course).

That's why I currently fear with JDK 8 that people will get some unexpected 
failures. And during the conf, for a few attendees, this demo gave a "now I 
understand what happened to me on one of my builds..." reaction

Regards,

Hervé

[1] 
https://github.com/MavenDemo/java-evolving-en/blob/master/toolchains/bonus.sh

Le mardi 1 décembre 2015 08:10:51 Kristian Rosenvold a écrit :
> 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 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.
> 
> 
> Kristian
> 
> 2015-12-01 6:59 GMT+01:00 Mirko Friedenhagen :
> > +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 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 "To
> >> build
> >> a modelVersion 5.0 pom you need Maven 5"
> >> 
> >> So if there is strong interest in jumping to Java 8 perhaps we just bite
> >> the bullet and jump to Maven 4.0 with Java 8 now and then we can start
> >> the
> >> model version 5.0 debate in earnest as we plan the features for Maven 5.0
> >> ;-)
> >> 
> >> -Stephen
> >> 
> >> On 30 November 2015 at 22:25, Jason van Zyl  wrote:
> >> > 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 Stephen Connolly:
> >> > >> Picking up from
> >> 
> >> http://mail-archives.apache.org/mod_mbox/maven-dev/201511.mbox/%3CCA%2BnP
> >> nMyjogmqRweYbxLuULLB9ve2P6MPcQuH%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 a minimum JRE
> >> 
> >> version
> >> 
> >> > >>> that is no older than 18 months after the end of Oracle's public
> >> > 
> >> > updates
> >> > 
> >> > >>> for that JRE version at the time that the first version of the
> >> > 
> >> > development
> >> > 
> >> > >>> line was released, but may require a higher minimum JRE version if
> >> > 
> >> > other
> >> > 
> >> > >>> requirements dictate a higher JRE version
> >> > >> 
> >> > >> (Source:
> >> https://cwiki.apache.org/confluence/display/MAVEN/Version+number+policy
> >> 
> >> > )
> >> > 
> >> > >> OK, so it's a draft policy... but we've all been silent on the
> >> > >> draft,
> >> 
> >> so
> >> 
> >> > >> lazy consensus!
> >> > >> 
> >> > >> Now in http://www.oracle.com/technetwork/java/javase/eol-135779.html
> >> > 
> >> > they
> >> > 
> >> > >> state:
> >> > >> 
> >> > >> after April 2015, Oracle will not post further updates of Java SE 7
> >> > >> to
> >> > 
> >> > its
> >> > 
> >> > >>> public download sites
> >> > >> 
> >> > >> So per our (draft) version number policy, we can keep Java 7 as the
> >> > >> baseline :-( or we can choose to upgrade code to Java 8 (because we
> >> > 
> >> > want to
> >> > 
> >> > >> use lambdas... there's a requirement)
> >> > >> 
> >> > >> 
> >> > >> So assuming we bump the master branch of Maven core to 3.4.0, what
> >> 
> >> Java
> >> 
> >> > >> version do we want to use as the baseline?
> >> > >> 
> >> > >> There are thankfully only two options:
> >> > >> 
> >> > >> Java 7
> >> > >> 
> >> > >>   + Not actually changing things
> >> > >>   + May make it easier to drive adoption
> >> > >>   - Still can't use newer language features in core
> >> > >>   - Java 7 is 

Re: [DISCUSS] Java version requirement for Mavan 3.4.x

[Hervé BOUTEMY]

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

This was just for more accurate information: the discussion on upgrading or 
not Maven core can continue :)

Regards,

Hervé

Le lundi 30 novembre 2015 21:18:38 Stephen Connolly a écrit :
> Picking up from
> http://mail-archives.apache.org/mod_mbox/maven-dev/201511.mbox/%3CCA%2BnPnMy
> jogmqRweYbxLuULLB9ve2P6MPcQuH%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 a minimum JRE version
> 
> > that is no older than 18 months after the end of Oracle's public updates
> > for that JRE version at the time that the first version of the development
> > line was released, but may require a higher minimum JRE version if other
> > requirements dictate a higher JRE version
> 
> (Source:
> https://cwiki.apache.org/confluence/display/MAVEN/Version+number+policy)
> 
> OK, so it's a draft policy... but we've all been silent on the draft, so
> lazy consensus!
> 
> Now in http://www.oracle.com/technetwork/java/javase/eol-135779.html they
> state:
> 
> after April 2015, Oracle will not post further updates of Java SE 7 to its
> 
> > public download sites
> 
> So per our (draft) version number policy, we can keep Java 7 as the
> baseline :-( or we can choose to upgrade code to Java 8 (because we want to
> use lambdas... there's a requirement)
> 
> 
> So assuming we bump the master branch of Maven core to 3.4.0, what Java
> version do we want to use as the baseline?
> 
> There are thankfully only two options:
> 
> Java 7
>   + Not actually changing things
>   + May make it easier to drive adoption
>   - Still can't use newer language features in core
>   - Java 7 is EOL and it may get harder for developers to source JDKs to
> test and develop against
> 
> Java 8
>   + We're not as old hat any more
>   + We can use lambdas
>   + We can use Nashorn (may make integrating with Node easier... certainly
> could make integrating with JavaScript tooling easier)
>   + EOL for Java 8 is at least Sep 2017 (and may be later)
>   - May be harder to drive adoption in shops that have issues upgrading
> Java (but toolchains and they likely wouldn't upgrade to 3.4.x anyway
> unless there are features dragging their change controlled heels over the
> line)
> 
> So...
> 
> Let's have a heated debate!
> 
> -Stephen
> 
> P.S.
> 
>   I'm waiting for Chris to chime in about how IBM is still supporting Java
> 1.3 or something like that ;-)


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [DISCUSS] Java version requirement for Mavan 3.4.x

[Hervé BOUTEMY]

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

This was just for more accurate information: the discussion on upgrading or 
not Maven core can continue 

Regards,

Hervé

(this time, with the link...)
[1] 
http://events.linuxfoundation.org/sites/events/files/slides/ApacheConEU2015-Maven.pdf

Le lundi 30 novembre 2015 21:18:38 Stephen Connolly a écrit :
> Picking up from
> http://mail-archives.apache.org/mod_mbox/maven-dev/201511.mbox/%3CCA%2BnPnMy
> jogmqRweYbxLuULLB9ve2P6MPcQuH%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 a minimum JRE version
> 
> > that is no older than 18 months after the end of Oracle's public updates
> > for that JRE version at the time that the first version of the development
> > line was released, but may require a higher minimum JRE version if other
> > requirements dictate a higher JRE version
> 
> (Source:
> https://cwiki.apache.org/confluence/display/MAVEN/Version+number+policy)
> 
> OK, so it's a draft policy... but we've all been silent on the draft, so
> lazy consensus!
> 
> Now in http://www.oracle.com/technetwork/java/javase/eol-135779.html they
> state:
> 
> after April 2015, Oracle will not post further updates of Java SE 7 to its
> 
> > public download sites
> 
> So per our (draft) version number policy, we can keep Java 7 as the
> baseline :-( or we can choose to upgrade code to Java 8 (because we want to
> use lambdas... there's a requirement)
> 
> 
> So assuming we bump the master branch of Maven core to 3.4.0, what Java
> version do we want to use as the baseline?
> 
> There are thankfully only two options:
> 
> Java 7
>   + Not actually changing things
>   + May make it easier to drive adoption
>   - Still can't use newer language features in core
>   - Java 7 is EOL and it may get harder for developers to source JDKs to
> test and develop against
> 
> Java 8
>   + We're not as old hat any more
>   + We can use lambdas
>   + We can use Nashorn (may make integrating with Node easier... certainly
> could make integrating with JavaScript tooling easier)
>   + EOL for Java 8 is at least Sep 2017 (and may be later)
>   - May be harder to drive adoption in shops that have issues upgrading
> Java (but toolchains and they likely wouldn't upgrade to 3.4.x anyway
> unless there are features dragging their change controlled heels over the
> line)
> 
> So...
> 
> Let's have a heated debate!
> 
> -Stephen
> 
> P.S.
> 
>   I'm waiting for Chris to chime in about how IBM is still supporting Java
> 1.3 or something like that ;-)


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [DISCUSS] Java version requirement for Mavan 3.4.x

[Anders Hammar]

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 version when we go
model 5, we could just skip Maven 4.x and go directly to Maven 5.x. If
Microsoft has done it, we can do it. :-) (Also, we skip version numbers all
the time now adays with core releases...)

/Anders

On Tue, Dec 1, 2015 at 10:07 AM, Stephane Nicoll 
wrote:

> 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 AM, Kristian Rosenvold <
> kristian.rosenv...@gmail.com> wrote:
>
> > 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 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.
> >
> >
> > Kristian
> >
> > 2015-12-01 6:59 GMT+01:00 Mirko Friedenhagen :
> > > +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" <
> > stephen.alan.conno...@gmail.com>
> > > 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 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 "To
> > build
> > >> a modelVersion 5.0 pom you need Maven 5"
> > >>
> > >> So if there is strong interest in jumping to Java 8 perhaps we just
> bite
> > >> the bullet and jump to Maven 4.0 with Java 8 now and then we can start
> > the
> > >> model version 5.0 debate in earnest as we plan the features for Maven
> > 5.0
> > >> ;-)
> > >>
> > >> -Stephen
> > >>
> > >> On 30 November 2015 at 22:25, Jason van Zyl  wrote:
> > >>
> > >> > 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 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:
> > >> > >>
> > >> > >> The development line of Maven core should require a minimum JRE
> > >> version
> > >> > >>> that is no older than 18 months after the end of Oracle's public
> > >> > updates
> > >> > >>> for that JRE version at the time that the first version of the
> > >> > development
> > >> > >>> line was released, but may require a higher minimum JRE version
> if
> > >> > other
> > >> > >>> requirements dictate a higher JRE version
> > >> > >>
> > >> > >>
> > >> > >> (Source:
> > >> > >>
> > >>
> https://cwiki.apache.org/confluence/display/MAVEN/Version+number+policy
> > >> > )
> > >> > >>
> > >> > >> OK, so it's a draft policy... but we've all been silent on the
> > draft,
> > >> so
> > >> > >> lazy consensus!
> > >> > >>
> > >> > >> Now in
> > http://www.oracle.com/technetwork/java/javase/eol-135779.html
> > >> > they
> > >> > >> state:
> > >> > >>
> > >> > >> after April 2015, Oracle will not post further updates of Java SE
> > 7 to
> > >> > its
> > >> > >>> public download sites
> > >> > >>
> > >> > >>
> > >> > >> So per our (draft) version number policy, we can keep Java 7 as
> the
> > >> > >> baseline :-( or we can choose to upgrade code to Java 8 (because
> we
> > >> > want to
> > >> > >> use lambdas... there's a requirement)
> > >> > >>
> > >> > >>
> > >> > >> So assuming we bump the master branch of Maven core to 3.4.0,
> what
> > >> Java
> > >> > >> version do we want to use as the baseline?
> > >> > >>
> > >> > >> There are thankfully only two options:
> > >> > >>
> > >> > >> Java 7
> > >> > >>   + Not actually changing things
> > >> > >> 

Re: [DISCUSS] Java version requirement for Mavan 3.4.x

[Mark Derricutt]

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, would this be say 3.3.10, or 3.4.1?

Just RUNNING under JDK8 explodes horribly for us on some of our modules ( still 
requiring antlr 3 - which is known to just not run under JDK8 ).

So if a release required changing JDKs and then broke builds - that's 
definitely not a patch release, but I'd also be hesitant over a minor release.

Toolchains are great - IF plugins actually support them, which is what - 4 
maybe 5 plugins in total? Sadly not many plugins fork a separate process to run 
let alone support tool chains.



-- 
Mark Derricutt
http://www.theoryinpractice.net
http://www.chaliceofblood.net
http://plus.google.com/+MarkDerricutt
http://twitter.com/talios
http://facebook.com/mderricutt


signature.asc
Description: OpenPGP digital signature

Re: [DISCUSS] Java version requirement for Mavan 3.4.x

[Stephane Nicoll]

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 AM, Kristian Rosenvold <
kristian.rosenv...@gmail.com> wrote:

> 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 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.
>
>
> Kristian
>
> 2015-12-01 6:59 GMT+01:00 Mirko Friedenhagen :
> > +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" <
> stephen.alan.conno...@gmail.com>
> > 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 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 "To
> build
> >> a modelVersion 5.0 pom you need Maven 5"
> >>
> >> So if there is strong interest in jumping to Java 8 perhaps we just bite
> >> the bullet and jump to Maven 4.0 with Java 8 now and then we can start
> the
> >> model version 5.0 debate in earnest as we plan the features for Maven
> 5.0
> >> ;-)
> >>
> >> -Stephen
> >>
> >> On 30 November 2015 at 22:25, Jason van Zyl  wrote:
> >>
> >> > 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 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:
> >> > >>
> >> > >> The development line of Maven core should require a minimum JRE
> >> version
> >> > >>> that is no older than 18 months after the end of Oracle's public
> >> > updates
> >> > >>> for that JRE version at the time that the first version of the
> >> > development
> >> > >>> line was released, but may require a higher minimum JRE version if
> >> > other
> >> > >>> requirements dictate a higher JRE version
> >> > >>
> >> > >>
> >> > >> (Source:
> >> > >>
> >> https://cwiki.apache.org/confluence/display/MAVEN/Version+number+policy
> >> > )
> >> > >>
> >> > >> OK, so it's a draft policy... but we've all been silent on the
> draft,
> >> so
> >> > >> lazy consensus!
> >> > >>
> >> > >> Now in
> http://www.oracle.com/technetwork/java/javase/eol-135779.html
> >> > they
> >> > >> state:
> >> > >>
> >> > >> after April 2015, Oracle will not post further updates of Java SE
> 7 to
> >> > its
> >> > >>> public download sites
> >> > >>
> >> > >>
> >> > >> So per our (draft) version number policy, we can keep Java 7 as the
> >> > >> baseline :-( or we can choose to upgrade code to Java 8 (because we
> >> > want to
> >> > >> use lambdas... there's a requirement)
> >> > >>
> >> > >>
> >> > >> So assuming we bump the master branch of Maven core to 3.4.0, what
> >> Java
> >> > >> version do we want to use as the baseline?
> >> > >>
> >> > >> There are thankfully only two options:
> >> > >>
> >> > >> Java 7
> >> > >>   + Not actually changing things
> >> > >>   + May make it easier to drive adoption
> >> > >>   - Still can't use newer language features in core
> >> > >>   - Java 7 is EOL and it may get harder for developers to source
> JDKs
> >> to
> >> > >> test and develop against
> >> > >
> >> > > Bumping Java requirements again in minor (!) release is insane. I am
> >> > against that, regardless Oracle has set this EoL or not. Folks at
> Commons
> >> > are doing the right this. Bump requirement with a major not a minor.
> >> > Moreover, we have too many components which have been neglected for
> >> years,
> >> > too many outstanding issues in JIRA. E.g., Doxia, I try to fix some
> once
> >> in
> >> > a while but there a too few of us to take care of the entire Maven
> >> > ecosystem.
> >> > >
> >> > > I would rather see us to bringing the entire system on a decent
> level
> >> > before we make a big 

Re: [DISCUSS] Java version requirement for Mavan 3.4.x

[Fred Cooke]

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 version to get J8

Both 2 and 3 have issues and are a bit of work, so 1 is enduring. You won't
see responsible devs in our office rocking a J8-requiring Maven for a while
at least. That said, I'm OK with the one we're currently using, which is a
3.2 series Maven IIRC, and we're unlikely to require significant new
tooling for anything anyway.

Just a data point.

Regards,

Fred.



On Tue, Dec 1, 2015 at 10:07 PM, Stephane Nicoll 
wrote:

> 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 AM, Kristian Rosenvold <
> kristian.rosenv...@gmail.com> wrote:
>
> > 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 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.
> >
> >
> > Kristian
> >
> > 2015-12-01 6:59 GMT+01:00 Mirko Friedenhagen :
> > > +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" <
> > stephen.alan.conno...@gmail.com>
> > > 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 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 "To
> > build
> > >> a modelVersion 5.0 pom you need Maven 5"
> > >>
> > >> So if there is strong interest in jumping to Java 8 perhaps we just
> bite
> > >> the bullet and jump to Maven 4.0 with Java 8 now and then we can start
> > the
> > >> model version 5.0 debate in earnest as we plan the features for Maven
> > 5.0
> > >> ;-)
> > >>
> > >> -Stephen
> > >>
> > >> On 30 November 2015 at 22:25, Jason van Zyl  wrote:
> > >>
> > >> > 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 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:
> > >> > >>
> > >> > >> The development line of Maven core should require a minimum JRE
> > >> version
> > >> > >>> that is no older than 18 months after the end of Oracle's public
> > >> > updates
> > >> > >>> for that JRE version at the time that the first version of the
> > >> > development
> > >> > >>> line was released, but may require a higher minimum JRE version
> if
> > >> > other
> > >> > >>> requirements dictate a higher JRE version
> > >> > >>
> > >> > >>
> > >> > >> (Source:
> > >> > >>
> > >>
> https://cwiki.apache.org/confluence/display/MAVEN/Version+number+policy
> > >> > )
> > >> > >>
> > >> > >> OK, so it's a draft policy... but we've all been silent on the
> > draft,
> > >> so
> > >> > >> lazy consensus!
> > >> > >>
> > >> > >> Now in
> > http://www.oracle.com/technetwork/java/javase/eol-135779.html
> > >> > they
> > >> > >> state:
> > >> > >>
> > >> > >> after April 2015, Oracle will not post further updates of Java SE
> > 7 to
> > >> > its
> > >> > >>> public download sites
> > >> > >>
> > >> > >>
> > >> > >> So per our (draft) version number policy, we can keep Java 7 as
> the
> > >> > >> baseline :-( or we can choose to upgrade code to Java 8 (because
> we
> > >> > want to
> > >> > >> use lambdas... there's a requirement)
> > >> > >>
> > >> > >>
> > >> > >> So assuming we bump the master branch of Maven core to 3.4.0,
> what
> > >> Java
> > >> > >> version do we want to 

Re: [DISCUSS] Java version requirement for Mavan 3.4.x

[Andreas Gudian]

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 freezed most of their tooling aswell, including their old version of
Hudson or Jenkins, their Maven 3.0.5, and stuff like that... or they use
Toolchains (as they should)

My 2e-2 €


2015-11-30 22:18 GMT+01:00 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:
>
> The development line of Maven core should require a minimum JRE version
> > that is no older than 18 months after the end of Oracle's public updates
> > for that JRE version at the time that the first version of the
> development
> > line was released, but may require a higher minimum JRE version if other
> > requirements dictate a higher JRE version
>
>
> (Source:
> https://cwiki.apache.org/confluence/display/MAVEN/Version+number+policy)
>
> OK, so it's a draft policy... but we've all been silent on the draft, so
> lazy consensus!
>
> Now in http://www.oracle.com/technetwork/java/javase/eol-135779.html they
> state:
>
> after April 2015, Oracle will not post further updates of Java SE 7 to its
> > public download sites
>
>
> So per our (draft) version number policy, we can keep Java 7 as the
> baseline :-( or we can choose to upgrade code to Java 8 (because we want to
> use lambdas... there's a requirement)
>
>
> So assuming we bump the master branch of Maven core to 3.4.0, what Java
> version do we want to use as the baseline?
>
> There are thankfully only two options:
>
> Java 7
>   + Not actually changing things
>   + May make it easier to drive adoption
>   - Still can't use newer language features in core
>   - Java 7 is EOL and it may get harder for developers to source JDKs to
> test and develop against
>
> Java 8
>   + We're not as old hat any more
>   + We can use lambdas
>   + We can use Nashorn (may make integrating with Node easier... certainly
> could make integrating with JavaScript tooling easier)
>   + EOL for Java 8 is at least Sep 2017 (and may be later)
>   - May be harder to drive adoption in shops that have issues upgrading
> Java (but toolchains and they likely wouldn't upgrade to 3.4.x anyway
> unless there are features dragging their change controlled heels over the
> line)
>
> So...
>
> Let's have a heated debate!
>
> -Stephen
>
> P.S.
>
>   I'm waiting for Chris to chime in about how IBM is still supporting Java
> 1.3 or something like that ;-)
>

Re: [DISCUSS] Java version requirement for Mavan 3.4.x

[Michael Osipov]

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:

The development line of Maven core should require a minimum JRE version

that is no older than 18 months after the end of Oracle's public updates
for that JRE version at the time that the first version of the development
line was released, but may require a higher minimum JRE version if other
requirements dictate a higher JRE version



(Source:
https://cwiki.apache.org/confluence/display/MAVEN/Version+number+policy)

OK, so it's a draft policy... but we've all been silent on the draft, so
lazy consensus!

Now in http://www.oracle.com/technetwork/java/javase/eol-135779.html they
state:

after April 2015, Oracle will not post further updates of Java SE 7 to its

public download sites



So per our (draft) version number policy, we can keep Java 7 as the
baseline :-( or we can choose to upgrade code to Java 8 (because we want to
use lambdas... there's a requirement)


So assuming we bump the master branch of Maven core to 3.4.0, what Java
version do we want to use as the baseline?

There are thankfully only two options:

Java 7
   + Not actually changing things
   + May make it easier to drive adoption
   - Still can't use newer language features in core
   - Java 7 is EOL and it may get harder for developers to source JDKs to
test and develop against


Bumping Java requirements again in minor (!) release is insane. I am 
against that, regardless Oracle has set this EoL or not. Folks at 
Commons are doing the right this. Bump requirement with a major not a 
minor. Moreover, we have too many components which have been neglected 
for years, too many outstanding issues in JIRA. E.g., Doxia, I try to 
fix some once in a while but there a too few of us to take care of the 
entire Maven ecosystem.


I would rather see us to bringing the entire system on a decent level 
before we make a big leaps which Java. It does not make sense to be to 
put Maven on the fast lane but let other components suffer at the edge 
of the road.


Michael


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [DISCUSS] Java version requirement for Mavan 3.4.x

[Tibor Digana]

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 tell us what you think of it. Maybe it's
crazy.

After i made a post [1] in JUnit on GitHub I found that it might be useful
in Maven.
Usually JUnit committers are very reserved to new features if you push them
somewhere they don't want to be. :-)

So there are two things how we can utilize Java 8 in Surefire extensions.

The first is simple abstraction of Runners independent of JUnit and TestNG
and easily customized by the user.

Second is the same Runner abstraction used with CLI console.
---
[1] https://github.com/junit-team/junit/issues/1078#issuecomment-158706736

1.
You should see [1]. JUnitTest is an interface and has default methods. The
test(string, function) methods needs to be called in users code. These
methods only register function -> test name.
The function is real test name. Since JUnitTest is interface it can be
implemented in extension. The Surefire Provider will only create a Proxy
around it and around test() methods and simply only report to
SurefireListener.
That's all, simple. All features like parameterized producer, categories,
filters, rules are up to AOP in SPI. Due to Java Proxy the AOP is possible.

2. With Nashorn console embedded in our CLI you can just halt the build in
test phase and run tests and tune them as you like:

>> surefire.run(MyTest.class)
...
>> surefire.exit()

You can just change the test or main code, recompile in IDEA and you do not
need to trigger the buid again because you are still in the JavaScript
console.

So run the TDD round again:

>> surefire.run(MyTest.class)

WDYT ?


Cheers
Tibor



On Mon, Nov 30, 2015 at 10: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%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 a minimum JRE version
> > that is no older than 18 months after the end of Oracle's public updates
> > for that JRE version at the time that the first version of the
> development
> > line was released, but may require a higher minimum JRE version if other
> > requirements dictate a higher JRE version
>
>
> (Source:
> https://cwiki.apache.org/confluence/display/MAVEN/Version+number+policy)
>
> OK, so it's a draft policy... but we've all been silent on the draft, so
> lazy consensus!
>
> Now in http://www.oracle.com/technetwork/java/javase/eol-135779.html they
> state:
>
> after April 2015, Oracle will not post further updates of Java SE 7 to its
> > public download sites
>
>
> So per our (draft) version number policy, we can keep Java 7 as the
> baseline :-( or we can choose to upgrade code to Java 8 (because we want to
> use lambdas... there's a requirement)
>
>
> So assuming we bump the master branch of Maven core to 3.4.0, what Java
> version do we want to use as the baseline?
>
> There are thankfully only two options:
>
> Java 7
>   + Not actually changing things
>   + May make it easier to drive adoption
>   - Still can't use newer language features in core
>   - Java 7 is EOL and it may get harder for developers to source JDKs to
> test and develop against
>
> Java 8
>   + We're not as old hat any more
>   + We can use lambdas
>   + We can use Nashorn (may make integrating with Node easier... certainly
> could make integrating with JavaScript tooling easier)
>   + EOL for Java 8 is at least Sep 2017 (and may be later)
>   - May be harder to drive adoption in shops that have issues upgrading
> Java (but toolchains and they likely wouldn't upgrade to 3.4.x anyway
> unless there are features dragging their change controlled heels over the
> line)
>
> So...
>
> Let's have a heated debate!
>
> -Stephen
>
> P.S.
>
>   I'm waiting for Chris to chime in about how IBM is still supporting Java
> 1.3 or something like that ;-)
>



-- 
Cheers
Tibor

Re: [DISCUSS] Java version requirement for Mavan 3.4.x

[Gary Gregory]

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%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 a minimum JRE version
> > that is no older than 18 months after the end of Oracle's public updates
> > for that JRE version at the time that the first version of the
> development
> > line was released, but may require a higher minimum JRE version if other
> > requirements dictate a higher JRE version
>
>
> (Source:
> https://cwiki.apache.org/confluence/display/MAVEN/Version+number+policy)
>
> OK, so it's a draft policy... but we've all been silent on the draft, so
> lazy consensus!
>
> Now in http://www.oracle.com/technetwork/java/javase/eol-135779.html they
> state:
>
> after April 2015, Oracle will not post further updates of Java SE 7 to its
> > public download sites
>
>
> So per our (draft) version number policy, we can keep Java 7 as the
> baseline :-( or we can choose to upgrade code to Java 8 (because we want to
> use lambdas... there's a requirement)
>
>
> So assuming we bump the master branch of Maven core to 3.4.0, what Java
> version do we want to use as the baseline?
>
> There are thankfully only two options:
>
> Java 7
>   + Not actually changing things
>   + May make it easier to drive adoption
>   - Still can't use newer language features in core
>   - Java 7 is EOL and it may get harder for developers to source JDKs to
> test and develop against
>
> Java 8
>   + We're not as old hat any more
>   + We can use lambdas
>   + We can use Nashorn (may make integrating with Node easier... certainly
> could make integrating with JavaScript tooling easier)
>   + EOL for Java 8 is at least Sep 2017 (and may be later)
>   - May be harder to drive adoption in shops that have issues upgrading
> Java (but toolchains and they likely wouldn't upgrade to 3.4.x anyway
> unless there are features dragging their change controlled heels over the
> line)
>
> So...
>
> Let's have a heated debate!
>
> -Stephen
>
> P.S.
>
>   I'm waiting for Chris to chime in about how IBM is still supporting Java
> 1.3 or something like that ;-)
>



-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition

JUnit in Action, Second Edition 
Spring Batch in Action 
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: [DISCUSS] Java version requirement for Mavan 3.4.x

[Martin W. Kirst]

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(last_usage) > 20150101
Does such exists?
Or maybe the core developers may raise a poll on Twitter, to get some
feedback ;)

What do you think?

Regards
Martin

PS: My background:  I'm Maven user since a handful years now and just did
one pull request #71

2015-11-30 23:19 GMT+01:00 Tibor Digana :

> 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 tell us what you think of it. Maybe it's
> crazy.
>
> After i made a post [1] in JUnit on GitHub I found that it might be useful
> in Maven.
> Usually JUnit committers are very reserved to new features if you push them
> somewhere they don't want to be. :-)
>
> So there are two things how we can utilize Java 8 in Surefire extensions.
>
> The first is simple abstraction of Runners independent of JUnit and TestNG
> and easily customized by the user.
>
> Second is the same Runner abstraction used with CLI console.
> ---
> [1] https://github.com/junit-team/junit/issues/1078#issuecomment-158706736
>
> 1.
> You should see [1]. JUnitTest is an interface and has default methods. The
> test(string, function) methods needs to be called in users code. These
> methods only register function -> test name.
> The function is real test name. Since JUnitTest is interface it can be
> implemented in extension. The Surefire Provider will only create a Proxy
> around it and around test() methods and simply only report to
> SurefireListener.
> That's all, simple. All features like parameterized producer, categories,
> filters, rules are up to AOP in SPI. Due to Java Proxy the AOP is possible.
>
> 2. With Nashorn console embedded in our CLI you can just halt the build in
> test phase and run tests and tune them as you like:
>
> >> surefire.run(MyTest.class)
> ...
> >> surefire.exit()
>
> You can just change the test or main code, recompile in IDEA and you do not
> need to trigger the buid again because you are still in the JavaScript
> console.
>
> So run the TDD round again:
>
> >> surefire.run(MyTest.class)
>
> WDYT ?
>
>
> Cheers
> Tibor
>
>
>
> On Mon, Nov 30, 2015 at 10: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%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 a minimum JRE version
> > > that is no older than 18 months after the end of Oracle's public
> updates
> > > for that JRE version at the time that the first version of the
> > development
> > > line was released, but may require a higher minimum JRE version if
> other
> > > requirements dictate a higher JRE version
> >
> >
> > (Source:
> > https://cwiki.apache.org/confluence/display/MAVEN/Version+number+policy)
> >
> > OK, so it's a draft policy... but we've all been silent on the draft, so
> > lazy consensus!
> >
> > Now in http://www.oracle.com/technetwork/java/javase/eol-135779.html
> they
> > state:
> >
> > after April 2015, Oracle will not post further updates of Java SE 7 to
> its
> > > public download sites
> >
> >
> > So per our (draft) version number policy, we can keep Java 7 as the
> > baseline :-( or we can choose to upgrade code to Java 8 (because we want
> to
> > use lambdas... there's a requirement)
> >
> >
> > So assuming we bump the master branch of Maven core to 3.4.0, what Java
> > version do we want to use as the baseline?
> >
> > There are thankfully only two options:
> >
> > Java 7
> >   + Not actually changing things
> >   + May make it easier to drive adoption
> >   - Still can't use newer language features in core
> >   - Java 7 is EOL and it may get harder for developers to source JDKs to
> > test and develop against
> >
> > Java 8
> >   + We're not as old hat any more
> >   + We can use lambdas
> >   + We can use Nashorn (may make integrating with Node easier...
> certainly
> > could make integrating with JavaScript tooling easier)
> >   + EOL for Java 8 is at least Sep 2017 (and may be later)
> >   - May be harder to drive adoption in shops that have issues upgrading
> > Java (but toolchains and they likely wouldn't upgrade to 3.4.x anyway
> > unless there are features dragging their change controlled heels over the
> > line)
> >
> > So...
> >
> > Let's have a heated debate!
> >
> > -Stephen
> >
> > P.S.
> >
> >   I'm 

Re: [DISCUSS] Java version requirement for Mavan 3.4.x

[Jason van Zyl]

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 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:
>> 
>> The development line of Maven core should require a minimum JRE version
>>> that is no older than 18 months after the end of Oracle's public updates
>>> for that JRE version at the time that the first version of the development
>>> line was released, but may require a higher minimum JRE version if other
>>> requirements dictate a higher JRE version
>> 
>> 
>> (Source:
>> https://cwiki.apache.org/confluence/display/MAVEN/Version+number+policy)
>> 
>> OK, so it's a draft policy... but we've all been silent on the draft, so
>> lazy consensus!
>> 
>> Now in http://www.oracle.com/technetwork/java/javase/eol-135779.html they
>> state:
>> 
>> after April 2015, Oracle will not post further updates of Java SE 7 to its
>>> public download sites
>> 
>> 
>> So per our (draft) version number policy, we can keep Java 7 as the
>> baseline :-( or we can choose to upgrade code to Java 8 (because we want to
>> use lambdas... there's a requirement)
>> 
>> 
>> So assuming we bump the master branch of Maven core to 3.4.0, what Java
>> version do we want to use as the baseline?
>> 
>> There are thankfully only two options:
>> 
>> Java 7
>>   + Not actually changing things
>>   + May make it easier to drive adoption
>>   - Still can't use newer language features in core
>>   - Java 7 is EOL and it may get harder for developers to source JDKs to
>> test and develop against
> 
> Bumping Java requirements again in minor (!) release is insane. I am against 
> that, regardless Oracle has set this EoL or not. Folks at Commons are doing 
> the right this. Bump requirement with a major not a minor. Moreover, we have 
> too many components which have been neglected for years, too many outstanding 
> issues in JIRA. E.g., Doxia, I try to fix some once in a while but there a 
> too few of us to take care of the entire Maven ecosystem.
> 
> I would rather see us to bringing the entire system on a decent level before 
> we make a big leaps which Java. It does not make sense to be to put Maven on 
> the fast lane but let other components suffer at the edge of the road.
> 
> Michael
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
> 

Thanks,

Jason

--
Jason van Zyl
Founder, Takari and Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/takari_io
-

Be not afraid of growing slowly, be only afraid of standing still.

 -- Chinese Proverb













-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [DISCUSS] Java version requirement for Mavan 3.4.x

[Mark Derricutt]

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://www.theoryinpractice.net
http://www.chaliceofblood.net
http://plus.google.com/+MarkDerricutt
http://twitter.com/talios
http://facebook.com/mderricutt


signature.asc
Description: OpenPGP digital signature

Re: [DISCUSS] Java version requirement for Mavan 3.4.x

[Stephen Connolly]

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 "To build
a modelVersion 5.0 pom you need Maven 5"

So if there is strong interest in jumping to Java 8 perhaps we just bite
the bullet and jump to Maven 4.0 with Java 8 now and then we can start the
model version 5.0 debate in earnest as we plan the features for Maven 5.0
;-)

-Stephen

On 30 November 2015 at 22:25, Jason van Zyl  wrote:

> 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 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:
> >>
> >> The development line of Maven core should require a minimum JRE version
> >>> that is no older than 18 months after the end of Oracle's public
> updates
> >>> for that JRE version at the time that the first version of the
> development
> >>> line was released, but may require a higher minimum JRE version if
> other
> >>> requirements dictate a higher JRE version
> >>
> >>
> >> (Source:
> >> https://cwiki.apache.org/confluence/display/MAVEN/Version+number+policy
> )
> >>
> >> OK, so it's a draft policy... but we've all been silent on the draft, so
> >> lazy consensus!
> >>
> >> Now in http://www.oracle.com/technetwork/java/javase/eol-135779.html
> they
> >> state:
> >>
> >> after April 2015, Oracle will not post further updates of Java SE 7 to
> its
> >>> public download sites
> >>
> >>
> >> So per our (draft) version number policy, we can keep Java 7 as the
> >> baseline :-( or we can choose to upgrade code to Java 8 (because we
> want to
> >> use lambdas... there's a requirement)
> >>
> >>
> >> So assuming we bump the master branch of Maven core to 3.4.0, what Java
> >> version do we want to use as the baseline?
> >>
> >> There are thankfully only two options:
> >>
> >> Java 7
> >>   + Not actually changing things
> >>   + May make it easier to drive adoption
> >>   - Still can't use newer language features in core
> >>   - Java 7 is EOL and it may get harder for developers to source JDKs to
> >> test and develop against
> >
> > Bumping Java requirements again in minor (!) release is insane. I am
> against that, regardless Oracle has set this EoL or not. Folks at Commons
> are doing the right this. Bump requirement with a major not a minor.
> Moreover, we have too many components which have been neglected for years,
> too many outstanding issues in JIRA. E.g., Doxia, I try to fix some once in
> a while but there a too few of us to take care of the entire Maven
> ecosystem.
> >
> > I would rather see us to bringing the entire system on a decent level
> before we make a big leaps which Java. It does not make sense to be to put
> Maven on the fast lane but let other components suffer at the edge of the
> road.
> >
> > Michael
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
>
> Thanks,
>
> Jason
>
> --
> Jason van Zyl
> Founder, Takari and Apache Maven
> http://twitter.com/jvanzyl
> http://twitter.com/takari_io
> -
>
> Be not afraid of growing slowly, be only afraid of standing still.
>
>  -- Chinese Proverb
>
>
>
>
>
>
>
>
>
>
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: [DISCUSS] Java version requirement for Mavan 3.4.x

[Igor Fedorenko]

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 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://www.theoryinpractice.net
> http://www.chaliceofblood.net
> http://plus.google.com/+MarkDerricutt
> http://twitter.com/talios
> http://facebook.com/mderricutt
> Email had 1 attachment:
> + signature.asc
>   1k (application/pgp-signature)

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [DISCUSS] Java version requirement for Mavan 3.4.x

[Mirko Friedenhagen]

+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 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 "To build
> a modelVersion 5.0 pom you need Maven 5"
>
> So if there is strong interest in jumping to Java 8 perhaps we just bite
> the bullet and jump to Maven 4.0 with Java 8 now and then we can start the
> model version 5.0 debate in earnest as we plan the features for Maven 5.0
> ;-)
>
> -Stephen
>
> On 30 November 2015 at 22:25, Jason van Zyl  wrote:
>
> > 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 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:
> > >>
> > >> The development line of Maven core should require a minimum JRE
> version
> > >>> that is no older than 18 months after the end of Oracle's public
> > updates
> > >>> for that JRE version at the time that the first version of the
> > development
> > >>> line was released, but may require a higher minimum JRE version if
> > other
> > >>> requirements dictate a higher JRE version
> > >>
> > >>
> > >> (Source:
> > >>
> https://cwiki.apache.org/confluence/display/MAVEN/Version+number+policy
> > )
> > >>
> > >> OK, so it's a draft policy... but we've all been silent on the draft,
> so
> > >> lazy consensus!
> > >>
> > >> Now in http://www.oracle.com/technetwork/java/javase/eol-135779.html
> > they
> > >> state:
> > >>
> > >> after April 2015, Oracle will not post further updates of Java SE 7 to
> > its
> > >>> public download sites
> > >>
> > >>
> > >> So per our (draft) version number policy, we can keep Java 7 as the
> > >> baseline :-( or we can choose to upgrade code to Java 8 (because we
> > want to
> > >> use lambdas... there's a requirement)
> > >>
> > >>
> > >> So assuming we bump the master branch of Maven core to 3.4.0, what
> Java
> > >> version do we want to use as the baseline?
> > >>
> > >> There are thankfully only two options:
> > >>
> > >> Java 7
> > >>   + Not actually changing things
> > >>   + May make it easier to drive adoption
> > >>   - Still can't use newer language features in core
> > >>   - Java 7 is EOL and it may get harder for developers to source JDKs
> to
> > >> test and develop against
> > >
> > > Bumping Java requirements again in minor (!) release is insane. I am
> > against that, regardless Oracle has set this EoL or not. Folks at Commons
> > are doing the right this. Bump requirement with a major not a minor.
> > Moreover, we have too many components which have been neglected for
> years,
> > too many outstanding issues in JIRA. E.g., Doxia, I try to fix some once
> in
> > a while but there a too few of us to take care of the entire Maven
> > ecosystem.
> > >
> > > I would rather see us to bringing the entire system on a decent level
> > before we make a big leaps which Java. It does not make sense to be to
> put
> > Maven on the fast lane but let other components suffer at the edge of the
> > road.
> > >
> > > Michael
> > >
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > For additional commands, e-mail: dev-h...@maven.apache.org
> > >
> >
> > Thanks,
> >
> > Jason
> >
> > --
> > Jason van Zyl
> > Founder, Takari and Apache Maven
> > http://twitter.com/jvanzyl
> > http://twitter.com/takari_io
> > -
> >
> > Be not afraid of growing slowly, be only afraid of standing still.
> >
> >  -- Chinese Proverb
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
>

Re: [DISCUSS] Java version requirement for Mavan 3.4.x

[Kristian Rosenvold]

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 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.


Kristian

2015-12-01 6:59 GMT+01:00 Mirko Friedenhagen :
> +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 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 "To build
>> a modelVersion 5.0 pom you need Maven 5"
>>
>> So if there is strong interest in jumping to Java 8 perhaps we just bite
>> the bullet and jump to Maven 4.0 with Java 8 now and then we can start the
>> model version 5.0 debate in earnest as we plan the features for Maven 5.0
>> ;-)
>>
>> -Stephen
>>
>> On 30 November 2015 at 22:25, Jason van Zyl  wrote:
>>
>> > 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 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:
>> > >>
>> > >> The development line of Maven core should require a minimum JRE
>> version
>> > >>> that is no older than 18 months after the end of Oracle's public
>> > updates
>> > >>> for that JRE version at the time that the first version of the
>> > development
>> > >>> line was released, but may require a higher minimum JRE version if
>> > other
>> > >>> requirements dictate a higher JRE version
>> > >>
>> > >>
>> > >> (Source:
>> > >>
>> https://cwiki.apache.org/confluence/display/MAVEN/Version+number+policy
>> > )
>> > >>
>> > >> OK, so it's a draft policy... but we've all been silent on the draft,
>> so
>> > >> lazy consensus!
>> > >>
>> > >> Now in http://www.oracle.com/technetwork/java/javase/eol-135779.html
>> > they
>> > >> state:
>> > >>
>> > >> after April 2015, Oracle will not post further updates of Java SE 7 to
>> > its
>> > >>> public download sites
>> > >>
>> > >>
>> > >> So per our (draft) version number policy, we can keep Java 7 as the
>> > >> baseline :-( or we can choose to upgrade code to Java 8 (because we
>> > want to
>> > >> use lambdas... there's a requirement)
>> > >>
>> > >>
>> > >> So assuming we bump the master branch of Maven core to 3.4.0, what
>> Java
>> > >> version do we want to use as the baseline?
>> > >>
>> > >> There are thankfully only two options:
>> > >>
>> > >> Java 7
>> > >>   + Not actually changing things
>> > >>   + May make it easier to drive adoption
>> > >>   - Still can't use newer language features in core
>> > >>   - Java 7 is EOL and it may get harder for developers to source JDKs
>> to
>> > >> test and develop against
>> > >
>> > > Bumping Java requirements again in minor (!) release is insane. I am
>> > against that, regardless Oracle has set this EoL or not. Folks at Commons
>> > are doing the right this. Bump requirement with a major not a minor.
>> > Moreover, we have too many components which have been neglected for
>> years,
>> > too many outstanding issues in JIRA. E.g., Doxia, I try to fix some once
>> in
>> > a while but there a too few of us to take care of the entire Maven
>> > ecosystem.
>> > >
>> > > I would rather see us to bringing the entire system on a decent level
>> > before we make a big leaps which Java. It does not make sense to be to
>> put
>> > Maven on the fast lane but let other components suffer at the edge of the
>> > road.
>> > >
>> > > Michael
>> > >
>> > >
>> > > -
>> > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> > > For additional commands, e-mail: dev-h...@maven.apache.org
>> > >
>> >
>> > Thanks,
>> >
>> > Jason
>> >
>> > --
>> > Jason van Zyl
>> > Founder, Takari and Apache Maven
>> > http://twitter.com/jvanzyl
>> > http://twitter.com/takari_io
>> >