[MSHADE-262] Add jpms goal

[jira-importer]

Robert Scholte opened MSHADE-262 and commented

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 Phillip Webb and David Blevins 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.

---

1 votes, 4 watchers

[jira-importer]

Markus Karg commented

Maybe it would be a good idea to actually not provide a new goal, but instead have a different Shader strategy. This sounds most intuitive: What you actually want to reach is not that another goal is reached – you still want to shade stuff. But you want to use a different strategy when shading: A JPMS strategy. So my advice would be: Keep the goal, but change the shader.

[jira-importer]

Slawomir Jaranowski commented

There is also appear idea for creating transformer for module-info.

https://lists.apache.org/thread/925qq3hljq06c5qjhdvbnhfo47z7lmhv

[jira-importer]

Alexander Kriegisch commented

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 description. There you can also find a UML diagram.

Probably, you should take a look at ModuleVisitor, maybe also ModuleRemapper. The CheckModuleAdapter might also be helpful. The ASM javadoc obviously does not display package-protected classes, so I am linking to the source code of ModuleWriter, which is mentioned several times in the developer guide.

The dev guide also mentions in the overview section:

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

That tool can be found in class ModuleInfoBndPlugin 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.