maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hervé BOUTEMY <herve.bout...@free.fr>
Subject Re: [DISCUSSION] JEP 238: Multi-Version JAR Files
Date Sat, 11 Apr 2015 14:06:08 GMT
if I read correctly the dicussion on JEP 238 list, there was already someone 
who had such idea on more generic "multi-profile" JAR files, jdk being just one 
type of profile [1]

but that seems really complex

for Maven, we have the classloader as Classworlds, then we could do what we 
want at this level. I'm not convinced this is a good thing to do, but at least 
we can do it at that level

IMHO, we started maven-project-utils [2] but never released it: this shuld be 
the right place to do the job once, then let everybody use it as dependency 
without having a hard work to test every Maven version compatibility

Regards,

Hervé


[1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-February/031526.html

[2] https://svn.apache.org/viewvc/maven/shared/trunk/maven-project-utils/

Le samedi 11 avril 2015 12:17:18 Robert Scholte a écrit :
> A few weeks ago I came up with an additional idea and I'm sure we probably
> all recognize this :)
> MVJars should also cover dependencies. Several Maven plugins use
> reflections to detect if they can use newer methods of of the Maven
> Runtime.
> In the end this code looks also like
>       if (isMaven331()) {
>         // M331 solution
>       } else {
>         // M221 solution
>       }
> 
> Just like the JRE you have control over the compile-time
> environment/dependencies, but not over the runtime
> environment/dependencies.
> 
> Robert
> 
> Op Sat, 11 Apr 2015 11:21:28 +0200 schreef nicolas de loof
> 
> <nicolas.deloof@gmail.com>:
> > This was part of the discussion we had with Brian,
> > 
> > The need for "some way" to address multi-JDK target environment without
> > just using the poorest API is a common thing for tools/framework/library
> > developers. They use to rely on complex profile-based maven builds,
> > hack-ish ant/gradle scripts, etc and produce -jdk6 / -jdk7 classified
> > artifacts. This JEP offer a nice alternative, but this for sure only make
> > sense if adopted by development tools.
> > 
> > I thing Maven is the one who can help this being a success. If maven do
> > support multi-version source directories, then for sure Idea will embrace
> > this and Eclipse as well (but probably later #troll)
> > 
> > In the meantime, lack of IDE support is for sure an issue.
> > BUT considering JDK7/8/9 features are in most case encapsulated into some
> > utility class which offer an alternate implementation on lower JDK, and
> > this is not something you have to work on a daily basis, you can just
> > configure IDE with the lowest JDK level and ignore errors in the java-7 /
> > java-8 source tree which only contain some optimized code (or exclude
> > from
> > IDE), and (temporary) switch to higher JDK when you need to edit them.
> > 
> > As Hervé said, the impact on compiler/jar/resource/surefire plugin has to
> > be explored, but could probably be implemented today as a PoC with some
> > dozen lines of plugin executions xml config. I plan to experiment with
> > the
> > runtime classloader which is able to load the adequate class file
> > depending
> > on runtime JDK to setup a demo.
> > 
> > 
> > 
> > 
> > 
> > 2015-04-11 10:54 GMT+02:00 Kristian Rosenvold
> > <kristian.rosenvold@gmail.com>
> > 
> >> IDE support for multiple source trees seems quite far off ?
> >> 
> >> 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/jav
> >> 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/031461
> >> .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


Mime
View raw message