maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From nicolas de loof <nicolas.del...@gmail.com>
Subject Re: [DISCUSSION] JEP 238: Multi-Version JAR Files
Date Mon, 13 Apr 2015 06:28:43 GMT
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.boutemy@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.boutemy@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.boutemy@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.boutemy@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-unsubscribe@maven.apache.org
> > > > >> >> For additional commands, e-mail: dev-help@maven.apache.org
> > >
> > > ---------------------------------------------------------------------
> > >
> > > > >> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > >> > For additional commands, e-mail: dev-help@maven.apache.org
> > > > >>
> > > > >>
> ---------------------------------------------------------------------
> > > > >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > >> For additional commands, e-mail: dev-help@maven.apache.org
> > > > >
> > > > >
> ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > For additional commands, e-mail: dev-help@maven.apache.org
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: dev-help@maven.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message