On Tue, Apr 14, 2015 at 8:29 AM, Hervé BOUTEMY <herve.bout...@free.fr> wrote:
> Le lundi 13 avril 2015 12:19:57 Paul Benedict a écrit : > > 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. > like Gary answered, I think that it'll be better if we stick with java#, > or j# > > And in this example, we'll require another module for the mvjar, that will > combine result fo every other module > I really hate when maven enforces us to create modules for its own technical reasons. (And I know I'm not the only one) > > > > > 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. > after thinking at it, true > this module layout is definitely really clear, that's a big advantage! > one thing that it makes really clear is javadoc, too, since javadoc in a > mv- > module is a challenge :) > > we should try it with plexus-utils, in another branch > > > > > 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). > IMHO, not really, since the minimum version module will contain absolutely > every classes, but the other modules will contain only a few classes = the > few > code that is rewritten to take advantage of newer JDK > > Compatibility with old jdks that do not support mvjar is built into mvjar > JEP: > a JVM that does not support mvjar extension will see minimum version > modules > (and useless content in /META-INF/versions/) > > notice that every module will ave its own GAV coordinates: the last mvjar > module will have the end-user coordinates, where every JDK-version-specific > module will have an artifactId = artifactId-java# (that's a generic > convention > we should try to push forward) > > > 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. > I don't know if the merging will require a dedicated packaging: we'll see > later > > now it's time to test on plexus-utils: givent this idea doesn't involve > much > new things in maven, I'm pretty sure we can make it full functional! > > I'll try to do it tonight if nobody beats me at it > > Regards, > > Hervé > > > > > > > > > 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 > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > > -- ----- Arnaud Héritier http://aheritier.net Mail/GTalk: aheritier AT gmail DOT com Twitter/Skype : aheritier
