[
https://issues.apache.org/jira/browse/COMPRESS-391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15998420#comment-15998420
]
ASF GitHub Bot commented on COMPRESS-391:
-----------------------------------------
Github user bodewig commented on the issue:
https://github.com/apache/commons-compress/pull/24
I don't see a chance of making it independent of `ZipArchiveOutputStream`,
you are certainly correct.
I was thinking along the lines of `ZipArchiveOutputStream` calculates the
length needed for proper alignment, creates an instance of the new extra field
passing in the size information necessary and adds it to the `ZipArchiveEntry`
- after that the code in `ZipArchiveOutputStream` can be left unchanged.
> 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)
