You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@maven.apache.org by "Markus Karg (JIRA)" <ji...@apache.org> on 2019/04/05 17:44:00 UTC

[jira] [Comment Edited] (MSHADE-313) Less agressive

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

Markus Karg edited comment on MSHADE-313 at 4/5/19 5:43 PM:
------------------------------------------------------------

Yes, indeed you missed the most important part of my PR: Whether or not "Main" uses the service or not plays not role, that's a very essential point that the code expresses! The outcome of the shade plugin is a service in turn that is not limited to what "Main" does, but will be used by any third-party consumer. As *that* is out of reach of any technical check, the service MUST be kept always, independent of whatever "Main" does nor does not. And yes, "Main" MUST stay part of the project, because it still is a public class that a consumer of the outcome of the shade plugin might want to load that class!


was (Author: mkarg):
Yes, indeed you missed the most important part of my PR: Whether or not "Main" uses the service or not plays not role, that's a very essential point that the code expresses! The outcome of the shade plugin is a service in turn that is not limited to what "Main" does, but will be used by any third-party consumer. As *that* is out of reach of any technical check, the service MUST be kept always, independent of whatever "Main" does nor does not. :-)

> Less agressive <minimizeJar>
> ----------------------------
>
>                 Key: MSHADE-313
>                 URL: https://issues.apache.org/jira/browse/MSHADE-313
>             Project: Maven Shade Plugin
>          Issue Type: Improvement
>    Affects Versions: 3.2.1
>            Reporter: Markus Karg
>            Priority: Major
>          Time Spent: 10m
>  Remaining Estimate: 0h
>
> The maven shade plugin already does a great job in minimizing JAR size. For the majority of applications this is exactly what is needed.
> On the other hand there are some application areas where the algorithm is too agressive. One particular and rather frequently found case is the services API: ServiceLoader will ceise to work for minimized JARs since it is the prototype of the biggest "minimize-JAR-antipattern": String-to-class conversion.
> To make <minimizeJar> usable in such scenarios, there should be a set of options to enable the usual suspetcs (like ServiceLoader) to be detected.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)