@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 <[email protected]>: > 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 <[email protected]> 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 <[email protected] > > > > 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 < > > [email protected]> 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.) <[email protected]>: > > >> > > >>> 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:[email protected]] > > >>> Sent: Thursday, April 07, 2016 7:13 AM > > >>> To: [email protected]; [email protected] > > >>> 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 <[email protected] > > >>> <mailto:[email protected]>> 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:[email protected]<mailto: > > >>> [email protected]>] > > >>> Sent: Wednesday, April 6, 2016 10:14 PM > > >>> To: deltaspike > > >> <[email protected]<mailto:[email protected] > > >>> >> > > >>> 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 > > >>> > > >> > > >
