I suspect that in the case of mvjars you will need to compile with J9
and
it will give you an option to down compile or J8.
It would not go lower than J8 as J7 is EOL in 2 weeks so they need only
support J8+ and when running on J8 an mvjar need only ignore all the
stuff
in META-INF, IOW the only JDK that needs to support loading classes
from
the alternative versions in a mvjar is J9
I don't see mvjar being workable for anything other than the core
JRE....
Otherwise it would need to store a matrix of dependency combinations:
* J8 with httpclient3 and log4j1.2
* J8 with httpclient4 and log4j1.2
* J8 with httpclient3 and log4j2.0
* J8 with httpclient4 and log4j2.0
* J9 with httpclient3 and log4j1.2
* etc
(Obviously this is less good of an example because for breaking API
changes, good libs change the package, but my point is you still need
to
matrix-explode all the dependency combos if you need to support a
certain
way of doing something if version 3+ of lib A and version 4+ of lib B
are
on the class path, plus variants of that)
I don't see that as a runner.
On Wednesday, April 15, 2015, Robert Scholte <rfscho...@apache.org>
wrote:
> WRT compiling: no, you should always try to compile with the target
JDK.
> My classic example:
> Suppose you have the following method in your code:
>
> public void check( String breathSpray )
> {
> if ( breathSpray.isEmpty() )
> {
> System.out.println( "Go to Quiki Mart" );
> }
> }
>
> You've set source+target to 1.5 and compile this code with JDK6.
Build
> success!
>
> Now I run this code with JDK5 and get:
java.lang.NoSuchMethodException:
> String.isEmpty()
>
> The problem is that this method was introduced with JRE6. When
compiling
> code, the compiler uses the JDK6 String, even though you had
specified
1.5
> as target.
>
> You could do a check afterwards with Animal Sniffer (if people are
aware
> of this tool), but it would have been better if the compiler had
failed.
>
> I don't expect this to change with newer versions of the JDK.
>
> WRT testing, I'm already working on this for the
maven-invoker-plugin,
but
> that's targeting Maven Runtime / JDK combination, but that made me
aware
> that I must think of a lot of the whole process.
>
> 1 module == 1 JDK source/target for compiling == 1 JDK source/target
for
> testing
>
>
> thanks,
> Robert
>
>
> Op Wed, 15 Apr 2015 20:14:11 +0200 schreef Arnaud Héritier <
> aherit...@gmail.com>:
>
> To compile classes for a mvjar I understand that we'll need only the
most
>> recent version (J9+) and with the right options (perhaps in several
calls)
>> it will do the job.
>> For tests (multi modules or several executions in one module) if you
>> really
>> want to test your code in a real situation you'll need to have
locally
all
>> the targeted JRE and use the JDK toolchain to use them.
>> WDYT ?
>>
>>
>> On Wed, Apr 15, 2015 at 8:07 PM, Robert Scholte
<rfscho...@apache.org>
>> wrote:
>>
>> I see comparison with an EAR, but instead of bundling artifacts,
you
>>> could
>>> unpack certain dependencies to the META-INF/java/x folder.
>>> What I like about this solution that it is very clear which
compiler
>>> version is used. Even if we are able to put all sources into 1
>>> MavenProject, it is still best to compile java5 source with JDK5,
java6
>>> sources with JDK6, etc.
>>> And what about unit testing? Test them with the whole range of
JDKs?
>>> Downside might be that with the multimodule solution you'll end up
with
>>> artifacts which should(?) never be installed/deployed, but should
only be
>>> bundled in the mvjar.
>>>
>>> Do we expect this to be THE new way of development or are these
still
>>> rare
>>> cases? If it is considered rare, then I don't mind offering a
multimodule
>>> solution, where every module does its less complex job very good.
>>>
>>> Robert
>>>
>>> Op Tue, 14 Apr 2015 17:39:56 +0200 schreef Paul Benedict <
>>> pbened...@apache.org>:
>>>
>>>
>>> In addition, even if IDEs were to support the MVJAR spec, that
doesn't
>>>
>>>> answer how Maven should natively answer the spec. Relying on IDE
support
>>>> isn't a good total answer, but it is a good complimentary answer.
Maven
>>>> just has to answer it with configuration and command line tooling
too.
>>>>
>>>>
>>>> Cheers,
>>>> Paul
>>>>
>>>> On Tue, Apr 14, 2015 at 10:14 AM, Carlos Sanchez
<car...@apache.org>
>>>> wrote:
>>>>
>>>> My 0.02
>>>>
>>>>>
>>>>> The current approach to use multiple modules, poms,... is a pita
and
>>>>> mvjar would fix that, while bringing new interesting problems
such
as
>>>>> testing the possible combinations. But that is ok.
>>>>>
>>>>> Lack of IDE support shouldn't stop us, if it is useful for maven
users
>>>>> that may push the IDEs
>>>>>
>>>>> If the Maven user wants to use mvjar by putting sources in
>>>>> src/main/java8 src/main/java9 or whatever convention we decide,
then
>>>>> the compiler, jar,... plugins should transparently handle all the
>>>>> necessary compilations and packaging without extra pom
configuration.
>>>>> If they decide to stick with multimodule, they can still do that.
>>>>>
>>>>> So if we are ok with the plugins recognizing these mvjar projects
then
>>>>> it is left for someone to implement some jira issues in the best
way
>>>>> possible while retaining backwards compatibility.
>>>>>
>>>>> Cheers
>>>>>
>>>>>
>>>>> On Tue, Apr 14, 2015 at 4:50 PM, Paul Benedict <
pbened...@apache.org>
>>>>> wrote:
>>>>> > I don't see this as "forcing" to create modules. This is
purely a
>>>>> packaging
>>>>> > issue, not a programming issue. Rather than providing distinct
jars
>>>>> per
>>>>> the
>>>>> > Java version you're targeting (which people have done for years
when
>>>>> > needed), you're just binding things up at the end. Forget this
is
>>>>> about
>>>>> the
>>>>> > MVJAR initiative because this is just how you would solve this
minus
>>>>> the
>>>>> > special packaging.
>>>>> >
>>>>> >
>>>>> > Cheers,
>>>>> > Paul
>>>>> >
>>>>> > On Tue, Apr 14, 2015 at 5:53 AM, Stephen Connolly <
>>>>> > stephen.alan.conno...@gmail.com> wrote:
>>>>> >
>>>>> >> Actually this is worse. This would be Maven forcing us to
create
>>>>> modules
>>>>> >> because IDEs do not support different JDK levels for source
code
>>>>> paths
>>>>> in
>>>>> >> the one module
>>>>> >>
>>>>> >> On 14 April 2015 at 09:32, Arnaud Héritier
<aherit...@gmail.com>
>>>>> wrote:
>>>>> >>
>>>>> >> > 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-unsubscribe@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
>>>>> >> >
>>>>> >>
>>>>>
>>>>>
---------------------------------------------------------------------
>>>>> 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
>
>
--
Sent from my phone
