... and when I say "CodeHaus" above, I mean "Apache". Fair?
;) 2014-12-25 13:11 GMT+01:00 Lennart Jörelid <lennart.jore...@gmail.com>: > Quite true. > > :) > > But this opens another interesting discussion. > Do we move the codehaus products with the slowest of the major JDK release > cycles (i.e. to match the IBM JDK release cycle in this case)? > Or with the Oracle JDK's release cycles? > > There may not be much difference in the mechanics of JDK 6 and JDK 7 - but > there are certainly differences between JDK 8 and JDK 9, which we have to > cater for (or at least create a strategy to handle). If so - do we aim for > introducing module mechanics to match Oracle's JDK 9 release or the > eventual IBM JDK's release? Or something else entirely? > > > > 2014-12-25 12:46 GMT+01:00 Kristian Rosenvold < > kristian.rosenv...@gmail.com>: > >> It appears that IBM JDK6 is EOL september next year. People move at >> different speeds :) >> >> Kristian >> >> >> >> 2014-12-25 6:25 GMT+01:00 Gary Gregory <garydgreg...@gmail.com>: >> > +1 >> > >> > Gary >> > >> > <div>-------- Original message --------</div><div>From: Benson >> Margulies <bimargul...@gmail.com> </div><div>Date:12/24/2014 17:08 >> (GMT-05:00) </div><div>To: Maven Developers List <dev@maven.apache.org> >> </div><div>Cc: </div><div>Subject: Re: [DISCUSS] Move everything to 1.6, >> take 2 (was: Re: I can't make a >> > release ...) </div><div> >> > </div>Here's what I don't understand. I can see why people need to keep >> > building apps that run on antediluvian version. I can't see why it's >> > such a problem for a tool, such as Maven, to require 1.7. Who are we >> > accomodating by the current policy, or even the 1.6 plan? >> > >> > Meanwhile, it seems to me that we don't need a complex system of >> > releases. There will be no new 3.0.x releases except for some sort of >> > exceptional event. If we simply open up everything except the 3.0.x >> > branch of the core to 1.6 or 1.7, then the worst that happens is, in >> > the event of a security issue out in a component or a plugin, someone >> > has to make a branch from the last 1.5-compatible release to make the >> > fix. >> > >> > >> > On Wed, Dec 24, 2014 at 5:02 PM, Milos Kleint <mkle...@gmail.com> >> wrote: >> >> +1. >> >> >> >> jdk 1.6 is EOL-ed for some time (Feb 2013) already and even 1.7 will be >> >> EOL-ed in April 2015.. >> >> >> >> I would suggest moving straight to 1.7 but I guess that's been already >> >> discussed. >> >> >> >> Milos >> >> >> >> On Thu, Dec 25, 2014 at 7:54 AM, Robert Scholte <rfscho...@apache.org> >> >> wrote: >> >> >> >>> +1, would also make testing with JDK9 easier, although I've already >> found >> >>> a good solution for that. >> >>> >> >>> Robert >> >>> >> >>> Op Wed, 24 Dec 2014 14:20:06 +0100 schreef Kristian Rosenvold < >> >>> krosenv...@apache.org>: >> >>> >> >>> >> >>> Oops. Snappy contains 1.6 java bytecode, which breaks the build on >> maven >> >>>>> plugins. We need to upgrade to 1.6; I'm taking this to the mailing >> list :) >> >>>>> >> >>>> >> >>>> Last time discussed this we established a consensus to establish >> 3.0.5 >> >>>> (maybe 3.0.6) as a minimum baseline for the 3.x range of plugins. >> >>>> >> >>>> This 3.0.X has a 1.5 java requirement. The problem is that >> *everyone* >> >>>> is moving to 1.6 and it's getting increasingly hard to maintain a 1.5 >> >>>> code base. As an example, I have been moving code to apache commons, >> >>>> but we're basically unable to use this effort because commons is now >> >>>> 1.6. alternately I need to backport the code in a >> >>>> "source-level-shading", but these things are getting silly. >> >>>> >> >>>> I propose the following: >> >>>> >> >>>> Make the 3.x line of plugins java 1.6+ only. >> >>>> Release all shared utilities in 1.6 versions in the 3.x version >> range. >> >>>> 3.0.X maven versions stay "forever" on the 2.x line of plugins and >> jdk >> >>>> 1.5. >> >>>> The most recent core version moves defaults to the 3.x range of >> plugins. >> >>>> The parent poms migrate to 3.x range some time in the near future. >> >>>> >> >>>> Keeping 3.0.x fixes to a minuimum (and "critical" stuff) only, will >> >>>> ensure that we can still stay 1.5 compatible here. >> >>>> >> >>>> >> >>>> Kristian >> >>>> >> >>>> 2014-12-24 13:52 GMT+01:00 Benson Margulies <bimargul...@gmail.com>: >> >>>> >> >>>>> I don't have access to push a plexus-archiver release, could you >> >>>>> please do the honors. >> >>>>> >> >>>>> Also, looks like my splitting job left some work behind in terms of >> >>>>> the parent pom. >> >>>>> >> >>>> >> >>>> --------------------------------------------------------------------- >> >>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> >>>> For additional commands, e-mail: dev-h...@maven.apache.org >> >>>> >> >>> >> >>> --------------------------------------------------------------------- >> >>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> >>> For additional commands, e-mail: dev-h...@maven.apache.org >> >>> >> >>> >> > >> > --------------------------------------------------------------------- >> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> > For additional commands, e-mail: dev-h...@maven.apache.org >> > >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> For additional commands, e-mail: dev-h...@maven.apache.org >> >> > > > -- > > -- > +==============================+ > | Bästa hälsningar, > | [sw. "Best regards"] > | > | Lennart Jörelid > | EAI Architect & Integrator > | > | jGuru Europe AB > | Mölnlycke - Kista > | > | Email: l...@jguru.se > | URL: www.jguru.se > | Phone > | (skype): jgurueurope > | (intl): +46 708 507 603 > | (domestic): 0708 - 507 603 > +==============================+ > > -- -- +==============================+ | Bästa hälsningar, | [sw. "Best regards"] | | Lennart Jörelid | EAI Architect & Integrator | | jGuru Europe AB | Mölnlycke - Kista | | Email: l...@jguru.se | URL: www.jguru.se | Phone | (skype): jgurueurope | (intl): +46 708 507 603 | (domestic): 0708 - 507 603 +==============================+
