Beyond Java Level, I think we should start thinking about a CDI 1.2 / Java
EE 7 branch. JDK8 could be nice for this branch but we should make sure
that all Java EE 7 server out there run well on JDK 8

Antoine

Le mar. 12 avr. 2016 à 14:04, Gerhard Petracek <gerhard.petra...@gmail.com>
a écrit :

> @john:
>
> if we have/keep one jdk6 based ci-job and it passes, it's as fine as our
> current support of jdk8 (which is also checked by just one ci-job).
> the rest is up to the ci-servers used for testing the different
> cdi-implementations (and ee-servers).
>
> @"latest version":
> that's why i said "random". it depends on the concrete version available on
> the ci-server/s (we don't control that on our own).
>
> regards,
> gerhard
>
>
>
> 2016-04-12 13:07 GMT+02:00 John D. Ament <johndam...@apache.org>:
>
> > @gerhard
> > So you're saying its coincidence that the Java 6 versions fail?
> >
> > Basically, its not random releases.  Its the latest Java 6 supported by
> the
> > asf infra on Jenkins.
> >
> > John
> >
> > On Sat, Apr 9, 2016 at 3:42 PM Gerhard Petracek <gpetra...@apache.org>
> > wrote:
> >
> > > @john:
> > > our ci-jobs are just about the basic compatibility with the different
> > > versions of owb, weld and several (open-source-)ee-servers.
> > > there are only few which test the basic compatibility with different
> > > versions of the jdk explicitly (e.g. jdk8).
> > > we never test against all jdk-releases (it's always a "random" release
> -
> > we
> > > just configure the major-version).
> > > esp. with jdk7 we saw issues caused by different reasons with
> > specific/old
> > > versions of the jdk (in most cases one of the maven-plugins failed ->
> it
> > > wasn't even ds itself).
> > > -> we can never test all >jdk releases< in combination with all
> > > cdi-implementations and ee-servers.
> > >
> > > regards,
> > > gerhard
> > >
> > >
> > >
> > > 2016-04-09 15:13 GMT+02:00 John D. Ament <johndam...@apache.org>:
> > >
> > > > Actually the main reason I brought it up was that we currently cannot
> > > > guarantee inter-operability with Java 6 any longer.  If I look at our
> > CI
> > > > tests, very few of the tests that actually run against Java 6
> > > environments
> > > > pass.
> > > >
> > > > This page should give a clearer indication of that problem:
> > > >
> > > >
> > >
> >
> https://builds.apache.org/view/A-D/view/DeltaSpike/job/DeltaSpike%20for%20CDI%201.0/
> > > >
> > > > John
> > > >
> > > > On Thu, Apr 7, 2016 at 11:12 AM Cody Lerum <cody.le...@gmail.com>
> > wrote:
> > > >
> > > > > At this point it seems the main driver for dropping Java6 is to
> > > > > discourage its use. I think there is sufficient discouragement
> > > > > elsewhere and anyone with active or new projects is working towards
> > or
> > > > > planning for Java7/8.
> > > > >
> > > > > +1 for keeping Java6 until the next major bump.
> > > > >
> > > > > On Thu, Apr 7, 2016 at 7:25 AM, Mark Struberg
> > > <strub...@yahoo.de.invalid
> > > > >
> > > > > wrote:
> > > > > > Agree, we don't gain much with moving to Java7.
> > > > > >
> > > > > > Thus I'd say that we keep Java6/CDI-1.0 and have the next major
> > > version
> > > > > bump (aka DeltaSpike-2.x) targeting Java8 and CDI-2.0. But of
> course
> > > > keep a
> > > > > ds-1.x maintenance branch even after that for a while.
> > > > > >
> > > > > >
> > > > > > LieGrue,
> > > > > > strub
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >> On Thursday, 7 April 2016, 14:42, Gerhard Petracek <
> > > > > gpetra...@apache.org> wrote:
> > > > > >> > as mentioned in the initial discussion i also don't see a real
> > > > > benefit for
> > > > > >> us as a community (to drop the java 6 support at this point).
> > > > > >> in the end ds targets ee6 + supports ee7 servers (including
> > optional
> > > > > >> features).
> > > > > >> ee6 isn't bound to java 6 technically, however, e.g. some
> vendors
> > > > > require
> > > > > >> it...
> > > > > >>
> > > > > >> regards,
> > > > > >> gerhard
> > > > > >>
> > > > > >>
> > > > > >>
> > > > > >>
> > > > > >> 2016-04-07 13:18 GMT+02:00 Rooda, William (John.) <
> > wro...@ford.com
> > > >:
> > > > > >>
> > > > > >>>  Ford has an internal “shared farm” of servers that our
> > > applications
> > > > > can
> > > > > >>>  use. The shared farm is Websphere Application Server 8.0.0.x.
> > > This
> > > > > only
> > > > > >>>  has Java6 available.  While some teams go out and spend the
> > money
> > > to
> > > > > >>>  procure their own servers outside of the shared farm, this is
> > > > > prohibitively
> > > > > >>>  expensive without a powerful use case.
> > > > > >>>
> > > > > >>>
> > > > > >>>
> > > > > >>>  Our Java applications won't have a server offering in our
> > internal
> > > > > >> shared
> > > > > >>>  farm for Java 7 until 4Q2016 or 1Q2017 at the earliest. We
> plan
> > on
> > > > > >>>  developing almost all applications against Java6 until that
> > time,
> > > > and
> > > > > >>>  unfortunately we have to re-evaluate continuing to use at an
> > > > > enterprise
> > > > > >>>  level any open source software that no longer patches and
> > supports
> > > > > Java6
> > > > > >>>  due to the risk it introduces to our applications. We
> understand
> > > > that
> > > > > this
> > > > > >>>  makes us an outlier in the community of DeltaSpike users.
> > > > > >>>
> > > > > >>>
> > > > > >>>
> > > > > >>>  Thanks,
> > > > > >>>
> > > > > >>>
> > > > > >>>
> > > > > >>>  ~john
> > > > > >>>
> > > > > >>>
> > > > > >>>  From: John D. Ament [mailto:johndam...@apache.org]
> > > > > >>>  Sent: Thursday, April 07, 2016 7:13 AM
> > > > > >>>  To: dev@deltaspike.apache.org; marvint...@gtcgroup.com
> > > > > >>>  Cc: Rooda, William (John.); Shvartsman, Oleg (O.I.); Hall,
> Todd
> > > > (T.B.)
> > > > > >>>  Subject: Re: Cutting over to Java 7
> > > > > >>>
> > > > > >>>  Hi Marvin,
> > > > > >>>
> > > > > >>>  Thanks for the input.  You can find our discussion/vote thread
> > > from
> > > > > last
> > > > > >>>  month here:
> > > > > >>>
> > > > > >>
> > > > >
> > > >
> > >
> >
> http://mail-archives.apache.org/mod_mbox/deltaspike-dev/201603.mbox/%3CCAOqetn_vo69sx-yQjLt%3DQpfdRXgXVqu7NiobanLgXKOOr6Co0Q%40mail.gmail.com%3E
> > > > > >>>
> > > > > >>>  The curious thing about your note - the WebSphere version I've
> > > seen
> > > > > the
> > > > > >>>  Ford team mention a few times requires Java 7.  In general,
> EE 7
> > > > > systems
> > > > > >>>  were built for Java 7 support (JMS made use of autocloseable
> is
> > > one
> > > > I
> > > > > can
> > > > > >>>  think of off the top of my head).
> > > > > >>>
> > > > > >>>  As mentioned, there's still a plan to support the 1.6.x line.
> > If
> > > > you
> > > > > >> guys
> > > > > >>>  find any issues that you need to stay on 1.6.x, please feel
> free
> > > to
> > > > > raise
> > > > > >>>  them and we can address as additional 1.6.x patches.
> > > > > >>>
> > > > > >>>  John
> > > > > >>>  On Thu, Apr 7, 2016 at 6:42 AM Marvin Toll <
> > > marvint...@gtcgroup.com
> > > > > >>>  <mailto:marvint...@gtcgroup.com>> wrote:
> > > > > >>>  A data point: Ford Motor Company is on Java 6.  Given our
> > > portfolio
> > > > of
> > > > > >>>  4,000 applications (a subset of which are Java) - it is
> > difficult
> > > to
> > > > > know
> > > > > >>>  how long a migration to Java 7 will take.  It was scheduled to
> > > begin
> > > > > in
> > > > > >>>  calendar year 2016 - the current "begin" target is 2017.
> > > > > >>>
> > > > > >>>  _Marvin
> > > > > >>>
> > > > > >>>  -----Original Message-----
> > > > > >>>  From: John D. Ament [mailto:johndam...@apache.org<mailto:
> > > > > >>>  johndam...@apache.org>]
> > > > > >>>  Sent: Wednesday, April 6, 2016 10:14 PM
> > > > > >>>  To: deltaspike
> > > > > >> <dev@deltaspike.apache.org<mailto:dev@deltaspike.apache.org
> > > > > >>>  >>
> > > > > >>>  Subject: Cutting over to Java 7
> > > > > >>>
> > > > > >>>  All,
> > > > > >>>
> > > > > >>>  I wanted to get opinions for how to cut over to Java 7.
> > > > > >>>
> > > > > >>>  There's two ways I've done similar cut overs in the past,
> wanted
> > > to
> > > > > >> share
> > > > > >>>  them and build out some ideas.
> > > > > >>>
> > > > > >>>  1. Continue maintenance on 1.6 for x months.  When we decide
> > that
> > > > > we're
> > > > > >>>  going to cut a 1.7 we do the switch then.
> > > > > >>>
> > > > > >>>  2. Decide now that the next release is going to be planned as
> > 1.7.
> > > > > If we
> > > > > >>>  need to do maintenance on 1.6 we branch from the tag and merge
> > > back
> > > > > in when
> > > > > >>>  done.
> > > > > >>>
> > > > > >>>  The former is safer, but will take longer.  The last minor
> > release
> > > > > had the
> > > > > >>>  most patch releases on it, 4.  The latter is more practical
> and
> > > > shows
> > > > > >>>  implementation much quicker.  It creates a bit more overhead
> as
> > > we'd
> > > > > >> need
> > > > > >>>  to merge branches.  In the 4.5 years of deltaspike, we haven't
> > had
> > > > to
> > > > > >> do it
> > > > > >>>  thus yet.  I suspect that given our user base, #2 would be
> > > > acceptable
> > > > > since
> > > > > >>>  most everyone's using Java 7+, so it seems a small chance that
> > > we'd
> > > > > >> run
> > > > > >>>  into a JVM difference.  I'm not sure if others have different
> > > ideas
> > > > to
> > > > > >>>  throw out.
> > > > > >>>
> > > > > >>>  John
> > > > > >>>
> > > > > >>
> > > > >
> > > >
> > >
> >
>

Reply via email to