You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@maven.apache.org by "Slawomir Jaranowski (Jira)" <ji...@apache.org> on 2022/10/12 06:46:00 UTC

[jira] [Closed] (MEAR-298) Improving EAR packaging performance with ZipFileSystem

     [ https://issues.apache.org/jira/browse/MEAR-298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Slawomir Jaranowski closed MEAR-298.
------------------------------------
    Fix Version/s: 3.3.0
       Resolution: Fixed

> Improving EAR packaging performance with ZipFileSystem
> ------------------------------------------------------
>
>                 Key: MEAR-298
>                 URL: https://issues.apache.org/jira/browse/MEAR-298
>             Project: Maven EAR Plugin
>          Issue Type: Improvement
>            Reporter: Peter Uhnak
>            Assignee: Slawomir Jaranowski
>            Priority: Minor
>              Labels: up-for-grabs
>             Fix For: 3.3.0
>
>
> Hi, I was exploring performance around the ear packaging on Windows, and found a major bottleneck in the `EarMojo#changeManifestClasspath`.
> The current implementation always unpacks and then re-packs all its modules to check/make manifest.mf changes, and remove jars if necessary (skinnyWars).
> On Windows, this is extra costly for modules with too many small files (e.g. war). Plus the extra time of uncompressing/compressing. (This also changes the war's compression, if configured in the maven-war-plugin).
> I have a working implementation using nio ZipFileSystem which performs all changes directly in the zip, so I can make a PR.
> For our projects I'm seeing 70-90+% perf improvements (or rather near-constant time vs time increasing with the size of the modules).
>  



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