[ https://issues.apache.org/jira/browse/COMPRESS-400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16037491#comment-16037491 ]
ASF GitHub Bot commented on COMPRESS-400: ----------------------------------------- GitHub user sesuncedu opened a pull request: https://github.com/apache/commons-compress/pull/27 COMPRESS-400 Add extra header map to tar archive entry. Move PAX header processing code from TarArchiveInputStream to TarAchiveEntry. Use same code for processing user supplied extra headers - thus setting "size "changes the value of getSize(). Add any extra PAX headers to output map when putting entry in TarArchiveOutputStream. Add simple tests for getting/setting xattr, setting "size", and round tripping. This PR uses COMPRESS-399 as a base. To make it easier to cherry-pick + rebase the PR has been split in two. 1d9b3c88455caceca81f0ff6b7eca0958c631359 contains just the code changes and test changes, and does not bump the minor package version . This will cause the bundle:baseline verify goal in 399 to break the build. 82405c13bd2688817108d3f2854387b3417a764d increases the package minor version to the correct value You can merge this pull request into a Git repository by running: $ git pull https://github.com/sesuncedu/commons-compress COMPRESS-400 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/commons-compress/pull/27.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #27 ---- commit 109b14915cf594e5c2031e58d6f2fd0595fc184f Author: Simon Spero <sesunc...@gmail.com> Date: 2017-06-02T17:25:02Z COMPRESS-399 OSGI package versions are overly pessimistic, except when they're overly optimisic Add packageinfo files for per-package version settings. Initialize to 1.14 Copy packageinfo files in resource phase. Use latest bundle plugin. Remove superflous headers from manifest. Pretty-print the manifest. Add bundle:baseline to the verify phase Add bundle:baseline-report to the site phase To change the base version from default (i.e. previous release) set comparisonVersion property Change travis build goal to verify Signed-off-by: Simon Spero <sesunc...@gmail.com> commit 3653a2e19b51c9bd894e3928ed959c0132afd9b6 Author: Simon Spero <sesunc...@gmail.com> Date: 2017-06-02T17:37:53Z Default rat doesn't ignore packageinfo One line of non copyrightable material does not need the license header :) commit 27b65778eee34805838a0e43777b98fb6714dc2a Author: Simon Spero <sesunc...@gmail.com> Date: 2017-06-05T15:55:18Z Replace packageinfo files with annotated package-info.java as source of version info. Add build time dependency on org,osgi.annotation for Version annotation. Remove resource copy. Signed-off-by: Simon Spero <sesunc...@gmail.com> commit 1d9b3c88455caceca81f0ff6b7eca0958c631359 Author: Simon Spero <sesunc...@gmail.com> Date: 2017-06-05T19:58:27Z COMPRESS-400 It should be possible for users to create and access extra PAX headers to tar archives Add extra header map to tar archive entry. Move PAX header processing code from TarArchiveInputStream to TarAchiveEntry. Use same code for processing user supplied extra headers - thus setting "size "changes the value of getSize(). Add any extra PAX headers to output map when putting entry in TarArchiveOutputStream. Add simple tests for getting/setting xattr, setting "size", and round tripping. This PR uses COMPRESS-399 as a base. To make it easier to cherry-pick, this commit does not bump the minor package version; this will cause the baseline verify stage in 399 to break the build, since the API has changed in a backwards compatible fashion A separate commit increases the package minor version. Signed-off-by: Simon Spero <sesunc...@gmail.com> commit 82405c13bd2688817108d3f2854387b3417a764d Author: Simon Spero <sesunc...@gmail.com> Date: 2017-06-05T20:02:32Z Increase the minor package version for org.apache.commons.compress.archivers.tar to 1.15.0 to reflect backwards compatible changes to API: [INFO] < org.apache.commons.compress.archivers.tar minor 1.15.0 1.14.0 1.15.0 - [INFO] < class org.apache.commons.compress.archivers.tar.TarArchiveEntry [INFO] + method addPaxHeader(java.lang.String,java.lang.String) [INFO] + method addXattr(java.lang.String,java.lang.String) [INFO] + method clearExtraPaxHeaders() [INFO] + method getExtraPaxHeader(java.lang.String) [INFO] + return java.lang.String [INFO] + method getExtraPaxHeaders() [INFO] + return java.util.Map<Ljava.lang.String;Ljava.lang.String;> [INFO] + method getXattr(java.lang.String) [INFO] + return java.lang.String [INFO] - version 1.14.0 [INFO] + version 1.15.0 Signed-off-by: Simon Spero <sesunc...@gmail.com> ---- > It should be possible for users to create and access extra PAX headers to tar > archives > --------------------------------------------------------------------------------------- > > Key: COMPRESS-400 > URL: https://issues.apache.org/jira/browse/COMPRESS-400 > Project: Commons Compress > Issue Type: Improvement > Components: Archivers > Reporter: Simon Spero > Priority: Minor > > It is very useful to be able to add extra PAX headers to tar entries. For > example, a tar file containing maven artifacts could have extra headers > carrying the groupid, artifactid, version, classifier, etc. > If the appropriate prefixes are used, these headers can be extracted to posix > extended attributes by gnu and bsdtar. > This change requires adding a map to TarArchiveEntry to carry the extra > headers, plus modifications to the TarArchive*Stream to save unrecognized > headers when reading, and to add any extra headers when writing. > I have created a prototype implementation, but have not merged it into my > fork of the project. I don't have full tests written, because I was using > gnutar as an oracle. > I have also ignored the issue of writing values to standard headers like > size, though since the PAX specification states that doing things like > setting size=100 (if the real size is not in fact 100) is undefined, so I'm > technically in compliance. The temptation is to do what was asked, then on > close pop up a "Were you sure?" dialog, but that's mean. I guess I could use > this to set the appropriate entry fields if doing so makes sense, but the > easiest approach is to block setting any headers that would be consumed by > the tar implementation when reading. -- This message was sent by Atlassian JIRA (v6.3.15#6346)