[
https://issues.apache.org/jira/browse/MSHADE-205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benoit Perrot updated MSHADE-205:
---------------------------------
Description:
Minimizing an uber-jar consists in assessing the relevance of classes of all
artifacts on which the project being processed depends: when a class is not
identified as being used, it is simply removed from the final jar.
To support implicit uses (e.g. dynamically loaded classes), it is possible to
explicitly tell the maven-shade-plugin that a classes must be specifically
included.
The algorithm for assessing the relevance of these classes is roughly the
following:
{code}
// All classes are initially considered as irrelevant
for each artifact in dependencies:
for each class in the set of irrelevant ones:
if artifact contains class && class is specifically included:
remove class from the set of irrelevant ones
{code}
Checking whether an artifact contains a class or not is done by invoking the
{{getClazzes()}} method on {{org.vafer.jdependency}} {{ClazzpathUnit}}.
Contrary to what its name suggests, this method is not as harmless as it seems:
it actually builds a hash set and fills it up with the entire set of classes in
a given jar _each time it is called_. (See ClazzpathUnit.java, line 36 at the
time of writing)
The instance of {{ClazzpathUnit}} is not modified during the iteration, so
simply caching the result of this {{getClazzes()}} would avoid the creation and
filling of the said set, and greatly increase the speed of the process.
The improvement obviously depends on the number of artifacts used by the
project being processed, and the number of classes inside them. We observed
very significant gains on our industrial cases.
was:
Minimizing an uber-jar consists in assessing the relevance of classes of all
artifacts on which the project being process depends: when a class is not
identified as being used, it is simply removed from the final jar.
To support implicit uses (eg. dynamicaly loaded classes), it is possible to
explicitly tell the maven-shade-plugin that a classes must be specifically
included.
The algorithm for assessing the relevance of these classes is roughly the
following:
{code}
// All classes are initially considered as irrelevant
for each artifact in dependencies:
for each class in the set of irrelevant ones:
if artifact contains class && class is specifically included:
remove class from the set of irrelevant ones
{code}
Checking whether an artifact contains a class or not is done by invoking the
{{getClazzes()}} method on {{org.vafer.jdependency}} {{ClazzpathUnit}}.
Contrary to what its name suggests, this method is not as harmless as it seems:
it actually builds a hash set and fills it up with the entire set of classes in
a given jar _each time it is called_. (See ClazzpathUnit.java, line 36 at the
time of writing)
The instance of {{ClazzpathUnit}} is not modified during the iteration, so
simply caching the result of this {{getClazzes()}} would avoid the creation and
filling of the said set, and greatly increase the speed of the process.
The improvement obviously depends on the number of artifacts used by the
project being processed, and the number of classes inside them. We observed
very significant gains on our industrial cases.
> Better use of ClazzpathUnit for improved jar minimization
> ---------------------------------------------------------
>
> Key: MSHADE-205
> URL: https://issues.apache.org/jira/browse/MSHADE-205
> Project: Maven Shade Plugin
> Issue Type: Improvement
> Affects Versions: 2.4.1
> Reporter: Benoit Perrot
>
> Minimizing an uber-jar consists in assessing the relevance of classes of all
> artifacts on which the project being processed depends: when a class is not
> identified as being used, it is simply removed from the final jar.
> To support implicit uses (e.g. dynamically loaded classes), it is possible to
> explicitly tell the maven-shade-plugin that a classes must be specifically
> included.
> The algorithm for assessing the relevance of these classes is roughly the
> following:
> {code}
> // All classes are initially considered as irrelevant
> for each artifact in dependencies:
> for each class in the set of irrelevant ones:
> if artifact contains class && class is specifically included:
> remove class from the set of irrelevant ones
> {code}
> Checking whether an artifact contains a class or not is done by invoking the
> {{getClazzes()}} method on {{org.vafer.jdependency}} {{ClazzpathUnit}}.
> Contrary to what its name suggests, this method is not as harmless as it
> seems: it actually builds a hash set and fills it up with the entire set of
> classes in a given jar _each time it is called_. (See ClazzpathUnit.java,
> line 36 at the time of writing)
> The instance of {{ClazzpathUnit}} is not modified during the iteration, so
> simply caching the result of this {{getClazzes()}} would avoid the creation
> and filling of the said set, and greatly increase the speed of the process.
> The improvement obviously depends on the number of artifacts used by the
> project being processed, and the number of classes inside them. We observed
> very significant gains on our industrial cases.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
