maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Russell Gold <russell.g...@oracle.com>
Subject Re: Are multi-release jars supported?
Date Mon, 28 Aug 2017 17:29:37 GMT
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 <rfscholte@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.gold@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-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
> 


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message