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