Re: [compress] Update Java version

On 2016-04-08, Gary Gregory wrote: > I think it would be good to use try-with-resources in our tests and for > users too. > Thoughts on updating to Java 7? Or, gasp, Java 8? I've had to fix some Java6ism a couple of times after applying patches like @Override on interface implementations - I

Re: Jenkins build is back to normal : Commons-Compress-Windows #13

On 2016-04-08, sebb wrote: > The Windows issues all seem to have been caused by the move to Git. > It appears that the move did not preserve EOL or binary file settings. > So some .ar files were being corrupted on Windows. > And some sample files were being converted to CRLF so they did not >

Re: [compress] test failures in master

On 2016-04-07, sebb wrote: > On 7 April 2016 at 10:19, Stefan Bodewig <bode...@apache.org> wrote: > I set up > https://builds.apache.org/job/Commons-Compress-Windows/ Thanks! > Most tests failed with > java.lang.OutOfMemoryError: Java heap space > If someone can sugg

Re: [compress] test failures in master

On 2016-04-06, Gary Gregory wrote: > Is this a Windows only issue? Likely. This could be testcases that are sensitive to line-ends. Stefan - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands,

[ANN] Apache Commons Compress 1.11 Released

directory. Issue: COMPRESS-321. For complete information on Commons Compress, including instructions on how to submit bug reports, patches, or suggestions for improvement, see the Apache Commons Compress website: http://commons.apache.org/compress/ Stefan Bodewig, on behalf of the Apache Commons

Re: [VOTE] Release Compress 1.11 Based on RC2

On 2016-04-03, Matt Sicker wrote: > I thought Infra disabled the ability to delete tags in git anyways unless > they reverted that recently. Only tags under rel/ cannot get deleted, all others can. Therefore final release tags should be created as rel/THE_TAG_NAME. Stefan

[compress] bytesRead and bytesWritten in our streams

Hi while looking into generalizing COMPRESS-207 I realized our CompressorOutputStreams didn't provide bytesWritten - unlike the ArchiverOutputStreams - while the InputStreams all provide a bytesRead. And I also realized I didn't really know what bytesRead actually meant - bytes read from the

Re: [VOTE] Release Compress 1.11 Based on RC2

On 2016-04-03, sebb wrote: > On 3 April 2016 at 06:01, Stefan Bodewig <bode...@apache.org> wrote: >> On 2016-04-03, Stian Soiland-Reyes wrote: >>> Could we delete the tag 1.11-RC1 now? >> AFAIR we keep all tags, even those for failed RC votes. > Sometimes

Re: [VOTE] Release Compress 1.11 Based on RC2

On 2016-04-03, Stian Soiland-Reyes wrote: > Could we delete the tag 1.11-RC1 now? AFAIR we keep all tags, even those for failed RC votes. Stefan - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional

[VOTE] Release Compress 1.11 Based on RC2

Hi all due to a packaging glitch I had to re-roll the release. It is based on the same commit that was used for RC1, so both tags refer to the same commit. For this reason I haven't even re-created the site. Compress 1.11 RC2 is available for review here:

[CANCEL][VOTE] Release Compress 1.11 Based on RC1

On 2016-04-01, Stian Soiland-Reyes wrote: > You didn't include the checksums in the mail, but the svn revision > 12931 matched. Never did, can certainly do that in the future. > My vote: -1 (Non-binding) > Due to additional file commons-compress-1.11-SNAPSHOT.jar Ouch. I have no idea how this

Re: [VOTE] Release Compress 1.11 Based on RC1

On 2016-03-30, Gary Gregory wrote: > "Foo 1.2 RC1 is available for review here:" > ;-) I plead guilty on the crime of copy-paste reuse. Stefan - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional

[VOTE] Release Compress 1.11 Based on RC1

Hi all Foo 1.2 RC1 is available for review here: https://dist.apache.org/repos/dist/dev/commons/compress/ (svn revision 12931) Maven artifacts are here: https://repository.apache.org/content/repositories/orgapachecommons-1144/org/apache/commons/commons-compress/1.11/ Details of

Re: [compress] progress monitoring

On 2016-03-28, Emmanuel Bourg wrote: > Le 27/03/2016 18:41, Stefan Bodewig a écrit : >> Is this a feature we generally want to see in compress? And if so, does >> the branch make sense or should we tackle this in a different way? > I like the idea of progress tracking, and

Re: [compress] 1.11 RC in about two weeks?

Hi all I don't intend to change anything in master before the 1.11 release anymore, so I've created a snapshot site at http://stefan.samaflost.de/staging/COMPRESS-1.11/ that you can use to look at the reports. If you see anything that should get addressed, please yell. Same if you want to add

[compress] progress monitoring

Hi all https://issues.apache.org/jira/browse/COMPRESS-207 asks for progress tracking inside BZip2CompressorInputStream. As such I think the request is to narrow (why add it for bzip2 but not gzip2?) and I created the branch COMPRESS-207 for a prototypical implementation. This is incomplete since

Re: [compress] Trying to Pick up Compress2 Again

On 2016-03-23, Stefan Bodewig wrote: > On the API side Java8 is only used for java.time.Instant (for the last > modified time of an entry). In addition I've used Java7's > SeekableByteChannel for random access and AutoCloseable in place of > Closeable. Actually I've moved away

[compress] Need Help With Jenkins Failure

Hi the Compress build has started failing about a week ago and I can't seem to figure out why. The log says "compilation failure", but I don't see any. I've thrown in a -X for good measure, see https://builds.apache.org/job/Commons-Compress/66/consoleFull any ideas? The first failing build

[compress] Trying to Pick up Compress2 Again

Hi all after more than two years of a hiatus I'd like to pick up the compress2 branch again. Back then we decided to embrace Java7 and I've taken the bold step of moving on to Java 8 now. On the API side Java8 is only used for java.time.Instant (for the last modified time of an entry). In

Re: [compress] 1.11 RC in about two weeks?

sftp only (and sftp doesn't support recursive operations). Stefan > Gary > On Tue, Mar 15, 2016 at 12:50 PM, Stefan Bodewig <bode...@apache.org> wrote: >> Hi all >> it looks as if we had a decent set of changes for a new release. There >> are a few ongoing things

Re: Request to add into Apache Commons Wiki contributors group

Hi Uma On 2016-03-15, Gangumalla, Uma wrote: > I would like to post Apache Commons Crypto proposal in Apache Commons > Wiki page. For this could you please add me into Wiki contributors > group? Should be done. Cheers Stefan

[compress] 1.11 RC in about two weeks?

Hi all it looks as if we had a decent set of changes for a new release. There are a few ongoing things that I know of, but haven't got a clear idea of when they might be done: * Damjan's changes to allow for non-File reading of ZIP (and with some effort of 7zip archives) - COMPRESS-327 *

Re: [compress] BZip2 block size is invalid

On 2016-02-21, Gary Gregory wrote: > Caused by: java.io.IOException: BZip2 block size is invalid > at > > org.apache.commons.compress.compressors.bzip2.BZip2CompressorInputStream.init(BZip2CompressorInputStream.java:251) Are you sure this is a valid bzip2 file - i.e. can command

Re: [commons-compress] traditional zip encryption patch to come

On 2016-02-16, Bear Giles wrote: > I can create test files. (I still need to create some PKWare test files as > well...). This would be good. > I also need to figure out a way to extract the encrypted content to I > can verify my implementation of the crypto logic itself. I think that > will

Re: [commons-compress] traditional zip encryption patch to come

On 2016-02-15, Bear Giles wrote: > We discussed adding support for the traditional zip encryption algorithm a > while back. IIRC the concensus was loosely against it since it's so weak > and we don't want to mislead people. I'm pretty sure we should ad a big warning about the quality of

Re: commons-compress git commit: Changes to allow byte-for-byte replication of Zip entries

On 2016-01-29, Torsten Curdt wrote: > Darn. OK. Will fix. Done now, I've also added your fix for COMPRESS-328. Cheers Stefan - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands,

Re: [VOTE] Form a separate TLP based on [math]

+0 since I'm not active in MATH Stefan On 2016-01-16, Phil Steitz wrote: > The discussion has thus far been generally favorable. I would like > therefore to put the proposal to split [math] out into a separate > TLP to a VOTE. Assuming a favorable vote, we can discuss how to go > about doing

Re: [COMPRESS] PKWare header questions

On 2015-12-13, Bear Giles wrote: > 1. I created the PKWareExtraHeader as a marker - it should make it clear > that the headers will only be present in PKWare-created files and everyone > else can ignore them. OK, understood. I'll add a few sentences as javadocs. > 2. ExtraFieldUtils and Tests -

Re: [COMPRESS] Problems with Git transfer - two branches (heads) missing?

On 2015-12-10, sebb wrote: > I was looking at the heads (branches) in the Git components, compared > with the branches in the original SVN copies (now read-only): > Compress appears to be missing 2 branches: > http://svn.apache.org/repos/asf/commons/_moved_to_git/compress/branches/ >

Re: [COMPRESS] pkware header id for crypto extensions

On 2015-09-04, Bear Giles wrote: > I just came across a press release that suggests that it is possible to > support AES encryption for zip files: > http://www.prnewswire.com/news-releases/pkware-announces-free-licensing-program-for-secure-ziptm-and-pkzip-reader-technologies-72382192.html I

Re: [VOTE] Release Commons Collections 4.1 Based on RC1

> Please review the release candidate and vote. > This vote will close no sooner that 72 hours from now, i.e. after 2400 > GMT 25-November 2015 +1 Stefan - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For

Re: [VOTE] Release Commons Collections 3.2.2 Based on RC3

On 2015-11-13, Thomas Neidhart wrote: > Please review the release candidate and vote. +1 Stefan - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org

Re: [VOTE] Release Commons Collections 3.2.2 Based on RC2

On 2015-11-11, Thomas Neidhart wrote: > Please review the release candidate and vote. +1 Stefan - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org

Re: [VOTE] Release Commons Collections 3.2.2 Based on RC2

On 2015-11-12, Phil Steitz wrote: >> On Nov 11, 2015, at 12:05 PM, Gary Gregory wrote: >> -1 > That is frankly ridiculous. Couldn't agree more. Stefan - To unsubscribe, e-mail:

Re: [VOTE] Release Commons Collections 3.2.2 Based on RC1

On 2015-11-09, Thomas Neidhart wrote: > in order to provide a work-around for the known remote code exploit via > java de-serialization of malicious InvokerTransformer instances, I would > like to start a vote to release Commons Collections 3.2.2 based on RC1. +1 Stefan

Re: [COMPRESS] Compress GUI?

On 2015-10-30, Roger Whitcomb wrote: > Any thoughts? Anyone who might be interested in helping with such a > project? TBH, I hate doing GUI stuff. :-) I can easily see that a GUI for Compress would be nice, though. If people want to work on a GUI and need help dealing with the Compress

Re: [COMPRESS] pkware header id for crypto extensions

On 2015-09-14, Bear Giles wrote: > I want to capture as much information as possible but the documentation is > a weird mixture of details and hand-waving. Some is detailed, some is > "compatible with the format used by the Microsoft CRYPTOAPI". How is > anyone supposed to use that if all they

Re: [COMPRESS] pkware header id for crypto extensions

Hi Bear sorry for the late reply. My spare time is currently severly limited but this should be getting better by the end of the month. On 2015-09-05, Bear Giles wrote: > I was just reminded of the risks of making assumptions. There's two > separate implementations of AES strong encryption -

Re: [COMPRESS] pkware header id for crypto extensions

On 2015-09-02, Bear Giles wrote: > Hi, I know that the implementation of the PKWARE AES crypto is subject to > license restrictions but is it possible to recognize the extension fields > so anyone scanning an unfamiliar file will at least know what the extra > field headers contain? I don't

Re: need some help

On 2015-09-02, Arsen Babakhanyan wrote: > I am interested in participating in some projects, but need some help. Welcome! > I don't know how to find currently active projects that are in development > or a project that needs help at all and the second problem help with > getting started as i am

Re: [RESULT] Move COMPRESS to git

Hi all https://git-wip-us.apache.org/repos/asf/commons-compress.git has been created and looks good. For the moment it is read-only but will soon be ready to be the primary SCM for Compress. Stefan - To unsubscribe, e-mail:

[continuum] svn - git for Compress, Lang

Hi I've never created an account for continuum. Could anybody with admin karma please change the SCM for Compress (and maybe fix the one for Lang while you are at it). Thanks Stefan - To unsubscribe, e-mail:

Re: [RESULT] Move COMPRESS to git

On 2015-08-26, Stefan Bodewig wrote: Progress will be reported back here. OK, svn has been cleaned uo and will get locked down, git is read-write and I've updated the site. Looks as if the migration was through now. Stefan

Re: [continuum] svn - git for Compress, Lang

On 2015-08-27, sebb wrote: Sorry, I failed to add either. The version of Continuum needs to be updated, see: https://issues.apache.org/jira/browse/BUILDS-100 I see, thanks Stefan - To unsubscribe, e-mail:

Re: [RESULT] Move COMPRESS to git

On 2015-08-26, Stefan Bodewig wrote: I'll start with figuring out what needs to get done and the open the INFRA tickets I suppose will become necessary. INFRA-10208 Stefan - To unsubscribe, e-mail: dev-unsubscr

[RESULT] Move COMPRESS to git

Hi all the vote has passed with +1s by Stefan Bodewig Torsten Curdt Gary Gregory Dave Brosius Oliver Heger Kristian Rosenvold Damjan Jovanovic Siegfried Goeschl Luc Maisonobe Jörg Schaible and no other votes. I'll start with figuring out what needs to get done and the open the INFRA tickets I

Re: [math] github pull requests

On 2015-08-25, Luc Maisonobe wrote: Le 25/08/2015 16:14, Stefan Bodewig a écrit : On 2015-08-25, Luc Maisonobe wrote: As the github pull request are not forwarded here, You know that you can enable automatic notifications? I don't recall the details - probably something involving a ticket

Re: [math] github pull requests

On 2015-08-25, Luc Maisonobe wrote: As the github pull request are not forwarded here, You know that you can enable automatic notifications? I don't recall the details - probably something involving a ticket for INFRA - but we do see PR notifications in Ant for example. Stefan

Re: [VOTE] Release Commons Compress Based on RC3

On 2015-08-18, Kristian Rosenvold wrote: I'm investigating a regression in the maven test suites with this version of c-c (related to zip file attributes). At the moment I do not know if c-c is the culprit. Please give me an extra day before closing this vote. Please take your time, thanks!

[RESULT] Release Commons Compress Based on RC3

Hi all with binding +1s by Gary Gregory Oliver Heger Kristian Rosenvold Stefan Bodewig and no other votes the vote has passed. I'll proceed with publishing the artifacts and will give the mirrors time to catch up before updating the site and sending out the announcement. Thanks to all who

Re: [VOTE] Release Commons Compress Based on RC3

On 2015-08-18, Kristian Rosenvold wrote: I found the source of the regression, outside c-c. great So here's my +1 for the release. and my own +1 as well. Stefan - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org

[ANN] Apache Commons Compress 1.10 Released

. Thanks to Damjan Jovanovic. For complete information on Commons Compress, including instructions on how to submit bug reports, patches, or suggestions for improvement, see the Apache Commons Compress website: http://commons.apache.org/compress/ Stefan Bodewig, on behalf of the Apache Commons

[VOTE] Release Commons Compress Based on RC3

Hi all third attempt after six months, last time we couldn't agree on how we wanted to treat the protected members of LZWInputStream, but this seems to be resolved with COMPRESS-300 now. So this is a fresh attempt. JIRA says we've fixed 19 issues and the changes to the zip packages are long

[compress] Review of ZIP Changes in trunk Needed

Hi all I'm tyring to get things together for a new attempt at releasing Compress 1.10. trunk has seen significant changes in the zip package by Kristian that I looked over back then and modified in a few places. I merged the changes over to Ant and they've ben release as Ant 1.9.5 where we've

[compress] LZWInputStream again

Hi all LZWInputStream's protected members have caused my last attempt to cut a 1.10 release of COMPRESS to fail. It seemed to be consensus that having those protected members was unacceptable but there is no real consensus on what to do instead. There are the two extremes: (a) leave everything

Re: [compress] JDK 9 b64 breaks bzip2 decompression

On 2015-06-18, Rory O'Donnell wrote: Did you log a bug at bugs.java.com, if yes can you send me the Incident number ? Sorry, so far I hadn't found the time to do so, just opened one Review ID: JI-9021700 Stefan - To

Re: [ALL][COMPRESS] security reports page naming

On 2015-06-18, sebb wrote: Commons Compress has a Security Reports page: http://commons.apache.org/proper/commons-compress/security.html which contains details of known security issues. The page links to the general commons security page http://commons.apache.org/security.html for

Re: [VOTE] Release pool 2.4.1 based on RC1

On 2015-05-30, Phil Steitz wrote: Built from: https://svn.apache.org/repos/asf/commons/proper/pool/tags/POOL_2_4_RC1/ (r1682493) you mean https://svn.apache.org/repos/asf/commons/proper/pool/tags/POOL_2_4_1_RC1/, right (an additional _1) - this also better matches the release number. Votes,

[compress] JDK 9 b64 - interpretation of TimeZone in ZipEntry#getTime has changed?

Hi I'm not sure whether I should raise a bug or this is an intended change. Apart from the bunzip2 problem - more on that in a separate mail - one other Unit test fails in Commons Compress. In our test we use a method to fix the time read from a ZIP entry with the following comment: /**

Re: [compress] JDK 9 b64 breaks bzip2 decompression

I've stripped down the test case to - import java.io.*; import org.apache.commons.compress.compressors.bzip2.BZip2CompressorInputStream; import org.apache.commons.compress.utils.IOUtils; public class Bzip2DecompressorLoop { public static void

[compress] JDK 9 b64 breaks bzip2 decompression

Hi all just as a heads up: while test-driving Ant on the latest JDK9 build I ran into errors for the tests that uncompressed bzip2 files, so I gave Commons Compress a try as well (Ant's bzip2 code base is pretty close to the CC one). In order to build Compress with JDK9 you need to set source

Re: [VOTE][LAZY] Migrate Apache Commons Lang to git

On 2015-03-05, sebb wrote: On 5 March 2015 at 05:33, Stefan Bodewig bode...@apache.org wrote: On 2015-03-05, sebb AT ASF wrote: git checkout -b release I don't understand what you're on the release branch means. Is that what the checkout command does? If so, does it have

Re: [VOTE][LAZY] Migrate Apache Commons Lang to git

On 2015-03-05, sebb AT ASF wrote: git checkout -b release I don't understand what you're on the release branch means. Is that what the checkout command does? If so, does it have to be done in an empty directory? Unlike svn, git doesn't branch into different folders of the file

Re: [VOTE] Release Compress 1.10 Based on RC1

On 2015-02-27, Gary Gregory wrote: What is the conclusion of this vote thread? Did I miss a CANCEL or RESULT email while I was gone? http://mail-archives.apache.org/mod_mbox/commons-dev/201502.mbox/%3C87oapdqxa0.fsf%40v35516.1blu.de%3E Stefan

Re: svn commit: r1659649 - in /commons/proper/compress/trunk/src: main/java/org/apache/commons/compress/archivers/tar/TarUtils.java test/java/org/apache/commons/compress/archivers/tar/TarUtilsTest.jav

On 2015-02-15, sebb wrote: On 13 February 2015 at 19:12, bode...@apache.org wrote: Author: bodewig Date: Fri Feb 13 19:12:09 2015 New Revision: 1659649 URL: http://svn.apache.org/r1659649 Log: python tarfile library seems to create embedded NULs, COMPRESS-301, unit test to follow -1

Re: svn commit: r1659649 - in /commons/proper/compress/trunk/src: main/java/org/apache/commons/compress/archivers/tar/TarUtils.java test/java/org/apache/commons/compress/archivers/tar/TarUtilsTest.jav

On 2015-02-15, sebb wrote: On 15 February 2015 at 18:45, Stefan Bodewig bode...@apache.org wrote: On 2015-02-15, sebb wrote: On 13 February 2015 at 19:12, bode...@apache.org wrote: Author: bodewig Date: Fri Feb 13 19:12:09 2015 New Revision: 1659649 URL: http://svn.apache.org/r1659649

Re: svn commit: r1659649 - in /commons/proper/compress/trunk/src: main/java/org/apache/commons/compress/archivers/tar/TarUtils.java test/java/org/apache/commons/compress/archivers/tar/TarUtilsTest.jav

On 2015-02-15, sebb wrote: On 13 February 2015 at 19:12, bode...@apache.org wrote: Author: bodewig Date: Fri Feb 13 19:12:09 2015 New Revision: 1659649 URL: http://svn.apache.org/r1659649 Log: python tarfile library seems to create embedded NULs, COMPRESS-301, unit test to follow -1

Re: [compress] (Internal)LZWInputStream

On 2015-02-02, Damjan Jovanovic wrote: I have a patch waiting to be committed to commons-imaging which uses the LZW stuff in commons-compress (brief mention of it by me on IMAGING-126), so it could break with these changes. My hope was to wait for the next release of compress before

[CANCEL] Release Compress 1.10 based on RC2

Sorry for those who already reviewed the release candidate, I'm going to cut a new RC once we've figured out what to do about LZWInputStream. Stefan - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional

Re: [VOTE] Release Compress 1.10 based on RC2

On 2015-01-31, sebb wrote: Given that the protected fields were in a class marked as internal, it seems arguable that users should not have referred to any of the items in it. Therefore we could potentially make all the mutable protected fields private (and add protected getters). Even if

[compress] (Internal)LZWInputStream

Hi I'm trying to bring together two separate discussions from two different [VOTE]-threads. It seems as if I should cancel the RC2 vote and before I rush another RC maybe we can get consensus on what to do. * my experiments show that moving the LZWInputStream class hasn't got as big an impact

Re: [VOTE] Release Compress 1.10 based on RC2

On 2015-01-31, sebb wrote: On 31 January 2015 at 09:03, Stefan Bodewig bode...@apache.org wrote: On 2015-01-31, sebb wrote: Given that the protected fields were in a class marked as internal, it seems arguable that users should not have referred to any of the items in it. Therefore we

Re: [VOTE] Release Compress 1.10 Based on RC1

On 2015-01-30, Gary Gregory wrote: On Fri, Jan 30, 2015 at 6:06 AM, Stefan Bodewig bode...@apache.org wrote: The superclass of ZCompressorInputStream has changed from one we've removed with the old __internal__ package to a new one in the now supported lzw package. Well, we cannot break BC

Re: [VOTE] Release Compress 1.10 Based on RC1

On 2015-01-30, sebb wrote: On 30 January 2015 at 08:20, Stefan Bodewig bode...@apache.org wrote: On 2015-01-28, Benedikt Ritter wrote: - PROPOSAL.txt is not in the src archives. Should it be? This is only there for historical reasons, I don't even think the other components still have

[VOTE] Release Compress 1.10 based on RC2

OK, next attempt. Compress 1.10 RC2 is available for review here: https://dist.apache.org/repos/dist/dev/commons/compress/ (svn revision 7884) Maven artifacts are here: https://repository.apache.org/content/repositories/orgapachecommons-1081/org/apache/commons/commons-compress/1.10/

[CANCEL][VOTE] Release Compress 1.10 Based on RC1

On 2015-01-27, Gary Gregory wrote: On Tue, Jan 27, 2015 at 4:54 AM, Kristian Rosenvold kristian.rosenv...@gmail.com wrote: I've run through all of our tests and the release looks good. The testcase should fail 1 in 1000 times as is and has been fixed. I'm +1 on the release as such (but

[compress] BitInputStream (was Preparations for 1.10)

On 2015-01-24, Stefan Bodewig wrote: On 2015-01-23, Emmanuel Bourg wrote: - BitInputStream: why not using a long cache instead of an int, like BitStream before the refactoring? It might be interesting to do some benchmarks and see if it make a difference. We never needed more than 31 bits

Re: [compress] Preparations for 1.10

On 2015-01-25, sebb wrote: On 25 January 2015 at 05:11, Stefan Bodewig bode...@apache.org wrote: On 2015-01-24, Kristian Rosenvold wrote: After an intense few minutes discussing the color of the bike shed with myself (package name) I moved the zip-unspecific parallel stuff

Re: [compress] Preparations for 1.10

On 2015-01-25, Emmanuel Bourg wrote: Le 25/01/2015 11:38, Benedikt Ritter a écrit : I'm not a compress developer, but IMHO exceptions should be packaged by their API and not by their nature. Thank you for moving the exception Stefan, however I tend to agree with Benedikt on this,

[VOTE] Release Compress 1.10 Based on RC1

As inidcated last week, here is the first RC for Compress 1.10. Compress 1.10 RC1 is available for review here: https://dist.apache.org/repos/dist/dev/commons/compress/ (svn revision 7828) Maven artifacts are here:

Re: [compress] Preparations for 1.10

On 2015-01-24, Kristian Rosenvold wrote: After an intense few minutes discussing the color of the bike shed with myself (package name) I moved the zip-unspecific parallel stuff to org.apache.commons.compress.parallel in r1654572. Maybe add a package-info.java? I'll need to add one to the

Re: [compress] Preparations for 1.10

On 2015-01-24, Kristian Rosenvold wrote: I suppose the what's new section on the site also needs to be updated to 1.10 ? Yes, that would be good. Anything else I can assist with before the release ? Thanks. I intend to spend a bit of time with BitInputStream and cut the RC tomorrow, at

Re: [compress] Preparations for 1.10

On 2015-01-23, Emmanuel Bourg wrote: Le 22/01/2015 17:30, Stefan Bodewig a écrit : Please have a look and identify stuff that looks as if I'd have to reroll a new RC should it come to a vote with the current code base. I reviewed the API changes, here are my comments

Re: [ALL] JIRA permissions for Kristian Rosenvold

On 2015-01-23, luc wrote: Le 2015-01-23 04:00, sebb a écrit : On 22 January 2015 at 23:55, sebb seb...@gmail.com wrote: On 20 January 2015 at 16:26, Stefan Bodewig bode...@apache.org wrote: JIRA Admins for Commons are Phil, Luc and Mark Struberg. As far as I know, I don't have

Re: Creating a Wiki Page

On 2015-01-22, Jochen Wiedmann wrote: Same as user ID: jochen sure? If so, then you should be set up now. Stefan - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail:

Re: Creating a Wiki Page

On 2015-01-22, Jochen Wiedmann wrote: are there any special privileges, one needs to create a new page on wiki.apache.org/commons? Yes, you need to be added to the contributors group - unfortunately we had to add this as an ant-spam measure. If so, could I have those privileges? Sure, what

[compress] Preparations for 1.10

Hi all I've had good experience with creating a site build before cutting a release candidate, so here we go: http://people.apache.org/~bodewig/commons-compress/ Please have a look and identify stuff that looks as if I'd have to reroll a new RC should it come to a vote with the current

Re: svn commit: r1653252 - in /commons/proper/compress/trunk/src: changes/ main/java/org/apache/commons/compress/archivers/sevenz/ test/java/org/apache/commons/compress/archivers/sevenz/

On 2015-01-20, Emmanuel Bourg wrote: Le 20/01/2015 15:24, bode...@apache.org a écrit : throw a special exception when there is no password for an encrpyted 7z archive - COMPRESS-298 Is it possible to mention the name of the file in the message of the exception? Not without modifying the

Re: [compress] ConcurrentJarCreator

On 2015-01-12, Kristian Rosenvold wrote: We had somewhat of a discussion regarding this class on the maven dev list over the weekend, some people wanted this code inside commons-compress: Code is here:

[ALL] JIRA permissions for Kristian Rosenvold

On 2015-01-20, Kristian Rosenvold wrote: Btw it still seems like my JIRA karma is a bit weak ? I'm not sure what you are missing, but I am sure I cannot provide it :-) JIRA Admins for Commons are Phil, Luc and Mark Struberg. Stefan

Re: svn commit: r1653252 - in /commons/proper/compress/trunk/src: changes/ main/java/org/apache/commons/compress/archivers/sevenz/ test/java/org/apache/commons/compress/archivers/sevenz/

On 2015-01-20, Gary Gregory wrote: Why not use an IllegalStateException? Because it used to throw IOException and I don't want to break code that was written to catch the IOException but not IllegalStateException. Stefan - To

Re: svn commit: r1650632 - in /commons/proper/compress/trunk/src/main/java/org/apache/commons/compress/archivers/zip: ZipArchiveEntry.java ZipArchiveOutputStream.java

On 2015-01-09, krosenv...@apache.org wrote: @@ -336,20 +338,48 @@ public class ZipArchiveEntry extends jav * @since 1.1 */ public ZipExtraField[] getExtraFields(boolean includeUnparseable) { +return includeUnparseable ? +getAllExtraFields() : +

Re: [compress] Finished with my changes

On 2015-01-10, Kristian Rosenvold wrote: 2015-01-10 15:29 GMT+01:00 Stefan Bodewig bode...@apache.org: what about the (unrelated) COMPRESS-290? I'll see what I can do. Should be simple compared to the other stuff I've been dealing with :) Just asking whether you intend to do anything about

Re: [compress] Finished with my changes

On 2015-01-09, Kristian Rosenvold wrote: I am finished with all my itches for the next version of c-compress what about the (unrelated) COMPRESS-290? and I'll just be running through all the maven test cases tonight. Unless bugs pop up I will not be making any further significant changes.

Wiki Accounts

Hi Luc and Kristian have asked to be added as contributors to the Wiki. I seem to be able to grant that, but need your wiki names in order to do so. I'm not able to grant Kristian JIRA karma. Stefan - To unsubscribe, e-mail:

Re: [compress] zip64 writing seems to be broken

On 2015-01-04, Kristian Rosenvold wrote: Most surprising to me is that it seems like the overhead of lots of small calls to RandomAccessFile.write seems to be a lot costlier than I thought it would be. It seems like consolidating to a larger byte array before calling write is a *lot* faster.

Re: [compress] zip64 writing seems to be broken

On 2015-01-04, Stefan Bodewig wrote: I'll leave my box alone to run the whole suite of ZIP64 ITs (i.e. enable the run-zipit profile) and report back later. Failed tests: Zip64SupportIT.write100KFilesFile:305-withTemporaryArchive:2342 arrays first differed at element [8]; expected:52

Re: [compress] zip64 writing seems to be broken

On 2015-01-04, Kristian Rosenvold wrote: Not entirely unsurprisingly this broken in r1648585. I'll try to understand it tonight I might find time before that, not sure, but I'll have a look myself as well. It might be a good idea to run the zip and tar ITs in some continuous build

Re: [compress] zip64 writing seems to be broken

On 2015-01-04, Kristian Rosenvold wrote: Not entirely unsurprisingly this broken in r1648585. I'll try to understand it tonight getBytesWritten vs getTotalBytesWritten - svn revision 1649322 Maybe we should rename getBytesWritten to something like getBytesWrittenForLastEntry to make the

Re: [compress] zip64 writing seems to be broken

On 2015-01-04, Stefan Bodewig wrote: I'm just running all ITs again to be sure. Tests run: 79, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1,400.308 sec - in org.apache.commons.compress.archivers.zip.Zip64SupportIT Stefan

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