Le lun. 22 janv. 2024 à 09:52, Hervé Boutemy <herve.bout...@free.fr> a écrit : > > Le dimanche 21 janvier 2024, 22:03:59 CET Guillaume Nodet 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. > +1 > > my biggest concern with Maven 4 is not JDK runtime requirement, but plugins > future when a plugin wants to be able to use the new Maven 4 API > > IIUC, Maven 4 has a compatibility layer to run Maven Plugin 3.x (= built with > Maven 3 plugin API). > On our core plugins, there is a Maven 4 branch that tests what the plugin > would become when it migrates to new Maven 4 API (and check that Maven 4 API > works as expected) > > But IIUC, once a plugin uses Maven 4 API, it de-facto cannot be run on Maven 3 > > Questions: > - is that true at plugin level or goal level?
It has to be at the plugin level. The main reason is that all goals share the same classloader and the rules to build the classloader will very probably change between the Maven 3 API and the Maven 4 API, as the Maven 4 API should provide a much smaller class loader than the current one. See https://issues.apache.org/jira/browse/MNG-7955 > - new Maven 4 API for now is not so much about providing new features, but > improving/clarifying plugin expectations from Maven core: are there known > features in Maven 4 API not available in Maven 3 that would bring stronger > interest in writing a goal for Maven 4? > > concern: does it mean that we either should not upgrade our master branches to > Maven 4 API too early? Will we need to maintain a 3.x branch in parallel to 4/ > main branch? > And the questions I have for plugins maintained at Maven project level will > impact every third party plugin maintainer: we need to make things explicit, > IMHO > The JVM upgrade in parallel IMHO is less a concern, as it is a consequence of > previous plugin prerequisite choice on Maven > > Hervé > > > > > 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 > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > -- ------------------------ Guillaume Nodet --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
