[VOTE] Release Compress 1.20 based on RC2

The only change compared to RC1 is one to a unit test which wouldn't pass unless you already had PAX Exam in your local mvn repo. Compress 1.20 RC2 is available for review here: https://dist.apache.org/repos/dist/dev/commons/compress/ (svn revision 37873) The tag is here:

[CANCEL] Release Compress 1.20 Based on RC1

Hi all as Rob pointed out one of Compress' tests based on Pax Exam fails unless you happen to have built it once before Maven Central started enforcing TLS. This is fixed in master and I'll tag a RC2 and call for a new vote. Probably tomorrow. Thanks Stefan

Re: [VOTE] Release Compress 1.20 Based on RC1

On 2020-02-03, Rob Tompkins wrote: > I'm fairly indifferent. I would minimally state it in the release > notes that test fails with that. After having slept over it, I think it is awkward that a build on a fresh machine won't work. I'll cancel the vote. > If you want, I'm happy to RC for

Re: [VOTE] Release Compress 1.20 Based on RC1

On 2020-02-03, Stefan Bodewig wrote: > On 2020-02-03, Rob Tompkins wrote: >> If you declare your .m2 directory to be somewhere else, do you see the same >> failure? > I do. > It looks as if there was an option to explicitly set remote > repositories, I'll try that. h

Re: [VOTE] Release Compress 1.20 Based on RC1

On 2020-02-03, Rob Tompkins wrote: > If you declare your .m2 directory to be somewhere else, do you see the same > failure? I do. It looks as if there was an option to explicitly set remote repositories, I'll try that. Stefan

Re: [VOTE] Release Compress 1.20 Based on RC1

On 2020-02-03, Rob Tompkins wrote: > I’m not sure what changed between yesterday and today, but it seems that the > org.apache.commons.compress.OsgiTest is failing due to a 501 being returned > from >

Re: [VOTE] Release Compress 1.20 Based on RC1

this is what you get when you copy-paste from the release instructions :-) > This vote will close no sooner that 72 hours from now, > i.e. sometime after 04:00 UTC 31-March 2010 i.e. sometime after 16:00 UTC 05-Feb-2020 Stefan

[VOTE] Release Compress 1.20 Based on RC1

This time there are not so many bugs but significant improvements that people are waiting to get their hands on. Compress 1.20 RC1 is available for review here: https://dist.apache.org/repos/dist/dev/commons/compress/ (svn revision 37832) The tag is here:

Re: [commons-compress] branch master updated: one more javadoc warning

On 2020-01-26, Gary Gregory wrote: > On Sun, Jan 26, 2020, 07:39 wrote: >>+ * @return the parsed PAX header > Plural? Not sure. I believe it is a single PAX header block holding multiple header variables - while the code calls those header variable headers to make things more confusing.

[compress] Towards a 1.20 Release

Hi all I'm trying to make the builds work on Jenkins and intend to cut a new COmpress release soon. Right now I don't see any chance of understanding COMPRESS-494 or COMPRESS-500 and would address 501 and 502 after the release. Also I'd like to postpone the pack200 issue and mention that

Re: [compress] What to do with Pack200?

On 2020-01-05, Gary Gregory wrote: > Is Pack200 100% Java? Even if not, I think it would be neat to bring it in > from Apache Harmony as a new module. What Emmanuel says. > I think we should consider converting compress into a multi-module > project and avoid hard dependencies. For folks who

Re: [compress] What to do with Pack200?

On 2020-01-04, Gary Gregory wrote: > Java has a service leader mechanism for that. No sense in duplicating it. Compress already supports that, and IIRC you've added that yourself :-) Stefan - To unsubscribe, e-mail:

Re: [compress] What to do with Pack200?

On 2020-01-04, Emmanuel Bourg wrote: > Le 02/01/2020 à 11:06, Stefan Bodewig a écrit : >> Any other ideas? > The removal of pack200 isn't an issue for the upcoming release yet since > we still target Java 7. For now this is just an issue with the CI using > Java 14+.

Re: [compress] What to do with the changed OSGi Bundle Name?

On 2020-01-02, Oliver Heger wrote: > The change of the bundle name does not necessarily break all OSGi users. > AFAIK, the recommended way to use an OSGi bundle is to import the > packages, not to require a specific bundle - this use case would not be > affected by the change of the bundle name.

Re: [compress] What to do with Pack200?

On 2020-01-02, Bruno P. Kinoshita wrote: > I think if we are going to release it soon, the only option to support java > 14+ the would be to remove it. Tell users it may be added back later either > as-was or as a separate artefact. If we want to cut a new release soon, we can just tell people

[compress] What to do with Pack200?

Hi our travis build also uses the combination - dist: trusty jdk: openjdk-ea which has started to use OpenJDK 14 a while ago and our build has been failing there ever since. The reason is https://openjdk.java.net/jeps/367 - the whole Pack200 stuff has been removed without any

[compress] What to do with the changed OSGi Bundle Name?

Hi all due to a change in the parent POM the Bundle-SymbolicName of the commons-compress JAR changed from org.apache.commons.compress to org.apache.commons.commons-compress with version 1.18. So we've had a lot of releases up to 1.17 with one name and two newer releases with a different name in

Re: [Compress]Discussion about COMPRESS-499

On 2019-12-19, Peter Lee wrote: > Hi all. > A recent issue COMPRESS-499( > https://issues.apache.org/jira/projects/COMPRESS/issues/COMPRESS-499) > discussed about a potential problem in SeekableInMemoryByteChannel. > Based on the java docs( >

[all] Heads-Up, watch your OSGi Bundle Names

Hi all I've started to look into https://issues.apache.org/jira/browse/COMPRESS-498 which (correctly) points out that Compress 1.18 has changed the OSGi coordinates over the previous versions. The symbolic name is defined inside the parent POM. In Parent 46 this has been

Re: [All] Using "SemVer"?

On 2019-10-18, Gilles Sadowski wrote: > My point/question was whether we do not already follow it. We don't, at least not in all components. Quite a few of our components don't have a patch number at all and they sometimes create minor releases that would be patch releases if we followed

Re: [All] Using "SemVer"?

On 2019-10-18, Gilles Sadowski wrote: > In another thread, the question was asked whether "Commons" > follows "SemVer".[1] > It seems to me that we (informally) abide by the intended goal. > Why not state it explicitly (and make it a formal requirement for > a release)? To me it seems we have

Re: [Compress] BZip2 file object size?

On 2019-10-18, Gary Gregory wrote: > BZip2FileObject does not implement doGetContentSize() and always returns > -1, which causes VFS to blow up if you try to read. Can this kind of > content only be streamed? First a "I'm not an expert in the bzip2 file format" disclaimer. >From what I can tell

Re: [VOTE] Release Apache Commons Daemon 1.2.2 RC1

On 2019-09-30, sebb wrote: > On Mon, 30 Sep 2019 at 10:25, Stefan Bodewig wrote: >> On 2019-09-29, sebb wrote: >>> On Sun, 29 Sep 2019 at 17:21, Matt Sicker wrote: >>>> Projects that have a configure script usually include that in the source >>>> dis

Re: [VOTE] Release Apache Commons Daemon 1.2.2 RC1

On 2019-09-29, sebb wrote: > On Sun, 29 Sep 2019 at 17:21, Matt Sicker wrote: >> Projects that have a configure script usually include that in the source >> distribution but not in the source repository (at least for autotools >> users). > But is that correct? This is what people expect. As

[compress] COMPRESS-491 InputStream#read returning 0

Hi all https://issues.apache.org/jira/browse/COMPRESS-491 correctly points out that some of our InputStream implementantions violate the contract of the read(byte[]...) pair of methods. They may return 0 instead of trying to block and read data. Digging deeper this really only seems to happen on

Re: [bcel][all] GitHub Actions for Maven builds

On 2019-08-31, Gary Gregory wrote: > On Sat, Aug 31, 2019 at 10:58 AM Gilles Sadowski > wrote: >> Links returns "404". > Works for me, anyone else? Only works if you are logged in - an probably a member of the apache organization. github returns 404 for links you are not allowed to see.

[CVE-2019-12402] Apache Commons Compress denial of service vulnerability

://commons.apache.org/proper/commons-compress/security-reports.html Stefan Bodewig -BEGIN PGP SIGNATURE- Version: GnuPG v1 iEYEARECAAYFAl1lgKIACgkQohFa4V9ri3IsSwCg0tYlFA5WXy6EuHFtRjsbVofR WjAAn2uNwEELGpIR2JiRO+jEAyxQJZvV =Ds0n -END PGP SIGNATURE

[ANN] Apache Commons Compress 1.19 Released

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [Re-Sending with fixed subject, sorry] The Apache Commons Team is pleased to announce the release of Apache Commons Compress 1.19. Apache Commons Compress software defines an API for working with compression and archive formats. These include:

[ANN] Apache Commons Compress 1.18 Released

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 The Apache Commons Team is pleased to announce the release of Apache Commons Compress 1.19. Apache Commons Compress software defines an API for working with compression and archive formats. These include: bzip2, gzip, pack200, lzma, xz, Snappy,

[RESULT] Release Compress 1.19 Based on RC1

Hi all with binding +1s by Gary Gregory Bruno P. Kinoshita Rob Tompkins and my own implicit +1 the vote has passed. I'll proceed with publishing the release artifacts and will announce the release after mirrors had a bit of time to catch up. Many thanks to those who had a look at the release

[VOTE] Release Compress 1.19 Based on RC1

It's been more than a year since the last release of Commons Compress and it is about time to get the fixes and enhancements out of the door. Compress 1.19 RC1 is available for review here: https://dist.apache.org/repos/dist/dev/commons/compress/ (svn revision 35357) The tag is here:

[compress] Closing in on the Next Release

Hi all while I have a bit of time at hand I'd like to use that and cut a new release of Compress. On my list of things I intend to do for the release: https://issues.apache.org/jira/browse/COMPRESS-485 - make the change to ParallelScatterZipCreator#submit backwards compatible. japicmp doesn't

Re: [compress] Need Feedback for COMPRESS-479

On 2019-08-14, Matt Sicker wrote: > Yes, I think you understand us. A strategy pattern with default sensible > strategies to choose. Done now. I'm going to tweak the implementation a little more but the API of ExtraFieldParsingBehavior seems to work quite well. Thanks Stefan

Re: [compress] Need Feedback for COMPRESS-479

On 2019-08-13, Matt Sicker wrote: > The enum makes sense. Are there any feasible ways to, say, configure > some sort of handler class that can implement logic around unknown > fields? Not really. The only extension point here currently is plugging in your own implementations of ZipExtraField via

[compress] Need Feedback for COMPRESS-479

Hi https://issues.apache.org/jira/browse/COMPRESS-479 highlights a problem where our zip reading code may reject an archive because it uses extra fields that we only partially understand. In this case the archive is not a real one, but it is easy to envision extra fields in the wild that use more

Re: [commons-compress] branch master updated: try to get our JDK zoo working in Travis

On 2019-08-07, Gary Gregory wrote: > I think you are missing openjdk13, openjdk-ea now maps to 14 IIRC. If so then it hasn't been in there before my change either :-) Stefan - To unsubscribe, e-mail:

[compress] resource leak in example code

Hi all https://issues.apache.org/jira/browse/COMPRESS-486 highlights a problem of the code inside the example package. The methods with stream or channel arguments create wrapper objects around said streams or channels and never close them. They don't close them because this in turn would close

Re: Build failed in Jenkins: Commons-Compress JDK-Matrix Build » JDK 1.7 (latest) #799

After Compress has been upgraded to Parent 48 the JDK 7 build started to fail as the new version of the bnd plugin has been compiled with -target 8, or so it seems. I'll downgrade the bnd plugin for compress for now. Stefan -

Re: [compress] Java 7 to Java 8

On 2019-04-16, Gary Gregory wrote: > On Tue, Apr 16, 2019 at 9:39 AM Stefan Bodewig wrote: >> As long as using Java 7 doesn't hurt us, I don't see any reason to >> update. > Using old dead versions of Java turns off potential contributors IMO. > You have to go d

Re: [compress] Java 7 to Java 8

On 2019-04-16, Gary Gregory wrote: > Based on a recent JIRA, it seems like using Java 8 in [compress] would be > helpful. I'd +1 that it bumping the dependency turned out to be really useful. I'm not convinced, yet. > Plus, it's 2019 and Java 12 is out. As long as using Java 7 doesn't hurt us,

Re: [ALL][RFC] Github subjects don't contain the repo name

On 2019-03-01, sebb wrote: > [GitHub] (commons-io) zsoltii opened a new pull request #74: Add new > function: byteCountToDisplayRoundedSize > WDYT? I don't really care for the exact subject as long as the name of the repo gets added :-) +1 Stefan

Re: [VOTE] Redirect github notifications to issues@

On 2019-02-19, Marcelo Vanzin wrote: > I'm opening a vote based on recent discussions about the extra noise > generated by github updates going to dev@. So please vote: > - +1 to redirect github updates of all commons repos to the issues@ list > - -1 to keep things as is > If the vote passes,

Re: Multiplicity of GitBox messages

On 2019-02-08, Eric Barnhill wrote: > Is it the consensus outcome for the dev list, that we all receieve a large > amount of GitBox postings? I think they are just hitting the wrong mailing list. We've had notifications of all commits for a long time. In fact this is a key ingredient for peer

Re: [All][Math] No ML, no JIRA; GitHub only?

On 2019-01-25, Gilles Sadowski wrote: > By chance, I opened and read an automated mail from "GitBox" whose > subject line did not contain anything that would usually prompt a > reaction from me.[1] [Sidenote: I also find it annoying that the messages no longer contain the name of the repository

Re: [VOTE][LAZY] move commons git-wip repos to gitbox

+1 Stefan - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org

Re: [1/3] commons-compress git commit: COMPRESS-470 make sure all ScatterZipOutputStreams are closed

On 2018-11-18, Gary Gregory wrote: > ensureStreamsAreClosed() seems like an over the top name. Why not simply > closeAll()? Or close(). Because I've got a track record for choosing bad names to defend :-) Stefan - To

Re: [ALL] SHA256/512 hashes

On 2018-08-31, Benedikt Ritter wrote: > Please note, that all what you are saying is just your opinion on how a > release should be created. The maven team clearly has another opinion on > that. Both are valid. +1 > Our release process is cumbersome and fragile leading to all release > looking

Re: [ALL] SHA256/512 hashes

On 2018-08-25, Gilles wrote: > On Sat, 25 Aug 2018 14:06:44 +0100, sebb wrote: >> On 25 August 2018 at 09:48, Stefan Bodewig >> wrote: >>> On 2018-08-25, Gary Gregory wrote: >>>> Is what you are referring to for a different purpose? >>> Probabl

Re: [ALL] SHA256/512 hashes

On 2018-08-25, Gary Gregory wrote: > Our release plugin already creates SHA256 and SHA512 files and saves those > to Apache's dev/dist for an RC as part of creating an RC, pushing it to > Nexus and dist/dev. > Is what you are referring to for a different purpose? Probably for those who don't

Re: Use of Java 8 features in the commons

On 2018-08-23, Eitan Adler wrote: > As the various commons libraries switch to Java 8 minimum what do > people thinking of mechanical migrations to use new languages > features. For example making of use of method references, stream API, > etc. Is this something we should only do when we're

Re: [parent] change in commons.scmPubUrl in Parent 47

On 2018-08-22, Rob Tompkins wrote: >> On Aug 22, 2018, at 9:03 AM, Stefan Bodewig wrote: >> On 2018-08-22, Rob Tompkins wrote: >>>> On Aug 22, 2018, at 1:47 AM, Benedikt Ritter wrote: >>>> Hi, >>>> I don't understand this discussion. Change

Re: [parent] change in commons.scmPubUrl in Parent 47

On 2018-08-22, Rob Tompkins wrote: >> On Aug 22, 2018, at 1:47 AM, Benedikt Ritter wrote: >> Hi, >> I don't understand this discussion. Changes in Commons Parent have broken >> the commons-compress build. So we should either roll this changes back or >> those who need the changes in commons

Re: [parent] change in commons.scmPubUrl in Parent 47

mail.com>: >> On Thu, Aug 16, 2018 at 10:27 AM Stefan Bodewig >> wrote: >>> On 2018-08-16, Gary Gregory wrote: >>>> I've use the release plugin a bunch without trouble. You might want to >>> see >>>> how other POMs are configured, for exampl

Re: [ALL] Make checkstyle:check part of default maven goal?

On 2018-08-20, Benedikt Ritter wrote: > one thing I always have to do when preparing a release is to fix all the > checkstyle and findbugs errors. This step could be eliminated if we added > checkstyle:check and findbugs:check to the maven default goal. This way it > would be executed on CI

Re: [parent] change in commons.scmPubUrl in Parent 47

On 2018-08-16, Gary Gregory wrote: > I've use the release plugin a bunch without trouble. You might want to see > how other POMs are configured, for example [dbcp]. The same way as Compress (no commons- prefix), I've got no idea why running site-deploy should work for it. You use the release

[parent] change in commons.scmPubUrl in Parent 47

Hi all with http://svn.apache.org/viewvc/commons/proper/commons-parent/trunk/pom.xml?r1=1831599=1832339 a component's site is expected to be a in subdirectory named after ${commons.componentTd} - it used to be the artifactId. A quick look at

[CVE-2018-11771] Apache Commons Compress 1.7 to 1.17 denial of service vulnerability

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 CVE-2018-11771: Apache Commons Compress 1.7 to 1.17 denial of service vulnerability Severity: Low Vendor: The Apache Software Foundation Versions Affected: Apache Commons Compress 1.7 to 1.17 Description: When reading a specially crafted ZIP

[ANN] Apache Commons Compress 1.18 Released

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 The Apache Commons Team is pleased to announce the release of Apache Commons Compress 1.18. Apache Commons Compress software defines an API for working with compression and archive formats. These include: bzip2, gzip, pack200, lzma, xz, Snappy,

[RESULT] Release Compress 1.18 based on RC1

Hi all with +1s by Gary Gregory Rob Tompkins Bruno P. Kinoshita my own implicit one and no other votes, the vote has passed. I'll proceed with publishing the artifacts and announce the release after the mirrors had time to catch up. Many thanks to all who vetted the release Stefan

Re: [VOTE] Release Compress 1.18 based on RC1

On 2018-08-14, Rob Tompkins wrote: >> On Aug 14, 2018, at 12:26 AM, Stefan Bodewig wrote: >>> On 2018-08-14, Rob Tompkins wrote: >>> Must fix during artifact promotion: >>> (1) Signature files contain more than the correct signatures (note the >>> c

Re: [VOTE] Release Compress 1.18 based on RC1

On 2018-08-14, Rob Tompkins wrote: > Must fix during artifact promotion: > (1) Signature files contain more than the correct signatures (note the > contents below): This is the well known default format of GNU textutil's sha256sum. Is this really a problem? I'm not aware of any policy that

Re: [VOTE] Release Compress 1.18 based on RC1

On 2018-08-13, Gary Gregory wrote: >> From src zip: ASC, SHA256 OK. > In the future we should only publish SHA512 hashes. can do. > Site typo: "It is no possible to specifiy various parameters for Zstd > output." > -> "It is *now *possible to *specify *various parameters for Zstd output."

[VOTE] Release Compress 1.18 based on RC1

Hi all, I would like to release Compress 1.18. Compress 1.18 RC1 is available for review here: https://dist.apache.org/repos/dist/dev/commons/compress/ (svn revision 28684) The tag is here: tag 1.18-RC1 on commit b95d5cde

Re: [parent] japicmp problems

On 2018-08-12, Gary Gregory wrote: > Whatever you do, please document in the parent what does what and how a > component should enable and disable the report. http://svn.apache.org/viewvc/commons/proper/commons-parent/trunk/pom.xml?r1=1837064=1837920 Actually, you don't have to do anything. It

Re: [parent] japicmp problems

On 2018-08-12, Rob Tompkins wrote: > I agree with this statement generally. That said, this doesn’t > surprise me that I made this error because japicmp is minimally > cumbersome to work with. I didn't mean to blame you, sorry if you received it that way. Fully agreed that japicmp is a pain, but

[parent] japicmp problems

Hi while building the site for Compress the japicmp report was empty, taking a closer look there is a little warning that says "skipping report because skip is set to true" which in fact it is. http://svn.apache.org/viewvc/commons/proper/commons-parent/trunk/pom.xml?r1=1832506=185 added this

Re: [compress] Cutting 1.18 soon

On 2018-08-11, Gary Gregory wrote: > The reports should include RAT. https://stefan.samaflost.de/staging/commons-compress-1.18/rat-report.html has been there all the time :-) Stefan - To unsubscribe, e-mail:

Re: [compress] Cutting 1.18 soon

On 2018-08-11, Gary Gregory wrote: > The reports should include RAT. > The japicmp report is blank, either fix or replace with Clirr. strange, I haven't changed anything, so the disappearing RAT report and the empty japicmp must be due to Compress upgrading commons-parent. I'll have to

[compress] Cutting 1.18 soon

Hi all I intend to create a RC for Compress 1.18 the coming days, I've uploaded a recent site build (so people can look at Jacoco and whatnot) to https://stefan.samaflost.de/staging/commons-compress-1.18/ Cheers Stefan

Re: [compress] close() and writing invalid streams

close() methods that need them. > On Thu, Jun 28, 2018 at 3:54 AM Stefan Bodewig wrote: >> Hi all >> https://issues.apache.org/jira/browse/COMPRESS-457 raises an issue that >> I vaguely recall we've talked about in the past but I may be wrong. >> Almost all our Ou

[compress] close() and writing invalid streams

Hi all https://issues.apache.org/jira/browse/COMPRESS-457 raises an issue that I vaguely recall we've talked about in the past but I may be wrong. Almost all our OutputStream close methods go along the lines of public void close() throws IOException { finishFormatSpecificStuff();

Re: [ANN] Apache Commons Compress 1.17 Released

On 2018-06-05, Scott Langley wrote: > Have you decided whether you will now switch development to the 2.0 branch The branch has basically been me tossing ideas around but it has never gotten any traction inside the dev team. > or otherwise begin accepting Java 8 code in order to take advantage

[ANN] Apache Commons Compress 1.17 Released

, or suggestions for improvement, see the Apache Commons Compress website: http://commons.apache.org/compress/ Stefan Bodewig, on behalf of the Apache Commons community -BEGIN PGP SIGNATURE- Version: GnuPG v1 iEYEARECAAYFAlsUJ8cACgkQohFa4V9ri3Jt0ACgxxCmC8KTY+GAK3FWGtwga/bZ

[RESULT] Release Compress 1.17 based on RC1

Hi all With +1s by Gary Gregory and Oliver Heger as well as my own implicit one the vote has passed. I'll kick off the usual process of publishing the artifacts, waiting for mirrors and sending out the announcement. Stefan -

Re: [VOTE] Release Compress 1.17 based on RC1

On 2018-05-31, wrote: > There are two typos in the release notes for 1.17: > wit whne Thanks! Fixed in master (thus will be fixed when I generate the site). And I'll fix the release notes in dist when publishing the artifacts. Stefan

[VOTE] Release Compress 1.17 based on RC1

Hi all, I would like to release Compress 1.17. Compress 1.17 RC1 is available for review here: https://dist.apache.org/repos/dist/dev/commons/compress/ (svn revision 27187) The tag is here: tag 54e86f951 on commit d9993f8f

Re: [io] Black Duck apparently sees vulnerability in 2.5

On 2018-05-17, Pascal Schumacher wrote: > Am 16.05.2018 um 08:24 schrieb Stefan Bodewig: >> Also, would there be any reason to not cut a new release from master? I >> mean is there any work in progress that needs to be finished? > I think a new release from master can be done

Re: [io] Black Duck apparently sees vulnerability in 2.5

On 2018-05-16, Otto Fowler wrote: > I believe all security related issues and vulnerabilities need to be > handled privately by the PMC for the project. > Has this issue gone through he PMC? The "issue" is public discussion in a JIRA issue, it is public knowledge anyway. Stefan

Re: [io] Black Duck apparently sees vulnerability in 2.5

On 2018-05-16, Otto Fowler wrote: > Is there a PMC for IO? Sure, IO is a component overseen by the Apache Commons PMC. Maybe I should also point at http://commons.apache.org/security.html ? Stefan - To unsubscribe, e-mail:

[io] Black Duck apparently sees vulnerability in 2.5

Hi all https://issues.apache.org/jira/browse/IO-559 says BlackDuck would call IO 2.5 vulnerable because of this issue - so far I've not been able to verify this claim. I guess it is because of IO-556 that has been closed as a duplicate of IO-559. There is a PR (by me) to fix the bug

Re: [compress] Thinking about 1.17 release

On 2018-05-10, Gary Gregory wrote: > Maybe "User Guide" is better than "Examples". Sounds good. > I think we would really help out our users if the template in "Common > Extraction Logic" would be followed by a "reference implementation", even > if that implementation only works on one OS. >

[compress] Thinking about 1.17 release

Hi all there haven't been any really big changes in master but I think Tika is waiting for COMPRESS-445 to get into a release so they can adapt their ZIP bomb detection mechanisms after the existing ones have been broken by Java10. Personally I plan to add unit tests to the archivers.examples

Re: [compress] High Level API / Examples

On 2018-05-05, Gary Gregory wrote: > Should we give a VFS example on the Compress site? I'd probably want to link to existing examples on the VFS site - assuming there are any - as otherwise we'd need to adjust our examples if things change on the VFS side of things. Stefan

[compress] High Level API / Examples

Hi all sorry to bother you again. It seems we won't be able to figure out what the high level API we'd want to provide should look like any time soon, or even whether we want to provide one at all. If Commons VFS already provides the high level API that is needed, there isn't anything we need to

Re: [compress][POLL] High Level API

On 2018-05-02, Torsten Curdt wrote: > So far I didn't think the current API is so horrible. I wouldn't call it horrible. My ideas about things that should be different and have been epressed in the compress-2.0 branch I started years ago. To me the most important things I'd want to change are

Re: [compress][POLL] High Level API

On 2018-05-02, Gary Gregory wrote: > I'm all for providing a high-level API. That's fine. > I would like a high-level statement first though concerning choices we have > or have not considered. > - The high level API is Commons VFS. Why? Why not? > - The high level API is Java IO File System.

Re: [compress][POLL] High Level API

On 2018-05-01, Torsten Curdt wrote: > https://github.com/apache/commons-compress/blob/master/ > src/main/java/org/apache/commons/compress/archivers/Archiver.java > Is tiny compared the whole lots of > https://github.com/apache/commons-compress/tree/master/ >

Re: [compress] High Level API for Archives

On 2018-05-01, Matt Sicker wrote: > On 1 May 2018 at 12:23, Torsten Curdt wrote: >> That smell must be something else ;) >> Just have a look at the dependencies >> https://github.com/apache/commons-compress/blob/master/pom.xml#L69 > Right, I see several dependencies marked

Re: [compress][io] Avoid InputStream#skip?

Hi all as skip throwing exception is uncommon enough that it hasn't been reported before in Compress and only seems to happen if you use streams like System.in maybe we can solve the issue by providing a wrapper stream that overrides skip so that it uses read and advice people to use that if they

[compress][POLL] High Level API

Hi all right now the master branch contains two different ideas of hign level APIs: * https://github.com/apache/commons-compress/blob/master/src/main/java/org/apache/commons/compress/archivers/Archiver.java and Expander in the same package *

Re: [compress] High Level API for Archives

On 2018-04-30, Matt Sicker wrote: > Not sure if it helps much, but based on my experience in writing a totally > unrelated library from scratch in Java 8, I feel as though the use of > default interface methods would help tremendously in providing a nice API > while maintaining BC. I may have

Re: [compress] High Level API for Archives

On 2018-04-29, Matt Sicker wrote: > On 29 April 2018 at 06:24, Stefan Bodewig <bode...@apache.org> wrote: >> I'm not sure what you mean by modular in this context. > As in one module/jar per implementation. One module for a zipfs, one for an > sshfs, etc., instead

Re: [compress] High Level API for Archives

On 2018-04-29, Stefan Bodewig wrote: > If this is something that looks acceptable I'll add expansion and remove > the other two classes. Just went ahead and added expansion as well, which doesn't mean it has to stay.

Re: [compress] High Level API for Archives

Hi all I've introduced a whole lot of infrastructure code with https://github.com/apache/commons-compress/commit/f62c523154dfedcf49a87a865db545bb8c55e795 but the interface now looks nicer to me, in particual see try (Sink sink = FileToArchiveSink.forFile(args[1], new File(args[2]))) {

Re: [compress] High Level API for Archives

On 2018-04-26, Oliver Heger wrote: > Recently I had a closer look at streaming libraries like Akka Streams. > So I had the idea to model the problem in a similar way: > An archive or deflate operation could be modeled by a flow from a source > via some filtering or modifying stages to a sink.

Re: [compress] High Level API for Archives

On 2018-04-26, Matt Sicker wrote: > If it helps in design, the most promising approach I found was to integrate > with the java.nio.file API. However, that turns into a sort of hybrid > library between VFS and Compress. The current compress-2.0 branch - which is something that I haven't fully

Re: [compress] High Level API for Archives

On 2018-04-24, sebb wrote: > On 23 April 2018 at 20:48, Torsten Curdt wrote: >> TBH I am not such super big fan of adding and maintaining a high level >> API at this stage. >> You will never find the right abstraction that everyone is happy with. >> If you would - well, then

Re: [compress] Need Help With PAX Exam Tests

On 2018-04-25, Robert Munteanu wrote: > It is definitely possible to use a single project with Pax-Exam. Take a > look for instance at > https://github.com/cschneider/osgi-testing-example This is exactly what I needed, many thanks! I've committed a mostly empty unit test that fails if I

Re: [compress] Need Help With PAX Exam Tests

On 2018-04-25, Robert Munteanu wrote: > Hi Stefan, > On Wed, 2018-04-25 at 18:41 +0200, Stefan Bodewig wrote: >> On 2018-04-24, Gary Gregory wrote: >>> You should take a look at the Log4j 2 module log4j-osgi. We do some >>> "bare >>> bones let's mak

Re: [compress] Need Help With PAX Exam Tests

On 2018-04-24, Gary Gregory wrote: > You should take a look at the Log4j 2 module log4j-osgi. We do some "bare > bones let's make sure we can load modules" tests using both Eclipse Equinox > and Apache Felix. AFAICT this also required the bundle to be built in advance - which is logical.

<    1   2   3   4   5   6   7   8   9   10   >