FWIW, I do not like 'minjava'. OTOH 'java7' is clear, not why not just stick to 'java#'?
Gary On Mon, Apr 13, 2015 at 10:19 AM, Paul Benedict <pbened...@apache.org> wrote: > This is the example project structure I had in mind: > > mvjar-example/ > minjava/ > src/main/java > src/test/java > java7/ > src/main/java > src/test/java > java8/ > src/main/java > src/test/java > > The "minjava" and "java7" and "java8" are not special names (just names to > denote what kind of Java source is inside). As Herve noted, "minjava" would > contain the source minimum Java version; "java7" would contain the java > 7-specific sources, and "java8" would contain the java 8-specific sources. > > I don't see any added difficulty with regard to testing. If you already > have code that tests a specific Java X version, just extract that into its > own test case file and place it in the appropriate project. At most all > you're doing is minor refactoring. > > This will create three JARs of course (or at least today). I don't see that > as a big deal since authors may decide to distribute this way where MVJAR > isn't supported (like pre-Java 9 JVMs). However, if we can bind up all the > jars into one in a post-processing phrase, you can then meet the MVJAR > specification. > > PS: I really don't know if an "mvjar" type is necessary. Honestly, I hope > it's not. I thought it was needed in the beginning, but am not sure > anymore. Opinions appreciated. > > > > Cheers, > Paul > > On Mon, Apr 13, 2015 at 1:28 AM, nicolas de loof <nicolas.del...@gmail.com > > > wrote: > > > 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 > > > > > > > > > -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org Java Persistence with Hibernate, Second Edition <http://www.manning.com/bauer3/> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> Spring Batch in Action <http://www.manning.com/templier/> Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory
