[ https://issues.apache.org/jira/browse/COMPRESS-391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16005830#comment-16005830 ]
ASF GitHub Bot commented on COMPRESS-391: ----------------------------------------- Github user coveralls commented on the issue: https://github.com/apache/commons-compress/pull/24 [![Coverage Status](https://coveralls.io/builds/11469394/badge)](https://coveralls.io/builds/11469394) Coverage increased (+0.09%) to 84.309% when pulling **77f5ce3714e194704332aa66bca746c9806f2be7 on kvr000:feature/COMPRESS-391-allow-entries-alignment** into **ca7ea939eaa9dad5f00c8a5e269f09681602bc98 on apache:master**. > Zip entries alignment > --------------------- > > Key: COMPRESS-391 > URL: https://issues.apache.org/jira/browse/COMPRESS-391 > Project: Commons Compress > Issue Type: New Feature > Components: Archivers > Affects Versions: 1.13 > Reporter: Zbynek Vyskovsky > Labels: features, github-import, patch > Fix For: 1.14 > > > Similarly to COMPRESS-390, there are requirements of the zip content to be > mapped directly into memory and therefore may require special alignment on > the embedded files. E.g. libraries may be aligned to page (4096-bytes) > boundary, images on 4-bytes boundary etc. By alignment it's meant the offset > from the beginning of file where the actual data stream starts, not the > header. > One of the cases was (still is?) Android APK for which zipalign utility was > created. > It would be useful if commons-compress ZipArchiveOutputStream supports > something similar directly in its API. -- This message was sent by Atlassian JIRA (v6.3.15#6346)