Il giorno mar 29 ott 2019 alle ore 14:22 Stephen Connolly < stephen.alan.conno...@gmail.com> ha scritto:
> Because maintaining Java 7 is a barrier to new contributors. It is tricky > enough to get Java 8 set up for some developers. Every version we support > adds complexity for contributors. Personally, I think we should be thinking > about dropping even Java 8 if we wait until next year and just follow the > latest LTS line... but I am happy to keep with Java 8 as a baseline for > now. Java 7 is only supported for a limited number of environments right > now, whereas Java 8 has multiple vendors supporting it against multiple > platforms at least until mid 2023. > > We hold back the entire community if we stick on a base version for too > long. > totally true ! We should only move to "target/source" 8, we do not need to change the code (lamdas), we can do it whenever we want Enrico > > On Tue, 29 Oct 2019 at 13:00, Michael Osipov <1983-01...@gmx.net> wrote: > > > 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 > > > > >
