[
https://issues.apache.org/jira/browse/JCRVLT-259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16321464#comment-16321464
]
Tobias Bocanegra commented on JCRVLT-259:
-----------------------------------------
Hi [~diru], thanks for all your work.
I generally agree that having a better abstraction for archive handling is
desirable. I don't know of this should be done on such a low level, though.
what could be problematic with your changes are:
- it looks like quite a lot of public API was changed, so we probably would
need to increase the package versions by a major digit, which will make it
incompatible with most of existing installations. so we could consider to move
to tackle this for 3.2.
- having a new dependency to common-compress also brings in supportability for
existing installations; I'm not a big fan of embedding libraries in bundles.
- using the JAR format mandates that the MANIFEST.MF is the first entry in the
archive. we need to ensure that this is still the fact.
If you can rework the patch, so that it doesn't use commons-compress and the
"user" can specify the exporter/importer to use via export- and import options,
that would probably be better.
ps: since this is rather a big patch, The ASF requires you to have a CLA signed
before we can use it. see https://www.apache.org/licenses/ for details.
(I checked the committer roster [0] and the non-committer CLA page [1], and you
weren't listed. In case I missed something, please ignore)
[0] http://people.apache.org/committer-index.html
[1] http://people.apache.org/unlistedclas.html
> Support pluggable compression formats
> -------------------------------------
>
> Key: JCRVLT-259
> URL: https://issues.apache.org/jira/browse/JCRVLT-259
> Project: Jackrabbit FileVault
> Issue Type: New Feature
> Components: Packaging
> Reporter: Dirk Rudolph
>
> The new feature to suppress compression for already compressed binaries
> introduced in JCRVLT-163, has been implemented with Apache Sling Content
> Distribution in mind to get best performance while still keep bytes on the
> wire as small as affordable [0].
> Wouldn't it make sense for such cases to support different compression
> formats as well, especially thinking about snappy or lz4?
> Currently there is a pair for compressing and decompressing implementations,
> JarExporter and ZipArchive/ZipStreamArchive. Those are used by the
> PackageManagerImpl for example to open or assemble a new package. Adding
> support for further compression formats could be done for example by
> implementing a registry holding the constructors for compression and
> decompression implementations, where the one of choice could be requested by
> the ExportOptions (defaulting to jar/zip as it is now).
> [0]
> https://github.com/apache/sling-org-apache-sling-distribution-core/blob/master/src/main/java/org/apache/sling/distribution/serialization/impl/vlt/VltUtils.java#L190
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
