Gary, I made a point in my email to note these aren't special names. These are just example names to denote what kind of project material was inside.
Cheers, Paul On Mon, Apr 13, 2015 at 12:53 PM, Gary Gregory <garydgreg...@gmail.com> wrote: > 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 >
