Same there while surefire/invoker runs respect supported versions. Le dim. 21 janv. 2024 à 22:04, Guillaume Nodet <gno...@apache.org> a écrit :
> At build time, I think it's fine to bump to whatever is needed to make > our life manageable. If 17 is required, so be it. > > Guillaume > > Le sam. 20 janv. 2024 à 19:18, Martin Desruisseaux > <martin.desruisse...@geomatys.com> a écrit : > > > > Hello > > > > I would like a little clarification about the Java version for Maven 4. > > I saw debate on this mailing list, but has a decision been reached? I > > got the impression that Maven 4 would require Java 11, but last time I > > checked, the pom.xml file was still declaring Java 8 as the target. If > > Java 11 is the target, updating the pom.xml would unlock some features > > and make some code a little bit simpler. > > > > Related question: even if Maven 4 targets Java 8 or 11, would it be > > acceptable to require Java 17 with `--release 8` or `--release 11` > > option only for Maven 4 compilation (not execution)? I ask because as > > far as I know, we cannot write code buildable with both Java 11 and Java > > 17 if the code uses HTML headings in Javadoc comments and the Javadoc > > checks are enabled. If the project builds on Java 11, then it fails on > > Java 17. Or if it builds on Java 17, then it fails on Java 11. For > > building on both versions, we must either avoid HTML headings, or > > disable Javadoc checks (more details at [1]). Using HTML headings is not > > very important, so they could be removed. But the `--release 11` > > approach would allow a more gradual transition to newest Java versions > > while preserving compatibility for users. > > > > Martin > > > > [1]https://github.com/apache/maven/pull/1378#issuecomment-1902173221 > > > > -- > ------------------------ > Guillaume Nodet > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
