It's been a minor struggle to get components to Java 8, despite my efforts. Java 11 is a ways off especially since not all platforms support it yet (IBM iSeries IIRC, which matters to me).
I'm all for getting all of Commons to Java 8. Gary On Thu, Oct 15, 2020, 10:57 John Patrick <nhoj.patr...@gmail.com> wrote: > Circa 2016 or 2017 I was trying to get commons projects ready for java > 9, so trying to get Automatic-Module-Name added into the manifest. > Moved onto other non commons projects for 2018 and 2019, helped with > modules and jupiter upgrades. > End of 2019 most of the java 9 work on other projects was blocked as > everything had dependencies on commons projects before they could be > true java 9+ modules projects. > Attempt to suggest a commons roadmap towards Java 11 as min version, > i.e. release current code at current version, bump to 1.8 and release > by end of 2020 say. Bump to Java 11 and release by mid 2021. So for a > year or 2 some projects might have multiple active master branches, so > if people do need commons-X on jdk 1.6 it is supported, but if no one > reports any issues it's maybe closed at the end of 2022. > Start of this year, try sorting out missing .gitignore and getting > them more standard, as some have target/ others /target/ others > **/target others **/target/. Upgrade to hamcrest v2.x. Move from junit > v4.x to junit-vintage v5.x and add junit-jupiter so dual support. Move > tests to junit jupiter classes. Upgrade maven dependencies/plugins to > latest versions. Look at adding using toolchain to select the jdk > instead of using the environment version. > Adding mvnw in prep for maven 3.7.0 which will have it now as part of > core maven instead of takari mvnw. So the project controls the maven > version, and when to upgrade. > I was going to start suggesting looking at moving commons-* to > org.apache.commons groupId so all are standard. Also how commons-lang3 > does it's packages so commons-lang and also be a dependency and have > different packages so they don't clash. But held off... > > Hope that gives an insight into my history with commons... some are > emails, some are jira tickets conversions, some are github > conversations. > > My goal is to get commons upgrade to jpms, so the downstream projects > I help out in 2018/2019 can upgrade and do a final jdk 1.8 release and > move onto jdk 11. > > So pr's for junit assertThrows I think are all done for > commons-collections, commons-digester and commons-validator. > > Will look at vfs and maybe also rng regarding tidying up the tests etc. > > John > > On Thu, 15 Oct 2020 at 13:06, Gilles Sadowski <gillese...@gmail.com> > wrote: > > > > Hello. > > > > Le mer. 14 oct. 2020 à 21:41, John Patrick <nhoj.patr...@gmail.com> a > écrit : > > > > > > before i waste time looking at upgrading tests... > > > > > > any objections if i upgrade tests to use assertAll and assertThrows > > > introduced in JUnit jupiter? > > > > > > I see it as less tech debt removal and I'm happy to spend time doing > > > the upgrade which I've done from maybe several projects now. Just > > > don't want to get to raising PR and them being rejected, which I feel > > > happens with everything I try to help out with related to commons > > > projects at the moment... > > > > I did notice that (or forgot it). Could you please remind of what you've > > proposed? > > > > AFAICT, the main contributors to > > Commons Math > > Commons Numbers > > Commons Statistics > > Commons Geometry > > Commons RNG > > are glad to keep in line with the evolution of the best Java practices. > > Except for [RNG], which requires Java 1.6, all the above components > > are at Java 8. > > > > If you are into improving our testing suites, please note that help > > would be welcome in ironing out issues in Commons Math, where > > sometimes (but too often) the use of "randomly" generated data > > with a *fixed seed* hides the fact that the test actually fails for most > > input (i.e. data generated from another seed). > > > > > > Thanks, > > 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 > >
