Re: Shading, relocation and modules?

[Robert Scholte]

It is not clear to me what the problem is.
As you shade antlr4 code, and they are only used by your own code, 
there's no need for exports or requirements, so I don't see why the 
module descriptor would be an issue.
... unless it is a cross-(Maven)module and you need to use these classes 
in a different module.

In that case you can export specific packages to a different module.

Is it the Java9Modules branch you're talking about?

thanks,
Robert

-- Origineel bericht --
Van: "Niels Basjes" 
Aan: users@maven.apache.org
Verzonden: 11-4-2022 22:28:52
Onderwerp: Shading, relocation and modules?


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



-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Shading, relocation and modules?

[Slawomir Jaranowski]

Hi,

New transformer is a good idea.
There is also similar issue https://issues.apache.org/jira/browse/MSHADE-262


wt., 12 kwi 2022 o 11:35 Delany  napisał(a):

> Hi Niels,
>
> I don't see an existing resource transformer for module-info
>
> https://maven.apache.org/plugins/maven-shade-plugin/examples/resource-transformers.html
>
> Did you see this?
> https://stackoverflow.com/a/58097561/2746335
>
> Delany
>
> On Tue, 12 Apr 2022 at 11:16, Niels Basjes  wrote:
>
> > Thanks.
> >
> > I was hoping for a "native" Java solution instead of an (apparently
> > necessary) external plugin that hacks this in.
> >
> > Niels
> >
> > On Mon, Apr 11, 2022 at 11:32 PM Daniel B. Widdis 
> > wrote:
> >
> > > > 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)
> > > 
> > >
> > >
> > >
> > >
> > > On Mon, Apr 11, 2022 at 1:29 PM Niels Basjes  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. ).
> > > > 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
> > >
> >
> >
> > --
> > Best regards / Met vriendelijke groeten,
> >
> > Niels Basjes
> >
>


-- 
Sławomir Jaranowski

Re: Shading, relocation and modules?

[Delany]

Hi Niels,

I don't see an existing resource transformer for module-info
https://maven.apache.org/plugins/maven-shade-plugin/examples/resource-transformers.html

Did you see this?
https://stackoverflow.com/a/58097561/2746335

Delany

On Tue, 12 Apr 2022 at 11:16, Niels Basjes  wrote:

> Thanks.
>
> I was hoping for a "native" Java solution instead of an (apparently
> necessary) external plugin that hacks this in.
>
> Niels
>
> On Mon, Apr 11, 2022 at 11:32 PM Daniel B. Widdis 
> wrote:
>
> > > 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)
> > 
> >
> >
> >
> >
> > On Mon, Apr 11, 2022 at 1:29 PM Niels Basjes  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. ).
> > > 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
> >
>
>
> --
> Best regards / Met vriendelijke groeten,
>
> Niels Basjes
>

Re: Shading, relocation and modules?

[Niels Basjes]

Thanks.

I was hoping for a "native" Java solution instead of an (apparently
necessary) external plugin that hacks this in.

Niels

On Mon, Apr 11, 2022 at 11:32 PM Daniel B. Widdis  wrote:

> > 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)
> 
>
>
>
>
> On Mon, Apr 11, 2022 at 1:29 PM Niels Basjes  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. ).
> > 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
>


-- 
Best regards / Met vriendelijke groeten,

Niels Basjes

Re: Shading, relocation and modules?

[Daniel B. Widdis]

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





On Mon, Apr 11, 2022 at 1:29 PM Niels Basjes  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. ).
> 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

Shading, relocation and modules?

[Niels Basjes]

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