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 >> > > > > > > >> > > > > > >> > > > > >> > > > >> > > >> > >> >
