afaik netbeans does support it (having different source/target level for test and main source) Not from the UI, but if you have your compiler plugin setup properly, it will take it into account.
Milos On Sat, Apr 11, 2015 at 11:35 PM, Kristian Rosenvold < kristian.rosenv...@gmail.com> wrote: > 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, but also like a great can of worms > :) I assume minimum compiler requirement would be java-8 for a project > with src/main/java-8 ? > > 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/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 > >
