2016-08-31 22:02 GMT+02:00 Tibor Digana <[email protected]>:
> >>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. > That's a bit off-topic, as this thread is about the _how_ and not the _why_, but I'd like to point out that I disagree with you here ;). MRJars would be great for a lot of frameworks and libraries that you would _use_ in your end-product. Frameworks that offer different alternatives or extended features requiring a newer JDK now have to build and maintain artifacts either with different versions or with different artifactIds (e.g. funky-annotations and funky-annotations-jdk8, where the -jdk8 variant contains annotations with @Repeatable) -- there are a lot of examples out there. And that's not only cumbersome for maintainers, but also for users (which is the bad thing). So go MRjars! Making them easily consumable for users is the top-prirority and it looks like a solid approach. Making them easy to build for the maintainers is way less important (as that's only a tiny percentage of the maven-users out there), but it sure needs to work with different IDEs and especially Eclipse would have problems handling different target JDKs in the same project. So for me as an Eclipse user, I'd have to take the road with the multi-module projects. But that's okay, as I'm just building a framework and separating the different variants for different JDKs has also a lot of benefits, as already described above: testing, generating javadocs, and all that other stuff is already there and can be used without having to change anything. For me, a project collecting the internally seperate artifacts and combining them into an MRjar would be totally fine. Andreas > > -- > Cheers > Tibor > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
