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

Reply via email to