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-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 > >> > > > >> > > > >> > > >> > > >> > -- > >> > ----- > >> > 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 > >
