I've now closed all PR's, and deleted the source branches. Giles I've pushed the changes back into my commons-lang fork, so this would recreate that branch https://github.com/nhojpatrick/apache_commons-lang/pull/new/takari.maven-wrapper.
The PR if raised again, would include changes needed for github workflow, travis and Jenkinsfile, also documentation updates. You don't need to use mvnw if you are an advanced user with a specific use case and know what you're doing. But for 90% of use cases just saying use mvnw will be fine, advising mvnw won't stop you using mvn to perform builds. Everytime I install a new Java 15 or 16 EA version, and update my toolchains.xml, I normally delete both ~/.m2/wrapper and ~/.m2/repository at the same time so regularly spring clean. So I'll only have an old version of maven if I've needed to build an older branch which was designed to be used on an older maven. Most modern new CI's are creating slaves on demand per execution, so it won't slowly build up older maven wrapper versions like the old style jenkins slave. John On Wed, 19 Aug 2020 at 22:23, Gilles Sadowski <gillese...@gmail.com> wrote: > > Le mer. 19 août 2020 à 22:49, Gary Gregory <garydgreg...@gmail.com> a écrit : > > > > The consensus is do nothing IMO. > > "Those who do the work" etc. (see below). > > > > > What I really dislike is that if I have 20 components that over time end up > > containing 20 different versions of these Cmd/Sh/JavaSource/PropertiesFiles > > that point to 20 different versions of Maven, and I build everything, I'll > > end up with 20 different versions of Maven downloaded on my machine that I > > did not ask. > > That seems like "business as usual" for maven-based development... > But I'd tend to agree that it must at least be optional. > Is someone willing to demonstrate that it is so, i.e. make the > needed changes (for a single component)? > > Regards, > Gilles > > >>> [...] > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
