Le samedi 11 avril 2015 21:42:50 Paul Benedict a écrit : > I've been giving this subject lots of thought in some of spare time. IMO, > the most straightforward way of meeting the requirement of the MVJAR is to > break up one's JAR project into separate modules. One module would contain > the version independent code, and then other modules would be per Java > version. more precisely: the first module would contain the source for minimum Java version: sometimes, it will contain code that won't run with later JRE
> This kind of slicing is necessary because you do need different > kinds of compiler directives (like -source), different JREs to run unit > tests differently, and most importantly, the different JREs to allow > debugging according to the Java version you want to test. > > The other piece that doesn't yet exist is a way to bundle the modules into > one jar. Perhaps this can be accomplished by introducing a new "mvjar" > Maven type. I didn't imagine this scenario: no Maven plugins updates nor IDE, "just" a new feature to merge multiple modules into on MV jar interesting idea, in fact: this would seriously reduce the impact on tooling, even if the result is less compact, ie creates a lot of Maven modules and I am wondering what unit tests will look like for additional versions: the good thing is that they can be tweaked easily. Then bad thing is that we may end up in copy/pasting them Regards, Hervé > > Paul > > > Cheers, > Paul > > On Sat, Apr 11, 2015 at 9:37 AM, Hervé BOUTEMY <herve.bout...@free.fr> > > wrote: > > Le samedi 11 avril 2015 15:35:02 Kristian Rosenvold a écrit : > > > Technically we support "main" scoped sources in java6 and "test" > > > scoped sources in java7 today, but the feature is largely unusable > > > since IDE support is totally missing. Even IntelliJ does not support > > > it (https://youtrack.jetbrains.com/issue/IDEA-85478 and other issues) > > > > > > :( > > > > > > There might be some hope of gaining some kind of traction to both > > > source and main-level support of multi-language-level modules. Maybe > > > something like (src/main/java and src/test/java = "default language" > > > level) while src/[main|test]/java-8 would be a specific language > > > level. This sounds infinitely cool, > > > > yes, that's what I did in plexus-utils jdep-238 branch > > https://github.com/codehaus-plexus/plexus-utils/tree/jep-238/src/main > > > > > but also like a great can of worms > > > > > > :) > > > > yes, I fear it's not so easy for IDEs... > > > > > I assume minimum compiler requirement would be java-8 for a project > > > > > > with src/main/java-8 ? > > > > yes, I think that's what makes such support hard at the moment: require > > the > > highest JDK, and signature for every lower JDK to avoid newer APIs > > unless JDK 9 can safely compile for any older target, checking the API > > (without having to run Animal Sniffer after that) > > > > Regards, > > > > Hervé > > > > > K > > > > > > 2015-04-11 15:11 GMT+02:00 Hervé BOUTEMY <herve.bout...@free.fr>: > > > > Le samedi 11 avril 2015 10:54:34 Kristian Rosenvold a écrit : > > > >> IDE support for multiple source trees seems quite far off ? > > > > > > > > IDE support for current situation, where we mix multiple Java API > > > > versions > > > > > > in one single source tree, is even more far off! > > > > > > > > With separate source trees, IDE support starts like we are at the > > > > moment = > > > > > > no IDE support > > > > > > > > but IDEs that want to do something about it have a chance: that's the > > > > big > > > > > > difference IMHO > > > > > > > > Regards, > > > > > > > > Hervé > > > > > > > >> Kristian > > > >> > > > >> 2015-04-11 8:51 GMT+02:00 Hervé BOUTEMY <herve.bout...@free.fr>: > > > >> > Hi, > > > >> > > > > >> > Yesterday at DevoxxFR, Carlos Sanchez, Arnaud Héritier, Nicolas de > > > > Loof > > > > > >> > and me met Brian Goetz and discussed about the objective of JEP 238 > > > > and > > > > > >> > what we could get from such a feature. > > > >> > > > > >> > Having a face to face explanation in front of a white board gave > > > >> > interesting ideas: then, *as library maintainer*, I tried to > > > >> > modifiy > > > >> > plexus-utils code to use MVJAR for Java 7 enhancement that are > > > >> > currently > > > >> > triggerred through reflection > > > >> > > > > >> > > > > >> > Here is the result [1]: > > > >> > > > > >> > I extracted 2 little xxxMv classes containing only the few methods > > > > that > > > > > >> > had to be enhanced when runing on Java 7, replacing the > > > >> > > > > >> > if (Java7Detector.isJava7()) { > > > >> > > > > >> > // java 7 > > > >> > > > > >> > } else { > > > >> > > > > >> > // Java 5 > > > >> > > > > >> > } > > > >> > > > > >> > stanza with the default Java 5 code in the main src/main/java > > > >> > source > > > >> > tree > > > >> > and Java 7 reimplementation in src/main/java-7 source tree > > > >> > > > > >> > and I did cleanup: removed Java7Detector and moved NioFiles to this > > > >> > java-7 > > > >> > specific source tree > > > >> > > > > >> > > > > >> > the result is a main src/main/java source tree that can be compiled > > > >> > with > > > >> > JDK 5 and a src/main/java-7 source tree that is minimal to be > > > > compiled > > > > > >> > with JDK 7 > > > >> > > > > >> > > > > >> > I still didn't try to update pom.xml to see what > > > > maven-compiler-plugin > > > > > >> > and > > > >> > maven-jar-plugin configurations could look like. > > > >> > > > > >> > and I don't know if javac will be enhanced to do the 2 compilations > > > > in > > > > > >> > 1 > > > >> > command like "javac -target 1.5 src/main/java -target 1.7 > > > >> > src/main/java-7" > > > >> > or if it'l have to launch 2 javac one after the other > > > >> > > > > >> > I didn't look at maven-jar-plugin to see if it uses "jar" command > > > > that > > > > > >> > will be enhanced to mix multiple target/classes or if it uses > > > > JarFile > > > > > >> > class then will need to code the mix > > > >> > > > > >> > and I don't know if javac will have tru crossplatform compilation > > > >> > option, > > > >> > to avoid using 2 JDKs (ie JDK 5 for compiling java 5 code and being > > > >> > sure > > > >> > there is no Java 7 API reference, and JDK 7 for the java 7 part) > > > >> > > > > >> > > > > >> > I see there will be impact on tooling, and if javac does a part of > > > > the > > > > > >> > job, > > > >> > this will be a lot easier to implement at Maven level > > > >> > > > > >> > > > > >> > But at the moment, my objective was not from Maven point of view > > > >> > but > > > >> > library developper point of view: show a real world case of how an > > > >> > existing library could be refactored to use the feature, expecting > > > > that > > > > > >> > the new source code would be easier to maintain > > > >> > > > > >> > > > > >> > WDYT? > > > >> > > > > >> > Regards, > > > >> > > > > >> > Hervé > > > >> > > > > >> > > > > >> > > > > >> > > > > >> > [1] > > > > https://github.com/codehaus-plexus/plexus-utils/tree/jep-238/src/main/j > > > > > >> > av > > > >> > a-7/org/codehaus/plexus/util> > > > >> > > > > >> > Le jeudi 19 mars 2015 23:38:32 Robert Scholte a écrit : > > > >> >> Hi, > > > >> >> > > > >> >> we've been asked to give our opinion on the JEP 238: Multi-Version > > > > JAR > > > > > >> >> Files > > > >> >> > > > >> >> Here's a quote from Rory O'Donnels e-mail: > > > >> >> --- > > > >> >> > > > >> >> It's goal is to extend the JAR file format to allow multiple, > > > >> >> JDK > > > >> >> > > > >> >> release-specific versions of class > > > >> >> > > > >> >> files to coexist in a single file. An additional goal is to > > > > backport > > > > > >> >> the > > > >> >> > > > >> >> run-time changes to > > > >> >> > > > >> >> JDK 8u60, thereby enabling JDK 8 to consume multi-version JARs. > > > > For > > > > > >> >> a > > > >> >> > > > >> >> detailed discussion, > > > >> >> > > > >> >> please see the corresponding thread on the core-libs-dev mailing > > > >> >> list. > > > >> >> [1] > > > >> >> > > > >> >> Please keep in mind that a JEP in the Candidate state is merely > > > > an > > > > > >> >> idea > > > >> >> > > > >> >> worthy of consideration > > > >> >> > > > >> >> by JDK Release Projects and related efforts; there is no > > > > commitment > > > > > >> >> that > > > >> >> > > > >> >> it will be delivered in > > > >> >> > > > >> >> any particular release. > > > >> >> > > > >> >> Comments, questions, and suggestions are welcome on the > > > > corelibs-dev > > > > > >> >> mailing list. (If you > > > >> >> > > > >> >> haven’t already subscribed to that list then please do so first, > > > >> >> > > > >> >> otherwise your message will be > > > >> >> > > > >> >> discarded as spam.) > > > >> >> > > > >> >> [0] http://openjdk.java.net/jeps/238 > > > >> >> [1] > > > > http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-February/031 > > > > > >> >> 461 > > > >> >> .ht ml > > > >> >> > > > >> >> --- > > > >> >> > > > >> >> IIUC the original request was to have different version of the > > > >> >> same > > > >> >> class > > > >> >> within the same artifact. On the mailinglist I noticed a more > > > >> >> interesting > > > >> >> idea: you need a mechanism to map Classes, Methods or Fields from > > > > one > > > > > >> >> version to the other. > > > >> >> > > > >> >> From a Maven perspective I don't see that much issues with the > > > >> >> original > > > >> >> > > > >> >> idea. You should already be able to do it right now with a lot of > > > >> >> execution-blocks. > > > >> >> However, I don't see how users would maintain different version of > > > > the > > > > > >> >> same class (within an IDE). > > > >> >> To me this all looks quite complex for rare cases. > > > >> >> If you really want multiple JDK versions of the same artifact, I > > > > would > > > > > >> >> probably split them into classified artifacts. > > > >> >> > > > >> >> Any other comments? > > > >> >> > > > >> >> thanks, > > > >> >> Robert > > > > --------------------------------------------------------------------- > > > > > >> >> 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 > > > > > > > > --------------------------------------------------------------------- > > > > 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 --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org