> My question is what is the correct/preferred/recommended way to do this?

Not combine shading and JPMS! :-)

But seriously.  Have a look at Moditect.  It has the capability of adding a
module-descriptor to a JAR after the fact, and may suit your needs.  I
honestly can't think of any other sane way to go about this.

moditect/moditect: Tooling for the Java Module System (github.com)
<https://github.com/moditect/moditect>




On Mon, Apr 11, 2022 at 1:29 PM Niels Basjes <ni...@basjes.nl> wrote:

> Hi,
>
> I have a project ( https://yauaa.basjes.nl/ ) which is a library that is
> used by others as a dependency.
> My project uses (among other things) Antlr4 as a building block.
> Antlr4 is a code generator that is (rightfully) very strict about the
> Antlr4-runtime version available at runtime: they must be identical
> versions.
>
> I do not want to impose "my" Antlr4 version onto the users of my library so
> I have shaded and relocated the correct Antlr4 version into my final jar.
> Now anyone can use it next to a different Antrl4 version in the same
> application without any conflicts.
>
> Entering JPMS...
>
> I'm trying to make my library as "JPMS" as possible.
>
> From what I understand at this time: when I shade some dependencies into my
> final jar the modules-info is removed by the maven-shade-plugin as this
> would break everything.
>
> In general I agree with this; yet in my case all of the shaded
> dependencies:
> 1) Have been relocated to a new package that does not exist anywhere else (
> nl.basjes.shaded.<original> ).
> 2) None of these should be visible outside the module.
>
> So in my mind these classes are modified to become "my" classes as they are
> moved to my namespace and I expect them to fall under similar rules as the
> classes I have created.
>
> Yet I have not yet been successful in making all of this work.
>
> My question is what is the correct/preferred/recommended way to do this?
>
> --
> Best regards / Met vriendelijke groeten,
>
> Niels Basjes
>


-- 
Dan Widdis

Reply via email to