You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@maven.apache.org by "Michael Osipov (Jira)" <ji...@apache.org> on 2023/02/05 17:07:00 UTC

[jira] [Commented] (MSHADE-400) Self-minimisation for the module executing Shade

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

Michael Osipov commented on MSHADE-400:
---------------------------------------

Willing to take a look at your solution since I understand the motivation. Can you replace your PR on top of current master?

> Self-minimisation for the module executing Shade
> ------------------------------------------------
>
>                 Key: MSHADE-400
>                 URL: https://issues.apache.org/jira/browse/MSHADE-400
>             Project: Maven Shade Plugin
>          Issue Type: New Feature
>    Affects Versions: 3.2.4
>            Reporter: Alexander Kriegisch
>            Priority: Major
>
> While discussing MSHADE-366, [~rmannibucau] refused to merge a simple workaround suppressing the warning {{target/classes (access denied)}} during minimisation (option {{minimizeJar}}), suggesting that instead directories should be handled as a first-class class container, just like dependency JARs.
> * He implemented that for {{DefaultShader}}, which has no effect on minimisation.
> * So I also implemented it for {{MinijarFilter}}. To my surprise, it had no effect either, because minimisation is currently just implemented for dependencies, not for the target module itself.
> So what we need here is *self-minimisation*, i.e. removal of unneeded classes in the target module itself. For boot-strapping reasons - we need starting points for class dependency analysis - it is necessary to add a new plugin parameter {{entryPoints}}, taking a set of fully-qualified class names as its input. If present and {{minimizeJar}} is active, it will treat only the defined entry points (e.g. classes with main methods, but can be any type of class) as starting points for dependency analysis instead of all classes of the target module.
> This feature should also correctly consider [Java Service Provider (SPI)|https://www.baeldung.com/java-spi] configuration files according to the implementation of MSHADE-313. I.e., services are to be considered as entry points if and only if there is an SPI config file and somethign like {{ServiceLoader.load( MyServiceProvider.class )}} is present in a Java entry point class or one of its (transitive) dependency classes. In that case, both the service provider interface and all implementations defined in the SPI config file are being kept in the minimised JAR. Due to unified handling of directories and JARs as input sources for minimisation, this should work transparently.
> I already have a first implementation which I am going to push and link to this issue soon.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)