One of the fundamental features of Maven is Convention Over Configuration, in other words: define defaults where possible, but make it possible to change these values. However, "default" can be explained differently, either as constant (forever) or as a predefined value within a certain context.
A lot of projects don't lock their plugins and up until Maven 2.0.9 the LATEST version was used. This could mean that with any new plugin release builds could break without any changes in their own codebase. Because of that Maven started defining default versions for the most common plugins. These defaults have been the same for a long time to prevent situations as before Maven 2.0.9 Upgrading plugin defaults in Maven will break builds, because project actually rely on these defaults, intended or not. We should have a good answer when things do break. Some options: - figure out the problematic plugins and lock their version - stay on Maven 3.6.3 to have the combinations of plugin versions that do work together. Assuming most developers only have 1 version of Maven on their machine, both these answer aren't nice. And even with multiple Maven versions, switching between them isn't that nice. There is one other solution that will help in this case: make sure the project is being build with Maven version X. Such solution already exists, but most users are not aware of it and expect it to be part of Maven itself (as with Gradle): it is called the Maven Wrapper. I'm already negotiating about the codebase and IP, hopefully we'll have positive results soon. To me the upgrades of plugin defaults must be combined with the introduction of the Maven Wrapper as part of Maven core to have the least amount of issues. Robert On 29-10-2019 14:00:49, 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" > An: "Maven Developers List" > 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 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 > >> 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 > >> > > 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
