Hi Robert, My main issue with that solution is that you wind up with four maven projects for each jar - which is really painful for multi-module projects. I submitted a feature request <https://youtrack.jetbrains.com/issue/IDEA-168946> to Jetbrains for IntellijIDEA back in March, but I suspect that there won’t be much incentive for them to move on it until they see how the tools will handle it. It’s a bit of a chicken-and-egg problem. People don’t want to lose the IDE benefits, so they aren’t pushing for a tooling improvement, but until they do, the pattern that the IDEs should support isn’t well-defined, so the IDEs won’t bother making the needed changes.
I have found a really hackish work-around using soft links :) As for the necessity, we’ve found that we need to support a range of JDK versions from 1.7-9, and there are APIs in the JDK itself which were removed in 9 which our older libraries need, and replacements don’t work in 1.7. The module system turns out to break some 1.8-based approaches in 9, and alternative APIs aren’t available until 9, which means that the only way to support both 1.8 and 9 is an MR jar. The impression I have from Mark Reinhold is that the existence of the MR jar technique will motivate them to be even more aggressive in removing legacy APIs. I’m thinking that improving on the modified lifecycle approach might be the quickest way to get there in the short term, and will do some experimentation. Thanks, Russ > On Aug 28, 2017, at 1:11 PM, Robert Scholte <rfscho...@apache.org> wrote: > > Hi Russ, > > I think Hervés approach[1] is still the most cleanest possible solution. > Main advantages: > - works with every IDE as it is a standard multimodule project. > - real unit testing for every version due to its isolation as Maven module. > > The assembly-part at the end is the most ugly part. > > With Maven it is quite easy to exceed the original intention of multirelease > jars. > It should only change the JDK/JRE related code, but with JDK activated > profiles you can control dependencies as well. > > Solving this within a single maven projects would probably be the ultimate > goals (it should result in a single jar), but with the current architecture > of Maven it is simply not possible keeping the advantages mentioned. > > For that reason I did not pay any extra attention to this subject. There is a > reasonable solution and one might wonder if these multirelease jars are a > good solution or will only overcomplicate things. Yes, there are cases where > multirelease jars will help (also within Maven itself), but in general I > don't think it will be used that much. > > Any suggestions to improve this are welcome :) > > Robert > > [1] https://github.com/hboutemy/maven-jep238 > > On Mon, 28 Aug 2017 16:18:40 +0200, Russell Gold <russell.g...@oracle.com> > wrote: > >> I have found a number of workarounds for MR jars, including >> https://github.com/metlos/multi-release-jar-maven-plugin, which makes the >> jars relatively easy to build, but lacks support for unit tests and doesn’t >> allow building in lower JDKs. Is there built-in maven support now? If not, >> is there a road map? >> >> I recognize that one of the problems in that the editors don’t appear to >> support the innovations, including multiple classes with the same name but >> different JDKs; I am hoping that maven support would prod the editor >> maintainers, once they know how the tools expect the directories to be laid >> out. >> >> Thanks, >> Russ >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org >> For additional commands, e-mail: users-h...@maven.apache.org > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org >
