Yes, it might be hard work, and yes, it implies discussions, and yes, currently only few people benefit from it.
But we need to understand to look on Maven from the side of Java 14 coders (and from day to day they will become more people): * Maven has default support for totally outdated Java version. * Maven has no native support for some Java 9 features (like this one). * Java 9 is around for many years. * The current LTS is Java 11, which is around for years, too. * To sum up: From the point of *modern* users, with every day of not supporting these features, Maven becomes more and more NOT the best choice for them. We should not further focus on making old things run better, but start investing in becoming the best build tool for Java 14 again. -Markus -----Ursprüngliche Nachricht----- Von: Robert Scholte [mailto:rfscho...@apache.org] Gesendet: Montag, 13. April 2020 21:39 An: dev@maven.apache.org Betreff: Re: AW: Maven intern projects the problem is that with every folder you'll need a separate execution-block of the maven-compiler-plugin. I've tried to solve within a single execution block, but that made it worse and impossible to manage. In the end having 1 execution block for every javac call makes sense. Multirelease jars are only interesting for libraries, I would not advice to do this for applications. So you might expect from library maintainer that they are experienced Java / Maven users, so I don't mind that they need to specify multiple execution blocks. https://github.com/metlos/multi-release-jar-maven-plugin was an attempt to do what you want: 1 execution block. However, he confirmed he did not solve the testing part. IF you want to solve this, you need to make clear separations of what should be solved by Maven and what by the maven-compiler-plugin: - Maven should make it possible to register multiple execution blocks by plugins *dynamically* (only the maven-compiler-plugin should be aware of all the source folders and the requirements per folder). It is really not that easy and the number of users will be low. I would invest in other issues. Robert On 13-4-2020 19:43:44, Markus KARG <mar...@headcrashing.eu> wrote: What users finally expect is to have multirelease JAR building being a Maven native functionality. This means, it should be as-easy-as putting code in these folders: src/main/java/9/ src/main/java/ src/main/java/11/ then perform mvn clean package to get a multi-release jar -- without *any* special switches, config, or POM.xml tweaking, and *all* maven-*-plugins will perform the necessary steps on their own (e. g. compiler runs multiple times as the compiler plugins knows this is needed when it sees /java/number/ folders). -Markus -----Ursprüngliche Nachricht----- Von: Elliotte Rusty Harold [mailto:elh...@ibiblio.org] Gesendet: Montag, 13. April 2020 19:02 An: Maven Developers List Betreff: Re: Maven intern projects On Mon, Apr 13, 2020 at 11:50 AM Robert Scholte wrote: > > Just to be clear: Multirelease jars is a JDK 9+ feature. With Maven it is > possible to make them, to test them and to run them. But they are pretty hard > to maintain. > So I would prefer NOT to try make Multirelease Jars of our libraries, unless > there's a very good reason. Yes, that's what I was thinking. Have we documented anywhere how to make multirelease jars with Maven? My impression from googling was that this doesn't work yet, but I guess that's not true? What improvements could we make to improve the workflow for multimodule builds? > If there is one thing that should be solved, but requires a lot of time, it > is support of ServicesLoaders > https://issues.apache.org/jira/browse/MNG-6275 > Thanks. I'll look at that. I did a review pass through the issue tracker. So far these are the ones I've found that look like they might make parts of plausible intern level projects: https://issues.apache.org/jira/browse/MDEP-644?jql=labels%20%3D%20intern -- 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 --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
