I expect we could run the unit test suite on JDK 6 / 7 / 8 in parallel with 7/8 specific code being used for the JDK that do support them, so I wonder such a multi-module setup would work in this scenario, or would need yet another maven module for tests :'(
2015-04-12 23:33 GMT+02:00 Hervé BOUTEMY <herve.bout...@free.fr>: > 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 > >
