if I read correctly the dicussion on JEP 238 list, there was already someone who had such idea on more generic "multi-profile" JAR files, jdk being just one type of profile [1]
but that seems really complex for Maven, we have the classloader as Classworlds, then we could do what we want at this level. I'm not convinced this is a good thing to do, but at least we can do it at that level IMHO, we started maven-project-utils [2] but never released it: this shuld be the right place to do the job once, then let everybody use it as dependency without having a hard work to test every Maven version compatibility Regards, Hervé [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-February/031526.html [2] https://svn.apache.org/viewvc/maven/shared/trunk/maven-project-utils/ Le samedi 11 avril 2015 12:17:18 Robert Scholte a écrit : > A few weeks ago I came up with an additional idea and I'm sure we probably > all recognize this :) > MVJars should also cover dependencies. Several Maven plugins use > reflections to detect if they can use newer methods of of the Maven > Runtime. > In the end this code looks also like > if (isMaven331()) { > // M331 solution > } else { > // M221 solution > } > > Just like the JRE you have control over the compile-time > environment/dependencies, but not over the runtime > environment/dependencies. > > Robert > > Op Sat, 11 Apr 2015 11:21:28 +0200 schreef nicolas de loof > > <nicolas.del...@gmail.com>: > > This was part of the discussion we had with Brian, > > > > The need for "some way" to address multi-JDK target environment without > > just using the poorest API is a common thing for tools/framework/library > > developers. They use to rely on complex profile-based maven builds, > > hack-ish ant/gradle scripts, etc and produce -jdk6 / -jdk7 classified > > artifacts. This JEP offer a nice alternative, but this for sure only make > > sense if adopted by development tools. > > > > I thing Maven is the one who can help this being a success. If maven do > > support multi-version source directories, then for sure Idea will embrace > > this and Eclipse as well (but probably later #troll) > > > > In the meantime, lack of IDE support is for sure an issue. > > BUT considering JDK7/8/9 features are in most case encapsulated into some > > utility class which offer an alternate implementation on lower JDK, and > > this is not something you have to work on a daily basis, you can just > > configure IDE with the lowest JDK level and ignore errors in the java-7 / > > java-8 source tree which only contain some optimized code (or exclude > > from > > IDE), and (temporary) switch to higher JDK when you need to edit them. > > > > As Hervé said, the impact on compiler/jar/resource/surefire plugin has to > > be explored, but could probably be implemented today as a PoC with some > > dozen lines of plugin executions xml config. I plan to experiment with > > the > > runtime classloader which is able to load the adequate class file > > depending > > on runtime JDK to setup a demo. > > > > > > > > > > > > 2015-04-11 10:54 GMT+02:00 Kristian Rosenvold > > <kristian.rosenv...@gmail.com> > > > >> IDE support for multiple source trees seems quite far off ? > >> > >> 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/jav > >> 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/031461 > >> .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
