IDE support for multiple source trees seems quite far off ?
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/java-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-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
