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/java-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