Mailing-List: contact dev-help@maven.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Maven Developers List" <dev@maven.apache.org>
MIME-Version: 1.0
In-Reply-To: 
 <CA+nPnMxsH2HuK2z4D+ELf8TzJO43TyVv_m4FMeun8oY3B_LbFA@mail.gmail.com>
References: 
 <CA+nPnMx7JR+r1HNAm2eDeARwp1-=5zqOPtU0ro-Z8naF-_KpRw@mail.gmail.com>
	<CAK8jvqy04dsXjo8xp92Uaw-MDR5XxnxjAK+=EfO30UrFqAC1wg@mail.gmail.com>
	<CAJZRQKxBs8s=ppcYC0Vyx2uQ3zKvb9LjBieL_kVmZDTJ8hkn9g@mail.gmail.com>
	<2289510.eTV2oMN0xd@herve-desktop>
	<CA+nPnMznfFenbaMRAR1LozD4v40v-UKQnE-TL24N1a+NF0MNPw@mail.gmail.com>
	<CABZhLO8VRubAREQg6KbEbg+Ca9iHX1V=Lci2M11XZ=s9LoGeZw@mail.gmail.com>
	<CA+nPnMxsH2HuK2z4D+ELf8TzJO43TyVv_m4FMeun8oY3B_LbFA@mail.gmail.com>
Date: Mon, 14 Dec 2015 01:16:08 +0100
Message-ID: 
 <CAKuVzBS2ebPQ-fqDsc4Mcijzi75Ar6wDLzcMTBSEx3pCsa8W8A@mail.gmail.com>
Subject: Re: [DISCUSS] Java version requirement for Mavan 3.4.x
From: Tibor Digana <tibor.digana@googlemail.com>
To: Maven Developers List <dev@maven.apache.org>
Content-Type: multipart/alternative; boundary=001a113fc1106e93770526d09497

--001a113fc1106e93770526d09497
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

i agree with stephenc that major version change =3D 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 plugin=
s

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.connolly@gmail.com> wrote:

> On 2 December 2015 at 09:07, Fred Cooke <fred.cooke@gmail.com> 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 becau=
se
> our API remains compatible and we are just removing JVMs that are no long=
er
> supported.
>
>
> >
> > "I agree that jumping to Java 8 would be unwise. I think we can wait
> until
> > 4.x. Don=E2=80=99t get me wrong, I=E2=80=99d prefer to use Java 8 and I=
 do for almost
> > everything else but I don=E2=80=99t think there=E2=80=99s 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 peop=
le
> prepared to maintain the older release lines
>
> 2. Think of the plugins in 2-3 years. Right now, to build a plugin and te=
st
> 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 versio=
ns
> of linux and there is no installer on my primary development platform...
> Similarly I need to do dancing games with older versions of windows... No=
w
> 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 i=
t
> 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... t=
he
> 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.connolly@gmail.com> wrote:
> >
> > > If we look at our JVM company history, IIRC
> > >
> > > 2.0 =3D Java 1.4
> > > 2.1 =3D Java 1.4
> > > 2.2 =3D Java 1.5
> > > 3.0 =3D Java 1.5
> > > 3.1 =3D Java 1.6
> > > 3.2 =3D Java 1.6
> > > 3.3 =3D 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 modelVersi=
on
> > > 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 wi=
th
> > 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 compil=
e
> > > 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) dow=
n
> > > below 1.4... With some VMs I was able to get down to 1.3 for some JVM=
s
> > 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 tha=
t
> > > starts now or in 6 months when JDK 9 comes out is a timing question
> only
> > > IMHO
> > >
> > > On Wednesday 2 December 2015, Herv=C3=A9 BOUTEMY <herve.boutemy@free.=
fr>
> > wrote:
> > >
> > > > from source code point of view, you don't need to change anything t=
o
> > > > 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=C3=A9
> > > >
> > > > [1]
> > > >
> > >
> >
> https://github.com/MavenDemo/java-evolving-en/blob/master/toolchains/bonu=
s.sh
> > > >
> > > > Le mardi 1 d=C3=A9cembre 2015 08:10:51 Kristian Rosenvold a =C3=A9c=
rit :
> > > > > 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, t=
he
> > > > > 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 <
> > mfriedenhagen@gmail.com
> > > > <javascript:;>>:
> > > > > > +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.connolly@gmail.com <javascript:;>>
> > > > > >
> > > > > > 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 versio=
n
> > > > 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 c=
an
> > > start
> > > > > >> the
> > > > > >> model version 5.0 debate in earnest as we plan the features fo=
r
> > > Maven
> > > > 5.0
> > > > > >> ;-)
> > > > > >>
> > > > > >> -Stephen
> > > > > >>
> > > > > >> On 30 November 2015 at 22:25, Jason van Zyl <jason@takari.io
> > > > <javascript:;>> wrote:
> > > > > >> > I agree that jumping to Java 8 would be unwise. I think we c=
an
> > > wait
> > > > > >> > until
> > > > > >> > 4.x. Don=E2=80=99t get me wrong, I=E2=80=99d prefer to use J=
ava 8 and I do for
> > > > almost
> > > > > >> > everything else but I don=E2=80=99t think there=E2=80=99s an=
y dire rush.
> > > > > >> >
> > > > > >> > > On Nov 30, 2015, at 2:00 PM, Michael Osipov <
> > > michaelo@apache.org
> > > > <javascript:;>>
> > > > > >>
> > > > > >> 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 minim=
um
> > 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 o=
n
> > 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 Jav=
a
> 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. Fol=
ks
> > 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 f=
ix
> > > 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 sens=
e
> to
> > > be
> > > > to
> > > > > >>
> > > > > >> put
> > > > > >>
> > > > > >> > Maven on the fast lane but let other components suffer at th=
e
> > edge
> > > > of
> > > > > >> > the
> > > > > >> > road.
> > > > > >> >
> > > > > >> > > Michael
> > > > > >> > >
> > > > > >> > >
> > > > > >> > >
> > > > -------------------------------------------------------------------=
--
> > > > > >> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > <javascript:;>
> > > > > >> > > For additional commands, e-mail: dev-help@maven.apache.org
> > > > <javascript:;>
> > > > > >> >
> > > > > >> > 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-unsubscribe@maven.apache.org
> > > > <javascript:;>
> > > > > >> > For additional commands, e-mail: dev-help@maven.apache.org
> > > > <javascript:;>
> > > > >
> > > > >
> ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > <javascript:;>
> > > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > > <javascript:;>
> > > >
> > > >
> > > > -------------------------------------------------------------------=
--
> > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > <javascript:;>
> > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > <javascript:;>
> > > >
> > > >
> > >
> > > --
> > > Sent from my phone
> > >
> >
>


--=20
Cheers
Tibor

--001a113fc1106e93770526d09497--