[jira] [Comment Edited] (MSHADE-262) Add jpms goal

["Alexander Kriegisch (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/MSHADE-262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17521418#comment-17521418 ] 

Alexander Kriegisch edited comment on MSHADE-262 at 4/13/22 2:39 AM:
---------------------------------------------------------------------

Whether you guys decide to implement this as a new goal, a strategy or a transformer - I actually like the last idea - is up to you, but because this issue was created in 2017 and is not implemented yet, I want to at least think aloud and point to some resources. I believe that tackling a new feature is always easier if you have a rough idea where to start looking:

Shade uses ASM. ASM supports modules, see [ASM object model|https://asm.ow2.io/developer-guide.html#objectmodel] description. There you can also find a [UML diagram|https://asm.ow2.io/asm-package-overview.svg].

Probably, you should take a look at [{{ModuleVisitor}}|https://asm.ow2.io/javadoc/org/objectweb/asm/ModuleVisitor.html], maybe also [{{ModuleRemapper}}|https://asm.ow2.io/javadoc/org/objectweb/asm/commons/ModuleRemapper.html]. The [{{CheckModuleAdapter}}|https://asm.ow2.io/javadoc/org/objectweb/asm/util/CheckModuleAdapter.html] might also be helpful. The ASM javadoc obviously does not display package-protected classes, so I am linking to the source code of [{{ModuleWriter}}|https://gitlab.ow2.org/asm/asm/-/blob/master/asm/src/main/java/org/objectweb/asm/ModuleWriter.java], which is mentioned several times in the developer guide.

The dev guide also mentions in the [overview section|https://asm.ow2.io/developer-guide.html#overview]:
{quote}{{tools}} contains (...) a BND plugin to generate a {{module-info.class}} for each ASM artifact
{quote}
That tool can be found in class [{{ModuleInfoBndPlugin}}|https://gitlab.ow2.org/asm/asm/-/blob/master/tools/bnd-module-plugin/src/main/java/org/objectweb/asm/tools/ModuleInfoBndPlugin.java] and is a nice starting point, if you want to see how to create a module info class file from scratch. Instead of using OSGi plugin manifest entries as a starting point, in our case we would probably use a bunch of module visitors for each module info we find, collect the information, relocate the packages as configured for the Shade execution and write a merged module info. Of course, we would fall back to removing the module info, if we notice that the resulting shaded JAR would contain more than one base package.

This is just a raw sketch, but better a raw starting point than none at all. I hope that you would agree with that assumption.

Oh BTW, doing the same for module info source files might even be trickier than for the class files, because we do not have a nice tool like ASM, prepared to read, transform and write it.


was (Author: kriegaex):
Whether you guys decide to implement this as a new goal, a strategy or a transformer - I actually like the last idea - is up to you, but because this issue was created in 2017 and it is not implemented yet, I want to at least think aloud and point to some resources,because I think tackling a new feature is always easier if you have a rough idea where to start looking:

Shade uses ASM. ASM supports modules, see [ASM object model|https://asm.ow2.io/developer-guide.html#objectmodel] description. There you can also find a [UML diagram|https://asm.ow2.io/asm-package-overview.svg].

Probably you should take a look at [{{ModuleVisitor}}|https://asm.ow2.io/javadoc/org/objectweb/asm/ModuleVisitor.html], maybe also [{{ModuleRemapper}}|https://asm.ow2.io/javadoc/org/objectweb/asm/commons/ModuleRemapper.html]. The [{{CheckModuleAdapter}}|https://asm.ow2.io/javadoc/org/objectweb/asm/util/CheckModuleAdapter.html] might also be helpful. Maybe the Javadoc is incomplete, so I am linking to the source code of [{{ModuleWriter}}|https://gitlab.ow2.org/asm/asm/-/blob/master/asm/src/main/java/org/objectweb/asm/ModuleWriter.java], which is mentioned several times in the developer guide.

The dev guide also mentions in the [overview section|https://asm.ow2.io/developer-guide.html#overview]:

bq. {{tools}} contains (...) a BND plugin to generate a {{module-info.class}} for each ASM artifact

That tool can be found in class [{{ModuleInfoBndPlugin}}|https://gitlab.ow2.org/asm/asm/-/blob/master/tools/bnd-module-plugin/src/main/java/org/objectweb/asm/tools/ModuleInfoBndPlugin.java] and is a nice starting point, if you want to see how to create a module info class file from scratch. Instead of using OSGi plugin manifest entries as a starting point, in our case we would probably use a bunch of module visitors for each module info we find, collect the information, relocate the packages as configured for the Shade execution and write a merged module info. Of course, we would fall back to removing the module info, if we notice that the resulting shaded JAR would contain more than one base package.

This is just a raw sketch, but better a raw starting point than none at all. I hope that you would agree with that assumption.

> Add jpms goal
> -------------
>
>                 Key: MSHADE-262
>                 URL: https://issues.apache.org/jira/browse/MSHADE-262
>             Project: Maven Shade Plugin
>          Issue Type: New Feature
>            Reporter: Robert Scholte
>            Assignee: Robert Scholte
>            Priority: Major
>
> With Java 9 we get module descriptors for strong encapsulation and reliable configuration.
> When shading we should not merge or ignore these descriptors.
> In case of an application we should think of the way spring boot works, i.e. bundle the jars in a jar and provide a new classloader. This is the only way to preserve the strong encapsulation right now.
> After a talk with [~pwebb] and [~dblevins] we came to the conclusion that it should NOT be combined with the current shade goal. First idea was to make a new plugin, but after some rethinking I'd prefer to just make a separate goal for it in this shade-plugin.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)