[
https://issues.apache.org/jira/browse/VFS-676?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16655655#comment-16655655
]
Gary Gregory commented on VFS-676:
----------------------------------
Patches via github PRs are more than welcome ;-)
> VFS does not support several Zip file compression methods
> ---------------------------------------------------------
>
> Key: VFS-676
> URL: https://issues.apache.org/jira/browse/VFS-676
> Project: Commons VFS
> Issue Type: Improvement
> Affects Versions: 2.2, 2.2.1
> Reporter: Sérgio Ribeiro
> Priority: Major
>
> VFS currently bases its ZipFileSystem implementation on the "java.util.zip"
> package, this makes it support *only* the +STORED+ and +DEFLATE+ compression
> methods.
> If it were using *Apache Commons Compression*, it would support much more
> (check
> [https://commons.apache.org/proper/commons-compress/zip.html#encryption)|https://commons.apache.org/proper/commons-compress/zip.html#encryption);].
> At the time this issue is being created the supported methods for version
> 1.18 are: STORED, DEFLATE, SHRINK, IMPLODE, BZIP2, DEFLATE64 (enhanced
> deflate).
>
> It would be nice to have one of the following options:
> # Change the current implementation to use Apache Commons Compression (this
> would, most probably, make Apache Commons Compression a non-optional
> dependency);
> # Add an Apache Commons Compression based provider and have some (easy) way
> of letting the user decide which implementation to use.
>
> The first option would make Apache Commons Compress a *non-optional*
> dependency while the second one could allow it to continue as optional.
> Currently, if Apache Commons Compress is available, one has access to both
> Bzip2FileProvider and TarFileProvider - a strategy that could be used to
> decide which ZipFileSystem implementation to use.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
