Re: svn commit: r1647329 - in /commons/proper/compress/trunk/src: main/java/org/apache/commons/compress/archivers/zip/ test/java/org/apache/commons/compress/archivers/ test/java/org/apache/commons/com

On 2014-12-22, krosenv...@apache.org wrote: * It is possible to extend this class to support different kinds of backing storage, the default * implementation only supports file-based backing. Wouldn't it be possible to create a proper interface for backing stores and have

Re: [compress] Importance of retaining exact compatibility for ZipArchiveOutputStream ?

On 2014-12-22, Kristian Rosenvold wrote: There are quite a few extension points in this class that make changing it really hard. ACK I just committed r1647329 which basically duplicates some code from this class into another class. As much as I hate duplication, I wasn't able to achieve

Re: [parent] tag in scmUrl

On 2014-12-24, Bernd Eckenfels wrote: I wonder, is it intentional, that this is no longer required/defined, or just an oversight? We're not very explicit about this, but at least a part of the releasing guide for components says: , | Edit the SCM entries in the parent POM. Note: use the

Re: [ALL] Source option 1.4 and 1.5 are no longer supported in Java 9

Benedikt Ritter wrote: Maybe it's finally time to start upgrading all components to Java 1.6. All compontents that don't explicitly want to defer the upgrade. No need to force this on all components IMHO. On 2014-12-26, Jörg Schaible wrote: Just add a profile that sets the two properties

Re: [compress] Importance of retaining exact compatibility for ZipArchiveOutputStream ?

On 2014-12-23, Stefan Bodewig wrote: Your commit message calls out writeOut as a particilar problem. Fortunately this is one is final, so we don't have to retain the effect of subclasses overriding it. Wouldn't it be possible to have writeOut call the StreamCompressor's writeOut method so

Re: svn commit: r1647798 - /commons/proper/compress/trunk/src/test/java/org/apache/commons/compress/archivers/zip/ZipUtilTest.java

On 2014-12-24, krosenv...@apache.org wrote: It seems like OpenJDK calendar operations are somewhat different from sun jdk, so this is not a viable test to make Actually the reason is that zips - at least those created by Commons Compress - store time in UTC and you need to adjust for the

Re: [all] how long to wait for mirrors to synchronize?

On 2014-12-28, Luc Maisonobe wrote: I regularly check a few mirrors to see if they have mirrored the recent [math] release, and many still seem to not know about it. I will certainly not check all of them. Is there an accepted delay before sending the official announce of the release, even if

Re: [compress] Importance of retaining exact compatibility for ZipArchiveOutputStream ?

On 2014-12-26, Kristian Rosenvold wrote: Yup; I'm taking care of the duplication in trunk on my github fork. The other interesting branch to look at is the somewhat stale concurrentSupport branch and in particular the class ConcurrentZipCreator. This is my primary goal, I just went off on a

Re: [compress] Importance of retaining exact compatibility for ZipArchiveOutputStream ?

On 2014-12-28, Kristian Rosenvold wrote: 2014-12-28 11:35 GMT+01:00 Stefan Bodewig bode...@apache.org: On 2014-12-26, Kristian Rosenvold wrote: D) Look at performance in the gather phase. It's too slow right now, even with my last commit on trunk. Consider moving the creation of the LFH

Re: [compress] Refactoring to interfaces in Scatter* logic

On 2014-12-28, Kristian Rosenvold wrote: Stefan, I looked at your changes in the github repo https://github.com/bodewig/commons-compress/commits/scatter-backing-store I think they look great. Please commit them :) Done Stefan

Re: [compress] Importance of retaining exact compatibility for ZipArchiveOutputStream ?

On 2014-12-29, Kristian Rosenvold wrote: The refactoring os ZipArchiveOutputStream to use StreamCompressor is now done in the branch https://github.com/krosenvold/commons-compress Some code comments: * the fields writtenToOutputStream, sourcePayloadLength and actualCrc in StreamCompressor

Re: [All] Moving to git

On 2014-12-29, Gary Gregory wrote: but I encourage Git 'pushers' (pun intended) to just bring up a VOTE for a component and move the process along if you care about Git. Just as a letter of intent - I'd prefer to cut Compress 1.10 while we're still in svn (as I know how to do it, I'm in the

Re: Project Life Cycle at Apache Software Foundation

Welcome Sumit Gaur! On 2014-12-29, Sumit Gaur wrote: I am new to Open Source Development. I’ve been part of various Java, J2EE, WebServices (SOAP,Rest), Spring based projects. I’ve some questions regarding project life cycle at ASF. Kindly spare some time to answer the following: This is

Release Plugin (was Re: [All] Moving to git)

On 2014-12-31, Jochen Wiedmann wrote: On Mon, Dec 29, 2014 at 3:16 PM, Stefan Bodewig bode...@apache.org wrote: Just as a letter of intent - I'd prefer to cut Compress 1.10 while we're still in svn (as I know how to do it, I'm in the avoid the release plugin camp) and call for a vote

Re: [compress] Importance of retaining exact compatibility for ZipArchiveOutputStream ?

On 2014-12-30, Kristian Rosenvold wrote: I fixed all comments and reinstated the protected Deflater. Thanks, looks good. The whole ZipArchiveOutputStream class reminds me of a few of the 3000+ LOC java classes I refactored in maven core; sometimes the only acceptable solution is to extract

Re: [compress] Importance of retaining exact compatibility for ZipArchiveOutputStream ?

Re backwards compatibility: ZipArchiveOutputStream's deflate method has been protected and now has gone. On 2014-12-31, Kristian Rosenvold wrote: On a related note, I just added the *last* substantial change I intend to do. I will do a tweak or two, and I'm sure that last class will trigger a

Re: svn commit: r1648704 - in /commons/proper/compress/trunk/src: main/java/org/apache/commons/compress/archivers/zip/ test/java/org/apache/commons/compress/archivers/zip/

On 2014-12-31, krosenv...@apache.org wrote: static ScatterGatherBackingStoreSupplier defaultSupplier = new DefaultSupplier(); This one could be instance variable (and made final when set in the constructor). I think this would be a cleaner approach to overriding the supplier that setting

Re: svn commit: r1648704 - in /commons/proper/compress/trunk/src: main/java/org/apache/commons/compress/archivers/zip/ test/java/org/apache/commons/compress/archivers/zip/

On 2015-01-02, Kristian Rosenvold wrote: 2015-01-02 16:22 GMT+01:00 Stefan Bodewig bode...@apache.org: On 2014-12-31, krosenv...@apache.org wrote: ... all else fixed in r1649128.. I thought you'd need a way to override the ScatterGatherBackingStoreSupplier from Plexus, maybe I was wrong

Re: [compress] Importance of retaining exact compatibility for ZipArchiveOutputStream ?

On 2015-01-02, Kristian Rosenvold wrote: All fixed :) Thanks a lot! Stefan - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org

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: 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: 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

[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

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 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] 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-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-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

-1080/org/apache/commons/commons-compress/1.10/ Details of changes since 1.9 are in the release notes: https://dist.apache.org/repos/dist/dev/commons/compress/RELEASE-NOTES.txt http://people.apache.org/~bodewig/compress-1.10-RC1/changes-report.html The tag is here: http

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

[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

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

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: [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] Finished with my changes

soon, this is also going to help IMAGING. For convenience I've uploaded a current site build to http://people.apache.org/~bodewig/COMPRESS-1.10/index.html so people can look at the currnt state of documentation and the usual suspects of reports that need to get explained. There are a few findbugs

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

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: 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] 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

[compress] zip64 writing seems to be broken

Hi building the compress antlib in Gump fails (and has been failing for a few days but I didn't notice): http://vmgump.apache.org/gump/public/antlibs-compress/compress-antlib-test/gump_work/build_antlibs-compress_compress-antlib-test.html The test creates a ZIP with a single 5GB entry and then

Re: [compress] zip64 writing seems to be broken

On 2015-01-04, Stefan Bodewig wrote: I'll try to reproduce this as a unit test for compress later today, svn revision 1649312 - run via $ mvn test -Dtest=Zip64SupportIT#writeAndRead5GBOfZerosUsingZipFile I'll leave my box alone to run the whole suite of ZIP64 ITs (i.e. enable the run-zipit

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: [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][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: 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: [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

/ Details of changes since 1.9 are in the release notes: https://dist.apache.org/repos/dist/dev/commons/compress/RELEASE-NOTES.txt http://people.apache.org/~bodewig/compress-1.10-RC2/changes-report.html The tag is here: http://svn.apache.org/repos/asf/commons/proper/compress/tags

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

[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

[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

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,

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

[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

[VOTE] Release Commons Compress Based on RC3

of changes since 1.1 are in the release notes: https://dist.apache.org/repos/dist/dev/commons/compress/RELEASE-NOTES.txt http://people.apache.org/~bodewig/compress-1.10-RC3/changes-report.html I have tested this with JDK 1.7 and 1.8 using maven3. The tag is here: https://svn.apache.org

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

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

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

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

[compress] Preparing for 1.12

Hi all we've got a nice set of fixes and new features added since 1.11 and I plan to cut the next release soonish. The only thing I want to do prior to the release is adding a few words of documentation about the IWA support in Snappy. Based on prior experience I'd like to give folks a chance to

Re: [compress] Preparing for 1.12

On 2016-06-10, Torsten Curdt wrote: >> You'll see that findbugs is unhappy about inconsistent synchronization >> introduced when I made the finish method of BZip2CompressorOutputStream >> synchronized due to COMPRESS-357 > My feedback: I'd rather recommend to get rid of the finalize over adding

Re: [compress] Preparing for 1.12

On 2016-06-10, Stefan Bodewig wrote: > We have it in two cases, ZipFile and BZip2CompressorOutputStream - > ZipFile uses a volatile flag rather than synchronization and > null-assignment, maybe that's the better option anyway. I've changed the code and findbugs is happy again, updated s

[compress] change behavior of bzip-output finalize?

Hi all I'm trying to bring a discussion from COMPRESS-357 over to the list. The bzip2 output stream has a finish method that is used to ensure all data has been written to the stream and a separate close method that invokes finish. And it overrides finalize to invoke finish in case people have

Re: [compress] change behavior of bzip-output finalize?

On 2016-06-13, Stefan Bodewig wrote: > The bzip2 output stream has a finish method that is used to ensure all > data has been written to the stream and a separate close method that > invokes finish. And it overrides finalize to invoke finish in case > people have forgotten to clos

[ANN] Apache Commons Compress 1.12 Released

that relied on the finalizer. Issue: COMPRESS-357. 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

<    3   4   5   6   7   8   9   10   11   12   >