Why not have 3.7.0 plugin updates and other non-technical stuff, have it parallely maintained for some time and move with Maven 3.8.0 to Java 8 next year?!
Does that sound like a plan? I'd be happy with that. I'd also expect an announcement on dev@, announce@ and users@. Michael > Gesendet: Dienstag, 29. Oktober 2019 um 13:49 Uhr > Von: "Stephen Connolly" <stephen.alan.conno...@gmail.com> > An: "Maven Developers List" <dev@maven.apache.org> > Betreff: Re: [DISCUSS] Maven 3.7.0 > > On Tue, 29 Oct 2019 at 12:47, Stephen Connolly < > stephen.alan.conno...@gmail.com> wrote: > > > We already have a version policy: > > https://cwiki.apache.org/confluence/display/MAVEN/Version+number+policy > > > > (while that page says draft, the proposal was on-list in 2014 and just > converted into a wiki page afterwards - hence why the examples use 2014 > dates) > > > > > The development line of Maven core should require a minimum 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. > > > > End of public updates for Java 8 from Oracle was January 2019, thus if we > > cut a new minor version we would be Java 8 but not Java 7. > > > > > > On Tue, 29 Oct 2019 at 12:28, Tibor Digana <tibordig...@apache.org> wrote: > > > >> Stephen, we are in loop. > >> Of course I know these technical things. > >> But I am saying, and I am not alone (Michael Osipov too), that I agree > >> with > >> sources 1.8, but there must be1. the Vote with milestones regarding Maven > >> and another Vote regarding plugins, and 2. written list of pros/cons > >> regarding J8 and 3. developer guideline for J8 (for devs, consultants, > >> another professions as well in the team). > >> You know, with video calls, all these public emails would be gone within > >> one or two hours, I am sure! > >> I am also sure that we will have another code preferences and therefore we > >> should have some guideline. For instance, I like to have clear OOP in the > >> public class/interfaces and Lambda in private code. And there are a lot of > >> stuff, like parallel streams ala thread pool of non-daemon threads, > >> performance of streams (when, how stream is constructed, etc), Date Time > >> API is new as well. > >> > >> No benefit for the community with J7 sources but yes with J8 code. Believe > >> me, this is true. Michael mentioned that as well. > >> > > > > Not true. Java 8 bytecode adds additional metadata that speeds up > > classloading (but only when the class graph is all Java 8) > > > > > >> > >> It is also true that we have a lot of bugs, and it is true that Maven > >> needs > >> to have breakthrough features like reproducible build and User POM, Docker > >> prefetched cache, etc. > >> I have no argument against these things. The only problem that I have and > >> Michael has is the way how this is managed but it is the only trivial > >> problem that we can solve between us. > >> > >> > >> > >> > >> > >> On Tue, Oct 29, 2019 at 1:04 PM Stephen Connolly < > >> stephen.alan.conno...@gmail.com> wrote: > >> > >> > You cannot have Java 8 sources produce Java 7 bytecode with the Java 8's > >> > javac. > >> > > >> > -target must be >= -source > >> > > >> > So to say: > >> > > >> > > So I vote -1 for J8 bytecode, and I vote +1 for J8 source code! > >> > > >> > Is not possible, you'll get something like: > >> > > >> > $ javac Test -source 1.8 -target 1.7 > >> > javac: source release 1.8 requires target release 1.8 > >> > > >> > While we could use something like > >> https://github.com/luontola/retrolambda > >> > its usage is not without significant risks. You really need to be very > >> > careful in how you use it, and the effort is IMHO far exceeding the > >> risk. > >> > Much better to just say Maven 3.7.0 is requires the runtime JVM be Java > >> 8+, > >> > use toolchains if you need to compile or unit tests with older JDKs. > >> > > >> > We have agreed before that upgrading the Maven minor or major version > >> would > >> > affect the JREs that Maven can run on. Basically following a one and one > >> > back for Oracle supported JDKs, thus 3.7.0 per that policy would be > >> forced > >> > to Java 8 as minimum anyway.... in other words, our users should be > >> > expecting us to go Java 8 as baseline. > >> > > >> > On Tue, 29 Oct 2019 at 10:28, Tibor Digana <tibordig...@apache.org> > >> wrote: > >> > > >> > > Stephen, what issue with current toolchain you mean? > >> > > > >> > > On Tue, Oct 29, 2019 at 11:11 AM Stephen Connolly < > >> > > stephen.alan.conno...@gmail.com> wrote: > >> > > > >> > > > On Tue, 29 Oct 2019 at 08:02, Tibor Digana <tibordig...@apache.org> > >> > > wrote: > >> > > > > >> > > > > Robert, I saw the code. The class has a method which returns > >> Lambda > >> > > > > function. The whole class was designed with OOP. The OOP is a good > >> > > thing > >> > > > > which you should follow and follow this approach and not to return > >> > the > >> > > > > labda function. Basically it is a precedense created in the PR > >> saying > >> > > > that > >> > > > > now J8 has to be used in the bytecode. > >> > > > > So I vote -1 for J8 bytecode, and I vote +1 for J8 source code! > >> > > > > > >> > > > > >> > > > That is not possible using the current toolchains. Let's just go > >> with > >> > > Java > >> > > > 8. There seems no good reason to hold back > >> > > > > >> > > > > >> > > > > > >> > > > > On Tue, Oct 29, 2019 at 8:25 AM Robert Scholte < > >> rfscho...@apache.org > >> > > > >> > > > > wrote: > >> > > > > > >> > > > > > The outcome is quite clear to me. There no clear 'No' to add > >> this > >> > > > > > build/consumer feature into 3.7.0, so we'll add it which > >> implies we > >> > > > must > >> > > > > > move to Java 8 due to new APIs with Java 8 class signatures. > >> > > > > > > >> > > > > > But first we need to deliver a 3.6.3 regression release. > >> > > > > > > >> > > > > > Robert > >> > > > > > > >> > > > > > On 29-10-2019 05:53:25, Romain Manni-Bucau < > >> rmannibu...@gmail.com> > >> > > > > wrote: > >> > > > > > +1, the risk is more or less 0 since we can still use branches > >> for > >> > > > > > potential fixes for "old" projects using frozen java and maven > >> > > versions > >> > > > > > anyway > >> > > > > > > >> > > > > > Guess we can even be very precautionous doing 1. an upgrade to > >> > > bytecode > >> > > > > > version without any code change (to change the major version in > >> > > > > bytecode), > >> > > > > > 2. a M1 to let users test it if some still doubt. > >> > > > > > > >> > > > > > Le mar. 29 oct. 2019 à 04:06, Olivier Lamy a écrit : > >> > > > > > > >> > > > > > > so what is the status of this? > >> > > > > > > will we discuss in 2025 about being able to use java 8 apis > >> or do > >> > > we > >> > > > > have > >> > > > > > > to wait 2030? > >> > > > > > > Sorry to be sarcastic but not moving forward it's certainly a > >> > > reason > >> > > > > why > >> > > > > > we > >> > > > > > > do not have more people participating in the project.... > >> > > > > > > It is so frustrating to be stuck with old apis... > >> > > > > > > > >> > > > > > > > >> > > > > > > > >> > > > > > > On Thu, 10 Oct 2019 at 04:36, Tibor Digana wrote: > >> > > > > > > > >> > > > > > > > I have to fully agree on Michael Osipov. This discussion is > >> > > > > > > > contraproductive from the time perspective. > >> > > > > > > > He explained the situation in Maven very clearly that we > >> have > >> > > over > >> > > > > 1800 > >> > > > > > > > bugs and here we are talking about javac compiler version > >> which > >> > > > does > >> > > > > > not > >> > > > > > > > fix these bugs. > >> > > > > > > > We know that our community is quite big but we also know > >> that > >> > we > >> > > > have > >> > > > > > > only > >> > > > > > > > few several developers who regularily provides fixes for the > >> > bug > >> > > > and > >> > > > > > they > >> > > > > > > > do it for free! > >> > > > > > > > So my advice is to leave these talks alone about technology > >> > lobby > >> > > > > (seen > >> > > > > > > on > >> > > > > > > > ML from outside as well) and rather concentrate on the bug. > >> We > >> > > have > >> > > > > > seen > >> > > > > > > > that the users/contributors handled performance issues and > >> > fixed > >> > > > them > >> > > > > > > which > >> > > > > > > > means that these contributors got very good proficiency > >> level! > >> > > > > > > > > >> > > > > > > > On Wed, Oct 9, 2019 at 7:56 PM Alexander Ashitkin <> > >> > > > > > > ashitkin.a...@gmail.com > >> > > > > > > > > > >> > > > > > > > wrote: > >> > > > > > > > > >> > > > > > > > > Totally disagree on the point. Writing java7 code after 8 > >> > makes > >> > > > you > >> > > > > > > feel > >> > > > > > > > > suffering - because instead of expressive stream based > >> > > operations > >> > > > > and > >> > > > > > > > > lambdas you write pointless iterators and copy > >> collections. > >> > > > > > > > > It is purely subjective opinion that lambdas make code > >> less > >> > > > > readable > >> > > > > > - > >> > > > > > > at > >> > > > > > > > > least there is an absolutely opposite opinion > >> > > > > > > > > > >> > > > > > > > > Thank you > >> > > > > > > > > Aleks > >> > > > > > > > > > >> > > > > > > > > On 2019/10/03 12:47:35, Paul Hammant wrote: > >> > > > > > > > > > Who codes for 18 months before discovering that qa/prod > >> are > >> > > not > >> > > > > > > > > compatible, > >> > > > > > > > > > anymore? Especially if Google ship a use-this-Pom > >> starter. > >> > > > > > > > > > > >> > > > > > > > > > On Thu, Oct 3, 2019 at 1:44 PM Elliotte Rusty Harold <> > >> > > > > > > > elh...@ibiblio.org > >> > > > > > > > > > > >> > > > > > > > > > wrote: > >> > > > > > > > > > > >> > > > > > > > > > > Theoretically that would work. In practice though, > >> every > >> > > > > project > >> > > > > > > I've > >> > > > > > > > > > > seen convert to Java 8 rapidly starts adding lambdas > >> that > >> > > > make > >> > > > > > the > >> > > > > > > > > > > code more obfuscated for no good reason and soon > >> > introduces > >> > > > > hard > >> > > > > > > > > > > dependencies on Java 8, intentionally or otherwise. > >> At a > >> > > bare > >> > > > > > > > minimum, > >> > > > > > > > > > > a CI environment that runs Java 7 is required. > >> > > > > > > > > > > > >> > > > > > > > > > > On Thu, Oct 3, 2019 at 8:25 AM Paul Hammant > >> > > > > > > > wrote: > >> > > > > > > > > > > > > >> > > > > > > > > > > > Would jdk 8 for maven itself and a target of 7 for > >> the > >> > > > > compiler > >> > > > > > > > > (etc) for > >> > > > > > > > > > > > maven-using projects be ok? > >> > > > > > > > > > > > > >> > > > > > > > > > > > On Thu, Oct 3, 2019 at 1:15 PM Elliotte Rusty > >> Harold <> > >> > > > > > > > > elh...@ibiblio.org > >> > > > > > > > > > > > > >> > > > > > > > > > > > wrote: > >> > > > > > > > > > > > > >> > > > > > > > > > > > > Strong -1 on Java 8 as the minimum version. Google > >> > > Cloud > >> > > > > > > Platform > >> > > > > > > > > has > >> > > > > > > > > > > > > lots of products and customers that still require > >> > Java > >> > > 7. > >> > > > > If > >> > > > > > > > Maven > >> > > > > > > > > > > > > requires Java 8, we'd have to stick to the latest > >> of > >> > > > > > whichever > >> > > > > > > > > release > >> > > > > > > > > > > > > does support Java 7 for at least a year and I'm > >> > > guessing > >> > > > > > > longer. > >> > > > > > > > > > > > > > >> > > > > > > > > > > > > On Sat, Sep 28, 2019 at 8:04 AM Robert Scholte <> > >> > > > > > > > > rfscho...@apache.org> > >> > > > > > > > > > > > > wrote: > >> > > > > > > > > > > > > > > >> > > > > > > > > > > > > > Hi, > >> > > > > > > > > > > > > > > >> > > > > > > > > > > > > > TLDR; introduce maven.experimental.buildconsumer > >> > and > >> > > > push > >> > > > > > > Java > >> > > > > > > > > > > > > requirement > >> > > > > > > > > > > > > > to Java 8 > >> > > > > > > > > > > > > > > >> > > > > > > > > > > > > > now that Maven 3.6.2 is out for a couple of > >> weeks, > >> > it > >> > > > > seems > >> > > > > > > > like > >> > > > > > > > > we > >> > > > > > > > > > > > > didn't > >> > > > > > > > > > > > > > face real regressions. > >> > > > > > > > > > > > > > The only one might be tricky is the issue > >> related > >> > to > >> > > > > Tycho. > >> > > > > > > > > > > > > > > >> > > > > > > > > > > > > > However, I think we're ready to push Maven to > >> the > >> > > next > >> > > > > > level. > >> > > > > > > > > > > > > > > >> > > > > > > > > > > > > > For those actively reading this list, they > >> should > >> > > > > recognize > >> > > > > > > the > >> > > > > > > > > need > >> > > > > > > > > > > for > >> > > > > > > > > > > > > > splitting up the pom as it is on the local > >> system > >> > > > versus > >> > > > > > the > >> > > > > > > > pom > >> > > > > > > > > > > being > >> > > > > > > > > > > > > > uploaded. Once we truly control this mechanism > >> we > >> > can > >> > > > > think > >> > > > > > > of > >> > > > > > > > > > > > > > improvements on model 5.0.0 and new fileformats. > >> > > > > > > > > > > > > > > >> > > > > > > > > > > > > > I've created and implemented MNG-6656[1]. It > >> also > >> > > > > contains > >> > > > > > a > >> > > > > > > > zip > >> > > > > > > > > > > with an > >> > > > > > > > > > > > > > example (original, patched, README) to > >> understand > >> > > > what's > >> > > > > > > > > happening. > >> > > > > > > > > > > > > > > >> > > > > > > > > > > > > > In order to make this successful, we need IDEs > >> and > >> > CI > >> > > > > > Servers > >> > > > > > > > to > >> > > > > > > > > > > > > > understand and support these changes. The likely > >> > need > >> > > > to > >> > > > > > > > > implement > >> > > > > > > > > > > one of > >> > > > > > > > > > > > > > the interfaces[2]. > >> > > > > > > > > > > > > > The new interface uses Java8 Functions (and > >> > > especially > >> > > > > > > > > > > SAXEventFactory is > >> > > > > > > > > > > > > > way easier to read+maintain with Java 8). I've > >> > tried > >> > > to > >> > > > > > keep > >> > > > > > > > > Maven > >> > > > > > > > > > > Java 7 > >> > > > > > > > > > > > > > compatible, but that was too hard to do. > >> > > > > > > > > > > > > > So I'd like to use this opportunity to move > >> Maven > >> > > > forward > >> > > > > > and > >> > > > > > > > > start > >> > > > > > > > > > > > > > requiring Java 8. > >> > > > > > > > > > > > > > > >> > > > > > > > > > > > > > There are some other improvements I'd like to > >> add > >> > > > (those > >> > > > > > > > messages > >> > > > > > > > > > > will > >> > > > > > > > > > > > > > follow), so this will imply that it will take > >> some > >> > > time > >> > > > > > > before > >> > > > > > > > > we do > >> > > > > > > > > > > a > >> > > > > > > > > > > > > new > >> > > > > > > > > > > > > > release. > >> > > > > > > > > > > > > > > >> > > > > > > > > > > > > > WDTY, > >> > > > > > > > > > > > > > Robert > >> > > > > > > > > > > > > > > >> > > > > > > > > > > > > > [1] > >> https://issues.apache.org/jira/browse/MNG-6656 > >> > > > > > > > > > > > > > [2] > >> > > > > > > https://github.com/apache/maven/compare/MNG-6656?expand=1 > >> > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > >> > > > > > > > > > >> > > > > > >> --------------------------------------------------------------------- > >> > > > > > > > > > > > > > To unsubscribe, e-mail: > >> > > > dev-unsubscr...@maven.apache.org > >> > > > > > > > > > > > > > For additional commands, e-mail: > >> > > > > dev-h...@maven.apache.org > >> > > > > > > > > > > > > > > >> > > > > > > > > > > > > > >> > > > > > > > > > > > > > >> > > > > > > > > > > > > -- > >> > > > > > > > > > > > > Elliotte Rusty Harold > >> > > > > > > > > > > > > elh...@ibiblio.org > >> > > > > > > > > > > > > > >> > > > > > > > > > > > > > >> > > > > > > > > > >> > > > > > >> --------------------------------------------------------------------- > >> > > > > > > > > > > > > To unsubscribe, e-mail: > >> > > dev-unsubscr...@maven.apache.org > >> > > > > > > > > > > > > For additional commands, e-mail: > >> > > > dev-h...@maven.apache.org > >> > > > > > > > > > > > > > >> > > > > > > > > > > > > > >> > > > > > > > > > > > >> > > > > > > > > > > > >> > > > > > > > > > > > >> > > > > > > > > > > -- > >> > > > > > > > > > > Elliotte Rusty Harold > >> > > > > > > > > > > elh...@ibiblio.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 > >> > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > >> > > > > > > > >> > > > > > > > >> > > > > > > -- > >> > > > > > > Olivier Lamy > >> > > > > > > http://twitter.com/olamy | http://linkedin.com/in/olamy > >> > > > > > > > >> > > > > > > >> > > > > > >> > > > > >> > > > >> > > >> > > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
