On Tue, 29 Oct 2019 at 12:49, Stephen Connolly < stephen.alan.conno...@gmail.com> wrote:
> 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) > https://lists.apache.org/thread.html/41a693d0e5787fa8af33ab0724a95c3ed0374fe2d860c2357a5565a9@1392995450@%3Cdev.maven.apache.org%3E > >> > 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 >>> > > > > > > >>> > > > > > >>> > > > > >>> > > > >>> > > >>> > >>> >>
