[ 
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)

Reply via email to