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