[
https://issues.apache.org/jira/browse/COMPRESS-93?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12842640#action_12842640
]
Stefan Bodewig commented on COMPRESS-93:
----------------------------------------
I'm not sure I like having discussions in JIRA rather than a mailing list ...
Anyway.
Another reason may be that the compression - or encryption - method is patent
encumbered or its implementation comes with a license commons compress wouldn't
want to use.
Treykaz: IIUC you'd just need a few convenient protected methods you could
override and wouldn't really require a plugin or factory API. This may be
doable without too much added complexity.
WRT why the ZIP packages exist. I know why I've started the one for Ant (which
is the grandfather of commons-compress' zip package) and no, it wouldn't have
helped. The Sun implementation is lacking important features of the ZIP
"protocol", which is OK if you view it as limited to the JAR use-case. The
original driver was that I needed access to the "external attributes" - which
you can't even read in java.util.ZipEntry - in order to store Unix permissions
the same way InfoZIP's implementation does.
> Support for alternative ZIP compression methods
> -----------------------------------------------
>
> Key: COMPRESS-93
> URL: https://issues.apache.org/jira/browse/COMPRESS-93
> Project: Commons Compress
> Issue Type: New Feature
> Reporter: Jukka Zitting
>
> As reported in TIKA-346, a ZIP file that uses a compression method other than
> STORED (0) or DEFLATED (8) will cause an IllegalArgumentException ("invalid
> compression method") to be thrown.
> It would be great if commons-compress supported alternative compression
> methods or at least degraded more gracefully when encountering them.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
