Here is what Brian gave to us :
{quote}
I’ve attached the (unreviewed) patch that is slated for Java 8 — this is
the runtime-only, with no dev tools support (e.g., jar, jar signer,
compiler.) So it will let you RUN with an mvjar. I can send you the 9
patch as well if you like. Usual disclaimer — no guarantees, blah blah
blah. You can create an mvjar with an unmodified JAR tool just by laying
out the files appropriately in the file system (eg., with a
META-INF/versions dir.)
{quote}
https://dl.dropboxusercontent.com/u/501043/webrev.zip
With this J8 patch yo should be able to have a working runtime but for the
build tool we have to hack with several manual compilations
On Wed, Apr 15, 2015 at 10:09 PM, Arnaud Héritier <aherit...@gmail.com>
wrote:
> Clearly Brian told us that the goal was only to cover the needs at the
> core JRE level.
> They don't want (at least now) to offer such feature for something else.
> I think it is really a change of mindset compared to few years ago when
> they wanted to build a solution that may cover many many needs.
> Nowadays they want before all to cover the need for JRE core and only for
> it if necessary (modularity, multi versions jars, ...)
>
>
> On Wed, Apr 15, 2015 at 9:45 PM, Stephen Connolly <
> stephen.alan.conno...@gmail.com> wrote:
>
>> 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
>>
>
>
>
> --
> -----
> Arnaud Héritier
> http://aheritier.net
> Mail/GTalk: aheritier AT gmail DOT com
> Twitter/Skype : aheritier
>
--
-----
Arnaud Héritier
http://aheritier.net
Mail/GTalk: aheritier AT gmail DOT com
Twitter/Skype : aheritier
