@antoine: we support cdi 1.1/1.2 and ee7 already (see [1]). imo: we just need to continue with ds2 once cdi2 is available. for now we just need to improve our documentation/examples/test-coverage/... + add useful features.
regards, gerhard [1] http://mail-archives.apache.org/mod_mbox/deltaspike-dev/201603.mbox/%3CCAGJtJfGTjx2vfqgr4LZgmmJg6eNT41DekeDoZU4bujurmubbrA%40mail.gmail.com%3E 2016-04-12 17:26 GMT+02:00 Antoine Sabot-Durand <anto...@sabot-durand.net>: > 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 > > > > > > >>> > > > > > > >> > > > > > > > > > > > > > > > > > > > > >
