Richart, >>couple features of Java8 which I've avoided adding because of needing backward compatibility. If I have to decide where my time goes, then I would rather keep Java 6 in source code and make s/w more stable improving architecture and features; rather than Java 7 or 8 or 9 or 10 since I know the cost and benefit. I would rather wait for time to come when Java 9 is out and Java 8 in Maven project. Some can be compromise, like in Surefire I can imaging Java 8 in source code in one child module of multimodule project and the reason is that JUNit 5 is built with Java 8 which makes sense to JUnit team from API point of view and mine as well, but again only that particular module. This is pragmatic and conservative approach.
>>Eclipse's maven support Do you know that IDEA is free of charge in open source project like Maven? I am mixing plenty of JDKs in one project. Separate for IDEA, another for compiler, another for runtime, another for tests and another for Maven. Cool... On Wed, Aug 31, 2016 at 11:05 PM, Richard Sand [via Maven] < [email protected]> wrote: > Agree with Andreas, I can see MRJars usefulness too. APIs with lambdas > come to mind as a good example, or interfaces with default > implementations, are just a couple features of Java8 which I've avoided > adding because of needing backward compatibility. > > Eclipse's maven support in general is very subpar... and it may be > difficult to avoid having multiple projects for different runtimes - but > I could envision a scenario where I'd simply have my project configured > in Eclipse as Java9, but in my pom configured for other builds. Eclipse > wouldn't be able to tell me if a particular piece of code was compatible > with the other runtimes, but maven sure would, and maybe Eclipse will > add the capability. In any event I wouldn't want the limitations of a > particular IDE to drive the POM design and in particular require > multi-projects when a single project could suffice. If I as the end user > can live with the limitations of the IDE (e.g. not being multi-runtime > aware) then I should be allowed to do so. > > Richard Sand | CEO > IDF Connect, Inc. > 2207 Concord Ave, #359 > Wilmington | Delaware 19803 | USA > Office: +1 888 765 1611 | Fax: +1 866 765 7284 > Mobile: +1 267 984 3651 > > > > > ------ Original Message ------ > From: "Andreas Gudian" <[hidden email] > <http:///user/SendEmail.jtp?type=node&node=5879624&i=0>> > To: "Maven Developers List" <[hidden email] > <http:///user/SendEmail.jtp?type=node&node=5879624&i=1>> > Sent: 8/31/2016 4:52:16 PM > Subject: Re: Building jar targeting multiple Java versions, including 9 > > >2016-08-31 22:02 GMT+02:00 Tibor Digana <[hidden email] > <http:///user/SendEmail.jtp?type=node&node=5879624&i=2>>: > > > >> >>So, we can try to have different source folders for different > >>runtimes. > >> No. If you are developers you would not say this. > >> No developer would develop and merge the same code multiple times!!! > >> Look, now let the maven-compiler-plugin to download jars of the same > >> artifact which was released for Version 1.7 and 1.8, and now let the > >> compiler wrap those two versions with current version 1.9 which is > >> ready to be released. Now you have fat jar MRjar. > >> This means any Java version of the artifact can be chosen on the top > >>of > >> JDK9. > >> > >> >>Most other plugins would need to be executed for each version as > >>well - > >> javadoc, junit > >> No. because the previous Versions were already tested and processed. > >> > >> >>Again if they *don't* need a separate execution, then why is MRJar > >> needed? > >> Exactly, and now I cannot imaging company which is going to > >>complicate > >> their project with a stupid MRJar and why so if they have WildFly > >> 8.2.1 which supports Java 8 do you think they EE project would > >> struggle with MRJar? Of course not. If they have WildFly 10.x > >> supporting Java 9 then again no developer would build MRJar. > >> > >> I think MRJar is suitable only for JDK internals and it is only > >> because of Oracle has problem with JCP because JCP does not let > >>Oracle > >> to break backwards compatibility and introduce dynamic language > >> features. So Oracle is trying for compromise. > >> Oracle is trying to let you build java.* JDK with javac, interchange > >> internal modules, etc. > >> Nothing for other non-JDK projects. > >> > > > >That's a bit off-topic, as this thread is about the _how_ and not the > >_why_, but I'd like to point out that I disagree with you here ;). > >MRJars > >would be great for a lot of frameworks and libraries that you would > >_use_ > >in your end-product. Frameworks that offer different alternatives or > >extended features requiring a newer JDK now have to build and maintain > >artifacts either with different versions or with different artifactIds > >(e.g. funky-annotations and funky-annotations-jdk8, where the -jdk8 > >variant > >contains annotations with @Repeatable) -- there are a lot of examples > >out > >there. And that's not only cumbersome for maintainers, but also for > >users > >(which is the bad thing). > > > >So go MRjars! Making them easily consumable for users is the > >top-prirority > >and it looks like a solid approach. > > > >Making them easy to build for the maintainers is way less important (as > >that's only a tiny percentage of the maven-users out there), but it > >sure > >needs to work with different IDEs and especially Eclipse would have > >problems handling different target JDKs in the same project. > > > >So for me as an Eclipse user, I'd have to take the road with the > >multi-module projects. But that's okay, as I'm just building a > >framework > >and separating the different variants for different JDKs has also a lot > >of > >benefits, as already described above: testing, generating javadocs, and > >all > >that other stuff is already there and can be used without having to > >change > >anything. For me, a project collecting the internally seperate > >artifacts > >and combining them into an MRjar would be totally fine. > > > >Andreas > > > > > > > >> > >> -- > >> Cheers > >> Tibor > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: [hidden email] > <http:///user/SendEmail.jtp?type=node&node=5879624&i=3> > >> For additional commands, e-mail: [hidden email] > <http:///user/SendEmail.jtp?type=node&node=5879624&i=4> > >> > >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [hidden email] > <http:///user/SendEmail.jtp?type=node&node=5879624&i=5> > For additional commands, e-mail: [hidden email] > <http:///user/SendEmail.jtp?type=node&node=5879624&i=6> > > > > ------------------------------ > If you reply to this email, your message will be added to the discussion > below: > http://maven.40175.n5.nabble.com/Re-Building-jar-targeting- > multiple-Java-versions-including-9-tp5879531p5879624.html > To start a new topic under Maven Developers, email > [email protected] > To unsubscribe from Maven Developers, click here > <http://maven.40175.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=142166&code=dGlib3JkaWdhbmFAYXBhY2hlLm9yZ3wxNDIxNjZ8LTI4OTQ5MjEwMg==> > . > NAML > <http://maven.40175.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml> > -- View this message in context: http://maven.40175.n5.nabble.com/Re-Building-jar-targeting-multiple-Java-versions-including-9-tp5879531p5879691.html Sent from the Maven Developers mailing list archive at Nabble.com.
