>>So, we can try to have different source folders for different runtimes. No. If you are developers you would not say this. No developer would develop and merge the same code multiple times!!! Look, now let the maven-compiler-plugin to download jars of the same artifact which was released for Version 1.7 and 1.8, and now let the compiler wrap those two versions with current version 1.9 which is ready to be released. Now you have fat jar MRjar. This means any Java version of the artifact can be chosen on the top of JDK9.
>>Most other plugins would need to be executed for each version as well - >>javadoc, junit No. because the previous Versions were already tested and processed. >>Again if they *don't* need a separate execution, then why is MRJar needed? Exactly, and now I cannot imaging company which is going to complicate their project with a stupid MRJar and why so if they have WildFly 8.2.1 which supports Java 8 do you think they EE project would struggle with MRJar? Of course not. If they have WildFly 10.x supporting Java 9 then again no developer would build MRJar. I think MRJar is suitable only for JDK internals and it is only because of Oracle has problem with JCP because JCP does not let Oracle to break backwards compatibility and introduce dynamic language features. So Oracle is trying for compromise. Oracle is trying to let you build java.* JDK with javac, interchange internal modules, etc. Nothing for other non-JDK projects. -- Cheers Tibor --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
