Yes it is exactly the option Brian presented to us. For me (perhaps it's name is misleading) the -platform is the option that allows to compile mvjars (partial code on top of default one). But I agree that it's not clear the relationship/constraint/control between source/target/platform
On Thu, Apr 16, 2015 at 6:53 PM, Robert Scholte <[email protected]> wrote: > Today I received this message from the core-libs-dev mailing list by > Joseph D. Darcy > > {quote} > Note that one possible feature of JDK 9 is a -platform N option to javac > which would allow compiling against older versions of the platform > libraries: > > JEP draft: Compile for Specific Platform Version > http://openjdk.java.net/jeps/8058150 > > This feature would address some of the concerns raised below. > > -Joe > {quote} > > You might wonder why there's a need for an extra argument, whereas > everybody would expect that source/target 1.5 implies -platform 1.5 > > Robert > > Op Wed, 15 Apr 2015 22:16:48 +0200 schreef Arnaud Héritier < > [email protected]>: > > > 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 <[email protected]> >> 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 < >>> [email protected]> 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 <[email protected]> >>>> 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 < >>>> > [email protected]>: >>>> > >>>> > 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 < >>>> [email protected]> >>>> >> 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 < >>>> >>> [email protected]>: >>>> >>> >>>> >>> >>>> >>> 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 < >>>> [email protected]> >>>> >>>> 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 < >>>> [email protected]> >>>> >>>>> 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 < >>>> >>>>> > [email protected]> 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 < >>>> [email protected]> >>>> >>>>> wrote: >>>> >>>>> >> >>>> >>>>> >> > On Tue, Apr 14, 2015 at 8:29 AM, Hervé BOUTEMY < >>>> >>>>> [email protected] >>>> >>>>> > >>>> >>>>> >> > 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 < >>>> >>>>> >> > > [email protected]> >>>> >>>>> >> > > > >>>> >>>>> >> > > > 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 < >>>> >>>>> [email protected] >>>> >>>>> >: >>>> >>>>> >> > > > > > 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 < >>>> >>>>> >> > > [email protected]> >>>> >>>>> >> > > > > > > >>>> >>>>> >> > > > > > > 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 < >>>> >>>>> >> > > [email protected]>: >>>> >>>>> >> > > > > > > > > > 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 < >>>> >>>>> >> > > [email protected] >>>> >>>>> >> > > > > > > > > >> >>>> >>>>> >> > > > > > > > > >> > 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: >>>> >>>>> >> > [email protected] >>>> >>>>> >> > > > > > > > > >> >> For additional commands, e-mail: >>>> >>>>> >> > > [email protected] >>>> >>>>> >> > > > > > > > >>>> >>>>> >> > > > > > > > >>>> >>>>> >> > > ------------------------------ >>>> ------------------------------ >>>> >>>>> -------- >>>> >>>>> >> > > > > > > > - >>>> >>>>> >> > > > > > > > >>>> >>>>> >> > > > > > > > > >> > To unsubscribe, e-mail: >>>> >>>>> >> > [email protected] >>>> >>>>> >> > > > > > > > > >> > For additional commands, e-mail: >>>> >>>>> >> > > [email protected] >>>> >>>>> >> > > > > > >>>> >>>>> >> > > > > > >>>> >>>>> >> > ------------------------------------------------------------ >>>> >>>>> --------- >>>> >>>>> >> > > > > > >>>> >>>>> >> > > > > > > > > >> To unsubscribe, e-mail: >>>> >>>>> >> [email protected] >>>> >>>>> >> > > > > > > > > >> For additional commands, e-mail: >>>> >>>>> >> > [email protected] >>>> >>>>> >> > > > > > >>>> >>>>> >> > > > > > >>>> >>>>> >> > ------------------------------------------------------------ >>>> >>>>> --------- >>>> >>>>> >> > > > > > >>>> >>>>> >> > > > > > > > > > To unsubscribe, e-mail: >>>> >>>>> [email protected] >>>> >>>>> >> > > > > > > > > > For additional commands, e-mail: >>>> >>>>> >> [email protected] >>>> >>>>> >> > > > > >>>> >>>>> >> > > > > >>>> >>>>> >> ------------------------------------------------------------ >>>> >>>>> --------- >>>> >>>>> >> > > > > >>>> >>>>> >> > > > > > > > > To unsubscribe, e-mail: >>>> >>>>> [email protected] >>>> >>>>> >> > > > > > > > > For additional commands, e-mail: >>>> >>>>> [email protected] >>>> >>>>> >> > > > > > > > >>>> >>>>> >> > > > > > > > >>>> >>>>> >> > > ------------------------------ >>>> ------------------------------ >>>> >>>>> -------- >>>> >>>>> >> > > > > > > > - >>>> >>>>> >> > > > > > > > To unsubscribe, e-mail: >>>> [email protected]. >>>> >>>>> org >>>> >>>>> >> > > > > > > > For additional commands, e-mail: >>>> >>>>> [email protected] >>>> >>>>> >> > > > > > >>>> >>>>> >> > > > > > >>>> >>>>> >> > ------------------------------------------------------------ >>>> >>>>> --------- >>>> >>>>> >> > > > > > To unsubscribe, e-mail: >>>> [email protected] >>>> >>>>> >> > > > > > For additional commands, e-mail: >>>> >>>>> [email protected] >>>> >>>>> >> > > >>>> >>>>> >> > > >>>> >>>>> >> > > >>>> >>>>> >>>> --------------------------------------------------------------------- >>>> >>>>> >> > > To unsubscribe, e-mail: [email protected] >>>> >>>>> >> > > For additional commands, e-mail: [email protected] >>>> >>>>> >> > > >>>> >>>>> >> > > >>>> >>>>> >> > >>>> >>>>> >> > >>>> >>>>> >> > -- >>>> >>>>> >> > ----- >>>> >>>>> >> > Arnaud Héritier >>>> >>>>> >> > http://aheritier.net >>>> >>>>> >> > Mail/GTalk: aheritier AT gmail DOT com >>>> >>>>> >> > Twitter/Skype : aheritier >>>> >>>>> >> > >>>> >>>>> >> >>>> >>>>> >>>> >>>>> >>>> --------------------------------------------------------------------- >>>> >>>>> To unsubscribe, e-mail: [email protected] >>>> >>>>> For additional commands, e-mail: [email protected] >>>> >>>>> >>>> >>>>> >>>> >>>>> >>>> --------------------------------------------------------------------- >>>> >>> To unsubscribe, e-mail: [email protected] >>>> >>> For additional commands, e-mail: [email protected] >>>> >>> >>>> >>> >>>> >>> >>>> >> >>>> > --------------------------------------------------------------------- >>>> > To unsubscribe, e-mail: [email protected] >>>> > For additional commands, e-mail: [email protected] >>>> > >>>> > >>>> >>>> -- >>>> Sent from my phone >>>> >>>> >>> >>> >>> -- >>> ----- >>> Arnaud Héritier >>> http://aheritier.net >>> Mail/GTalk: aheritier AT gmail DOT com >>> Twitter/Skype : aheritier >>> >>> >> >> > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > -- ----- Arnaud Héritier http://aheritier.net Mail/GTalk: aheritier AT gmail DOT com Twitter/Skype : aheritier
