[VOTE] Release Compress 1.8 Based on RC1

Hi all I talked about cutting Compress 1.8 in particular because of COMPRESS-264 but delayed it waiting for a new XZ for Java release. Compress 1.8 RC1 is available for review here: https://dist.apache.org/repos/dist/dev/commons/compress/ (svn revision 4610) Maven artifacts are here:

Re: svn commit: r1573038 - /commons/proper/compress/trunk/src/test/java/org/apache/commons/compress/compressors/bzip2/PythonTruncatedBzip2Test.java

On 2014-03-02, sebb wrote: > On 1 March 2014 19:53, Matt Benson wrote: >> I've said it before: doocracy. If someone wants to take on the work to >> provide 1.5 support, they've widened the audience of the component, which >> should be seen as a win if it didn't cause anyone else a problem. > Whi

Re: svn commit: r1573060 - /commons/proper/compress/trunk/src/main/java/org/apache/commons/compress/archivers/sevenz/Coders.java

On 2014-03-01, sebb wrote: > On 1 March 2014 05:57, Stefan Bodewig wrote: >> On 2014-02-28, wrote: >>> Add serialVersionUID >> to a private inner class that is a subclass of HashMap. >> Why? > Eclipse complained; it won't do any harm. Sure not, I w

Re: [compress] problems with 7z BCJ methods

On 2014-02-28, sebb wrote: > On 28 February 2014 17:47, Stefan Bodewig wrote: >> On 2014-02-28, sebb wrote: >>> Alternatively, can Compress detect the XZ version and refuse to run >>> BCJ, again with suitable message? >> No way short of parsing the OSGi att

Re: svn commit: r1573060 - /commons/proper/compress/trunk/src/main/java/org/apache/commons/compress/archivers/sevenz/Coders.java

On 2014-02-28, wrote: > Add serialVersionUID to a private inner class that is a subclass of HashMap. Why? Stefan - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.a

Re: [compress] problems with 7z BCJ methods

On 2014-02-28, Gary Gregory wrote: > Do we have any idea WRT a new release of XZ? I've reported the problem a few hours ago and Lasse fixed it within minutes. This single line change is the only change since the 1.4 release cut six or seven month ago. Not sure whether he'd like to create a new

Re: [compress] problems with 7z BCJ methods

On 2014-02-28, sebb wrote: > Can Compress catch the specific Assertion Error and convert it to a > message that explains the issue? Perhaps even provide a link to a > Wiki FAQ? not without catching all AssertionErrors java.lang.AssertionError: null at org.tukaani.xz.SimpleInputStream.(Unkn

[compress] problems with 7z BCJ methods

Hi, I've managed to implement the major BCJ filters for 7z (special filters for native executables) by simply invoking the XZ for Java implementations for it. This is needed for COMPRESS-257. Unfortunately there is a bug in XZ for Java that has already been fixed in git. When using a released

Re: [compress] Planning 1.8 Release

> Apart from the bugfixing we've added better support for 7z compression > methods - you can now chose a stack of more than one method when writing > (this has always been possible when reading), pass options to the > methods and use different configurations per entry. The core of this > are the

Re: [imaging] failing JUnit test

On 2014-02-27, luc wrote: > Is this failure expected? I am running the tests suite on a Linux > computer, maybe MicrosoftTagTest is windows-specific? all tests pass for me: $ uname -a Linux brick 3.5.0-46-generic #70-Ubuntu SMP Wed Jan 8 18:40:46 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux $ java -v

Re: [compress] Planning 1.8 Release

On 2014-02-27, Benedikt Ritter wrote: > the project reports look good to me. Some package have low test coverage > but I think you've already said that it's pretty hard to write tests for > this areas of the code. PMD shows four violations. The first three look > like they can be fixed easily. No

[compress] Planning 1.8 Release

Hi all, this is a heads-up that I intend to cut a RC for Compress 1.8 soon. We have accumulated a few bugfixes and at least COMPRESS-264 is pretty serious. I've already updated the website from trunk (basically to have the new skin online) so you can already have a look at the reports. Before I

Re: [DBCP] @since markers for 2.0 release

On 2014-02-26, Mark Thomas wrote: > I'm wondering what to do about @since markers. As DBCP2 is in a > completely new package, arguably everything is new for this release. The > existing @since markers don't make a lot of sense. Therefore, I am > currently considering removing all @since markers fr

Re: [VOTE] Release Apache Commons Pool 2.2 RC2 as 2.2

On 2014-02-21, Mark Thomas wrote: > The Pool 2.2 RC2 is available for review here: > https://dist.apache.org/repos/dist/dev/commons/pool/ (r4457) > Maven artifacts are here: > https://repository.apache.org/content/repositories/orgapachecommons-1009 > Details of changes since 2.1 are in the r

Re: [VOTE] Move Commons Attributes to dormant

On 2014-02-20, Benedikt Ritter wrote: > I'd like to call a vote for moving Commons Attributes to dormant. > Reasons: > - years have passed since the last real activity in attributes [1]. > - the last release is from 2006. > - the code is pre Java 5. +1 Stefan ---

Re: [VOTE] Release Apache Commons File Upload 1.3.1 RC1 as 1.3.1

On 2014-02-06, Mark Thomas wrote: > The FileUpload 1.3.1 RC1 is available for review here: > https://dist.apache.org/repos/dist/dev/commons/fileupload/ (r4317) > Maven artifacts are here: > https://repository.apache.org/content/repositories/orgapachecommons-1005/ > Details of changes since 1

Re: [io][compress] Interest in Some Channel Classes?

On 2014-01-27, Benedikt Ritter wrote: > I've planned to do some work on IO after [lang] 3.3, but you know how > it often turn's out with my plans ;-) so I cannot promise anything. tell me - I'll go MIA for most of the next two or three weeks, I'm afraid. > One thing I don't understand is: are yo

[io][compress] Interest in Some Channel Classes?

Hi while pondering the API of Compress 2.x I already moaned about the lack of decorator support in Channels, in particular pushback would be needed in Compress in many places, but also stuff like counting, verifying checksums and other Filter*Stream stuff. When I started to look around I didn't f

Re: [compress] 2.0: require Java7?

On 2014-01-25, Damjan Jovanovic wrote: > On Fri, Jan 24, 2014 at 6:06 PM, Stefan Bodewig wrote: >> On 2013-12-30, Stefan Bodewig wrote: >>> Compress 1.x is at Java5, personally I don't think Java6 would give us >>> any benefits. I don't know about t

Re: [compress] 2.0: require Java7?

On 2013-12-30, Stefan Bodewig wrote: > Compress 1.x is at Java5, personally I don't think Java6 would give us > any benefits. I don't know about the other improvements in NIO2 but the > java.nio.file package looks useful for compress. In the meantime it has been pointed out

Re: [compress] 2.0: Reading and Writing Archives

On 2014-01-22, Damjan Jovanovic wrote: > On Wed, Jan 8, 2014 at 4:41 PM, Stefan Bodewig wrote: >> * Checked vs Unchecked exceptions >> I would love to make ArchiveInput be an Iterator over the entries but >> can't do so as the things we'd need

[ANNOUNCE] Apache Commons Compress 1.7 Released

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 community -BEGIN PGP SIGNATURE- Version

[RESULT] Release Compress 1.7 based on RC2

Hi, with +1s by Benedikt Ritter, Gary Gregory, Emmanuel Bourg, Phil Steitz, Oliver Heger, Jörg Schaible and an implicit +1 by myself the vpte has passed. I'll start publishing the stuff and give the mirrors a bit of time before updating the site and sending out the release announcement. Thanks t

Re: Build-By MANIFEST-Attribute (was Re: [VOTE] Release Compress 1.7 based on RC2)

On 2014-01-17, Emmanuel Bourg wrote: > If you build the release from your son's account (or if you have > exotic tastes) you may end up with a 'Build-By: spacepirate' field in > the manifest, which is a bit embarrassing. Now that's an idea. So I'll throw in a bit of desinformation with future re

Build-By MANIFEST-Attribute (was Re: [VOTE] Release Compress 1.7 based on RC2)

thanks for the review and the vote. On 2014-01-17, Benedikt Ritter wrote: > One minor thing I've noticed is, that the Build-By MANIFEST header is set > to "stefan". I've learned that it should be set to you're Apache ID. Well, this must have been that way for all releases I've ever created. :-)

[VOTE] Release Compress 1.7 based on RC2

Hi all compared to RC1 there is no code change only the Javadocs of the _internal package are even more discouraging and the directory tree insite the tarballs/zips should hold the correct version number. Compress 1.7 RC2 is available for review here: https://dist.apache.org/repos/dist/dev/co

Re: [compress] exclude _internal package from javadocs?

On 2014-01-12, Stefan Bodewig wrote: > I'm a bit torn on this and since I'll re-roll a new RC anyway I'd like > to see what others think about hiding internal packages. I've unhid it again and strengthened the "may change" warning as Sebb suggested. Makin

[compress] exclude _internal package from javadocs?

Compress holds a package that is public as an implementation detail but whose API isn't meant for public consumption. The javadocs of said package state this in bold letters.[1] Current trunk will even go further and hide the package from javadoc, but the only class inside is still refered to by

Re: [VOTE] Release Compress 1.7 based on RC1

On 2014-01-11, Gary Gregory wrote: > The reports look good BUT I think the NEW code should have better code > coverage. There seems to be some non-trivial code that is not tested > at all. AFAICS this is mostly handling cases that are difficult to create test data for. * Snappy with literals lon

[CANCELLED] Release Compress 1.7 based on RC1

On 2014-01-11, Oliver Heger wrote: > There is a problem with the source distribution: It deflates in a > directory "commons-compress-1.6-src"; so here the version number is > wrong. Not sure whether this is blocking or not - in any case, it is > confusing. Ouch. Emmanuel told me I forgot to upda

[VOTE] Release Compress 1.7 based on RC1

Hi all current trunk contains two new read-only compression algorithms but more importantly it fixes serious bugs in the tar and 7z packages. As indicated a few weeks ago a new release is overdue. Compress 1.7 RC1 is available for review here: https://dist.apache.org/repos/dist/dev/commons/c

Re: svn commit: r1556795 - in /commons/proper/compress/tags/COMPRESS-1.7-RC1: ./ RELEASE-NOTES.txt pom.xml src/site/site.xml src/site/xdoc/download_compress.xml src/site/xdoc/index.xml

On 2014-01-09, Benedikt Ritter wrote: >> >> -scm:svn: >> http://svn.apache.org/repos/asf/commons/proper/compress/trunk >> -scm:svn: >> https://svn.apache.org/repos/asf/commons/proper/compress/trunk >> >> -http://svn.apache.org/repos/asf/commons/proper/compress/trunk >> >> +sc

[compress] 2.0: Reading and Writing Archives

Hi, putting the exact representation of an archive entry aside I've put down an idea of the API for reading and writing archives together with a POC port of the AR classes for this API. All is inside http://svn.apache.org/repos/asf/commons/proper/compress/branches/compress-2.0/ The port doesn't

Re: [VOTE] Release Commons Exec 1.2-RC1

On 2014-01-02, sebb wrote: > AFAIK zip does not support permissions. InfoZIP does and so does Ant (or Commons Compress ;-). Not sure about the assembly plugin but I'd assume it supports it as well. Stefan PS: permissions in ZIPs are the main reason I started to write the org.apache.tools.zip p

Re: [VOTE] Release Commons Exec 1.2-RC1

On 2014-01-02, Gary Gregory wrote: > Sounds like an OS permission issue with executables. Can we use Maven to > create the right file permissions for sh files in a tar/zip? Assuming you are using the assembly plugin, then the answer is yes: https://maven.apache.org/plugins/maven-assembly-plugin/

Re: [compress] 2.0: require Java7?

On 2014-01-02, Emmanuel Bourg wrote: > Le 01/01/2014 23:09, Stefan Bodewig a écrit : >> AFAIK maven uses some Plexus component which is yet another fork of the >> codebase originating from Ant - must have been created at about the same >> time as Compress. > The forked c

Re: [compress] 2.0: require Java7?

On 2014-01-01, Emmanuel Bourg wrote: > Le 30/12/2013 11:17, Stefan Bodewig a écrit : >> Is this too ambitious? Should we poll the user list? > I believe Commons Compress is a core dependency of the Maven ecosystem. > I don't know what is the minimum version of Java ex

[compress] 2.0: require Java7?

Hi, I've started to write a tiny amount of code for 2.0 to get things moving (more on this later) and have already reached a point where Java7 may make a difference. I'm trying to define an API for attributes beyond the set offered by ArchivEntry so far - many (AR, ARJ, CPIO, ZIP, TAR, DUMP) of o

Re: [compress] Tika test error with IMPLODEd zip

On 2013-12-22, Emmanuel Bourg wrote: > Le 22/12/2013 12:40, Stefan Bodewig a écrit : >> The archive is real, InfoZIP's unzip is willing to extract it without >> any errors. I've created unit tests from it with svn revision 1552980 - >> not sure when I'll fi

Re: [compress] Tika test error with IMPLODEd zip

On 2013-12-22, Stefan Bodewig wrote: > I'll try to locate the archive they use later and see whether it looks > genuine but maybe somebody from tika is lurking here and can shed some > light. The archive is real, InfoZIP's unzip is willing to extract it without any errors.

Re: [compress] Tika test error with IMPLODEd zip

On 2013-12-22, sebb wrote: > On 22 December 2013 07:45, Stefan Bodewig wrote: >> <http://vmgump.apache.org/gump/public/tika/tika-parsers-test/gump_file/org.apache.tika.parser.pkg.ZipParserTest.txt.html> >> Of course it is possible the archive isn't real and they used

[compress] Tika test error with IMPLODEd zip

Hi even thouhg Gump stopped nagging, it still works. Tika is built by Gump and they have a test they call testUnsupportedZipCompressionMethod in which they seem to use an archive created with an IMPLODED entry. This test started to fail when Emmanuel added support for IMPLODE but unfortunately i

Re: [compress] cutting 1.7?

On 2013-12-20, Gary Gregory wrote: > How about using the current version of FB, 2.5.3? OK, I upgradede findbugs, removed the methods from JarArchiveEntry and commented the new warnings findbugs emits now (default encoding in places where we explicitly want to use it).

Re: svn commit: r1552745 - /commons/proper/compress/trunk/src/main/java/org/apache/commons/compress/compressors/z/ZCompressorInputStream.java

On 2013-12-20, Gary Gregory wrote: > I've made some adjustments to this file in SVN. My intention was to not > change the bit twiddling expressions, my mistake. Now we have: > value |= nextByte << (8 * i); Thanks Stefan --

Re: [compress] cutting 1.7?

On 2013-12-20, sebb wrote: > On 20 December 2013 17:38, Stefan Bodewig wrote: >> On 2013-12-20, sebb wrote: >>> On 20 December 2013 17:07, Stefan Bodewig wrote: >>>> On 2013-12-20, Gary Gregory wrote: >>>>> We get PMD warnings in >>>>&g

Re: svn commit: r1552745 - /commons/proper/compress/trunk/src/main/java/org/apache/commons/compress/compressors/z/ZCompressorInputStream.java

On 2013-12-20, Gary Gregory wrote: > On Fri, Dec 20, 2013 at 12:21 PM, Emmanuel Bourg wrote: >> Le 20/12/2013 18:18, ggreg...@apache.org a écrit : >>> Remove some unnecessary parentheses. >> I'd argue they make the code easier to read. Reading bit shifting code >> is quite painful, some parent

Re: [compress] cutting 1.7?

On 2013-12-20, sebb wrote: > On 20 December 2013 17:07, Stefan Bodewig wrote: >> On 2013-12-20, Gary Gregory wrote: >>> We get PMD warnings in >>> org.apache.commons.compress.archivers.jar.JarArchiveEntry about methods >>> only calling super. >

Re: svn commit: r1552745 - /commons/proper/compress/trunk/src/main/java/org/apache/commons/compress/compressors/z/ZCompressorInputStream.java

On 2013-12-20, Emmanuel Bourg wrote: > Le 20/12/2013 18:18, ggreg...@apache.org a écrit : >> Remove some unnecessary parentheses. > I'd argue they make the code easier to read. Reading bit shifting code > is quite painful, some parentheses help greatly. +1 Stefan -

Re: [compress] cutting 1.7?

On 2013-12-20, sebb wrote: > On 20 December 2013 16:46, Gary Gregory wrote: >> Either the source level must be set to 1.6 or the @Overrides must be >> removed from org.apache.commons.compress.compressors.snappy.PureJavaCrc32C. > I suspect these were accidentally added. The code is copied from

Re: [compress] cutting 1.7?

On 2013-12-20, Gary Gregory wrote: > CPD shows some complex code duplication, is it possible to refactor? It has been doing so ever since we added CPD reports. The code is part of a loop (you'll note the braces are not ballanced, there is one more closing than opening brace) that contains and mu

Re: [compress] cutting 1.7?

On 2013-12-20, Gary Gregory wrote: > We get PMD warnings in > org.apache.commons.compress.archivers.jar.JarArchiveEntry about methods > only calling super. > Either document that the methods are placeholders for future > implementations (TODO) or remove the methods. Actually it is neither. If y

Re: [compress] cutting 1.7?

On 2013-12-20, Gary Gregory wrote: > Either the source level must be set to 1.6 or the @Overrides must be > removed from org.apache.commons.compress.compressors.snappy.PureJavaCrc32C. > I'm fine with making the min JRE 1.6. Removing the @Overrides was quicker and less controversial :-) A pity C

[compress] Marking a public Class non-Public

Hi in compress' trunk we now have to different stream classes that use variants of LZW - the UNSHRINKING support in the zip package and the ZCompresorInputStream. They looked so similar (and CPD was rightfully moaning about code duplication) that I decided to extract the common code into

Re: [compress] cutting 1.7?

OK, this time I'm really trying to get feedback before I spend two hours on a throw-away RC build :-) contains the site generated from current trunk. When building the real release I'll be using Java6 so Clirr won't talk about AutoCloseable. And I'll c

Re: [compress] Unused CRC in ZipArchiveInputStream

On 2013-12-19, Emmanuel Bourg wrote: > ZipArchiveInputStream updates a CRC32 for each entry but the result is > never used. Any objection to remove it? Hmm, we also set the CRC on the ZipArchiveEntry so it may be worth to actually verify it. ZipFile doesn't verify it either, by the way. I'd pre

Re: svn commit: r1551026 - in /commons/proper/compress/trunk/src/main/java/org/apache/commons/compress: archivers/zip/UnshrinkingInputStream.java compressors/z/AbstractLZWInputStream.java compressors/

On 2013-12-17, Damjan Jovanovic wrote: > I am wondering how far this can be taken. TIFF's LZW uses an > end-of-information code after the clear code, allows both > little-endian and big-endian packing of bytes, and increases the code > size one step too early. Is it even possible to generalize LZW

[compress] cutting 1.7?

Hi all, 1.6 has a regression inside the tar package that causes serious problems for people not using buffered streams when reading archives. Current trunk contains some new code that seems to have acceptable test coverage by now. I know Emmanuel is working on an IMPLODE implementation for the z

Re: [DRAFT][REPORT] Status report for the Apache Commons Project December 2013

On 2013-12-09, Stefan Bodewig wrote: > On 2013-12-09, Gary Gregory wrote: >> Thank you for the corrections. I do not see how to get mailing list stats >> out of ezmlm. > <http://pulse.apache.org/#commons.apache.org> Ahh, sorry, just saw that page doesn'

Re: [DRAFT][REPORT] Status report for the Apache Commons Project December 2013

On 2013-12-09, Gary Gregory wrote: > Thank you for the corrections. I do not see how to get mailing list stats > out of ezmlm. Report looked fine to me. Stefan - To unsubscribe, e-

[compress] ideas for 2.0

Hi all, we've been talking about a backwards incompatible 2.0 release for a long time and even have some JIRA tickets assigned to that magic version as they can only be cleanly soved by breaking the old API. As a small step forward I've started to collect discussion items and requirements that I

Re: [compress] ZIP unshrinking support

On 2013-12-06, Damjan Jovanovic wrote: > I just committed a patch for decompressing ZIP entries using method 1 > ("unshrinking"), but it's only for ZipFile. Cool. Do you know how to create such an archive so we can have a real testcase? InfoZip zip on my Linux box only supports methods stored,

Re: [Compress] Hiring Coder

On 2013-11-29, Bear Giles wrote: > What are the license issues? I had looked at the legal stuff briefly > but could have easily overlooked it since I was only looking at the > tech note that documents their numerous versions. Section 10 of the current APPNOTE.TXT: 10.1 The Use or Implementati

Re: [Compress] Hiring Coder

On 2013-11-29, dam6923 . wrote: > I'm looking for the encryption that Windows XP provides for ZIP files. > I believe it's the old, lame, encryption. Is that correct? TBH, I have no idea. You may be able to tell by looking at the general purpose bit of an encrypted entry. Bit 0 would be set whe

Re: [Compress] Hiring Coder

On 2013-11-29, dam6923 . wrote: > Is there any policy in place or method already laid out for putting > bounties on certain task items? In particular, I could chip something > in for the following two tickets: What Phil said. > 1) https://issues.apache.org/jira/browse/COMPRESS-88 > 2) https://i

Re: [cli] Moving to Git?

On 2013-11-27, Gilles wrote: >> So can we please allow the folks who actively work on [cli] today >> make the decsision which vcs they want to use? > Do "we" really have to allow them? Or do they have the right to do as > they please? "allow" was meant to be "let" rather than "permit" - my inte

Re: [cli] Moving to Git?

Hi I don't intend to argue for git or svn at all, but rather for "let the people decide who do the work". IIUC we can migrate CLI to git without forcing all other Commons components to make the move as well. I for one do not intend to work on [cli] and if I had to patch a small thing (like I did

Re: [VOTE] Release of Commons Collections 4.0 based on RC5

On 2013-11-21, Thomas Neidhart wrote: > I'd like to call a vote for releasing Commons Collections 4.0 based on > RC5 and hope that people are still willing to review and vote for this RC. +1 and thanks again Stefan - To unsubs

Re: [VOTE] Release of Commons Collections 4.0 based on RC4

+1 for the release Thanks for your patience Stefan - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org

Re: [RESULT] Allow "plain committers" to publish releases

On 2013-11-08, Stefan Bodewig wrote: > I've opened INFRA-6978. which has just been resolved. Stefan - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org

[RESULT] Allow "plain committers" to publish releases

Hi all I count +1s by Stefan Bodewig Emmanuel Bourg Phil Steitz Luc Maisonobe Henning Schmiedehausen and a +0 by Mark Thomas so the vote has passed. I've opened INFRA-6978. Stefan - To unsubscribe, e-mail: dev-uns

Re: Snapshot vs. release sites.

On 2013-11-07, sebb wrote: > On 6 November 2013 15:53, Gary Gregory wrote: >> Hi All: >> I find it unhelpful and confusing at times to see Commons sites for >> -SNAPSHOT version. > +1, it's annoying and unhelpful to have the main site refer to a > version that has not been released. I tend to

Re: [VOTE] Allow "plain committers" to publish releases

On 2013-11-05, Mark Thomas wrote: > Arguably any committer involved enough in the project to be a release > manager should be on the PMC. unless we overlook that he/she isn't, I agree. > (I assume that Nexus is already configured this way else that will > need tweaking too.) Yes. This vote ste

[VOTE] Allow "plain committers" to publish releases

Hi all making this a formal vote so it doesn't fall through the cracks. We allow committers who are not PMC members to be release managers but they are not allowed to write to the release branch of the dist repository. This seems to be the default setting for the dist repo and could be easily fi

Re: Huh? Only two people can do releases?

On 2013-10-28, Henning Schmiedehausen wrote: > Sorry for singling you out, Stefan; np > again thanks a lot for moving the files over. I will fix the README > later today. Would it be possible that you also remove the 1.9 files > from the binaries and sources folders? will do so in a few hours,

Re: Huh? Only two people can do releases?

release > software. > I know that one is Stefan Bodewig. Can one of you please open a ticket with > infra as requested. I'm hardly the only PMC member around :-) Stefan - To unsubscribe, e-mail: dev-unsubscr...@c

Re: can't move files from dev to release

On 2013-10-28, Henning Schmiedehausen wrote: > Thanks Stefan. I will look into the README issue. I've modified the README doing s/1.9/1.10/g Let me know if more needs to be done. Stefan - To unsubscribe, e-mail: dev-unsubscr..

Re: can't move files from dev to release

On 2013-10-28, Stefan Bodewig wrote: > In the interim I can move the files for you - at least last Saturday I > posessed the karma required to do so. Done, but there didn't seem to be a README to replace the existing one wi

Re: can't move files from dev to release

On 2013-10-28, Henning Schmiedehausen wrote: > Seems I am missing some permissions here. I filed > https://issues.apache.org/jira/browse/INFRA-6942 for that. Not exactly sure but ISTR you also get this response when you try to overwite an existing file using mv - cp is fine. In the interim I can

[compress] Build Problems with JDK8

Hi, I'm currently using JDK 1.8 build 113 on some projects as we had reports of incompatibilities on the Gump list. It may be worth doing that for other components as well. Anyway, two tests fail, both for the same reason: org.tukaani.xz.XZIOException: Stream finished or closed at org.tukaa

[ANNOUNCE] Apache Commons Compress 1.6 Released

-234. Thanks to BELUGA BEHR. 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 commu

Re: svn commit: r1535923 - in /commons/proper/compress/trunk: pom.xml src/site/site.xml

On 2013-10-26, sebb wrote: > On 26 October 2013 06:30, wrote: >>> >>>org.apache.maven.plugins >>>maven-scm-publish-plugin >>> >>> >>>javadocs** > That expression looks a bit odd. > Should it be as follows? > javadocs/** No idea, this is st

[RESULT] Release Compress 1.6 based on RC3

With +1s by Torsten Curdt Emmanuel Bourg Benedikt Ritter Gary Gregory Stefan Bodewig and no other votes the vote has passed. I'll copy around the release artifacts but will give the mirrors a bit of time to catch up before I announce the release and update the site. S

Re: [VOTE] Release of Commons Email 1.3.2 based on RC2

On 2013-10-20, Thomas Neidhart wrote: > I'd like to call a vote for releasing Commons Email 1.3.2 based on RC2. Signatures and hashes look good, RAT is happy, no opinion on contents :-) +1 Stefan - To unsubscribe, e-mail: dev-

Re: [compress] Strong Crypto in Tests

On 2013-10-24, Benedikt Ritter wrote: > I don't see a reason to wait for 2.x before updating to JUnit 4. The > old tests will be executable without changes. There already are 4.x and 3.x tests mixed up. > Am I missing something here? It needs somebody to do it. As I expet us to rewrite all tes

Re: [compress] Strong Crypto in Tests

On 2013-10-23, Gary Gregory wrote: > Consider using JUnit's Assume to skip testing, this will allow IDEs and > tools to know a test has been skipped. Unfortunately the test like many of Compress' tests is in JUnit 3.x land - something to change if we ever get 2.x off the ground. Stefan

Re: [compress] Strong Crypto in Tests

On 2013-10-23, Mark Fortner wrote: > As you're probably aware, aes is export restricted. Commons Compress already has a crypto notice, see also 7z uses 256bit AES when encrypting so if we want to provide code that can read encrypted archives there is lit

Re: [compress] Strong Crypto in Tests

On 2013-10-23, Paul Benedict wrote: > In my own research on strong crypto, I found out that US law allows > strong crypto to be exported for open source software. That was some > provision recently carved out in the last 10 years. I think there are > some limitations and procedures wrapped around

Re: [compress] Strong Crypto in Tests

On 2013-10-23, Bear Giles wrote: > Should that be PKCS7Padding? Or would that be worse - I don't recall > if it's one of the "must have" paddings in the spec. 7z uses "AES/CBC/NoPadding" and that's what I use during the check inside the unit tests as well now. Stefan ---

Re: [compress] Strong Crypto in Tests

On 2013-10-23, Jörg Schaible wrote: > boolean supportedKeyLength(int keyLen) throws NoSuchAlgorithmException > { >if (Cipher.getMaxAllowedKeyLength("AES/ECB/PKCS5Padding") < keyLen) { > System.err.println("WARNING: " + getName() >+ " not executed, environment does not support "

[compress] Strong Crypto in Tests

On 2013-10-23, Emmanuel Bourg wrote: > The test coverage is much better, thank you Stefan. Thank you for making me find a serious bug by pointing out the low coverage :-) > test7zDecryptUnarchive failed on Linux using the Java 6 JDK (not > OpenJDK6) due to the lack of the strong crypto policy. T

[VOTE] Release Compress 1.6 based on RC3

Compress 1.6 RC3 is available for review here: https://dist.apache.org/repos/dist/dev/commons/compress/ (svn revision 3327) Maven artifacts are here: https://repository.apache.org/content/repositories/orgapachecommons-ABC/org/apache/commons/commons-compress/1.6/ Details of chan

Re: [CANCELLED VOTE] Release Compress 1.6 based on RC2

On 2013-10-22, Gary Gregory wrote: > On Tue, Oct 22, 2013 at 11:02 AM, Stefan Bodewig wrote: >> On 2013-10-21, Gary Gregory wrote: >>> On Mon, Oct 21, 2013 at 11:11 AM, Stefan Bodewig >> wrote: >>>> at the same time I'll update the release note

Re: [CANCELLED VOTE] Release Compress 1.6 based on RC2

On 2013-10-21, Gary Gregory wrote: > On Mon, Oct 21, 2013 at 11:11 AM, Stefan Bodewig wrote: >> at the same time I'll update the release notes to reflect the potential >> backwards incompatible change as well. > OK, sounds good. I'll look forward to the next RC

Re: svn commit: r1534216 - /commons/proper/fileupload/trunk/pom.xml

On 2013-10-22, Mark Thomas wrote: > On 22/10/2013 08:12, Emmanuel Bourg wrote: >> Le 22/10/2013 00:33, Mark Thomas a écrit : >>> On 21/10/2013 23:31, Emmanuel Bourg wrote: >>> Thatis using Fileupload as a noun which isn't the correct usage of the >>> trademark. >> But how is it different from "A

[CANCELLED VOTE] Release Compress 1.6 based on RC2

Hi, while writing additional tests I found SevenZOutFile wasn't handling directories correctly - or rather its handling of anything empty isn't correct. I'll add new tests, fix the implementation and re-roll another RC - at the same time I'll update the release notes to reflect the potential back

Re: [VOTE] Release Compress 1.6 based on RC2

On 2013-10-16, Gary Gregory wrote: > Now that we have a new cleaned up RC, I want to make sure that we > understand that, strictly speaking and while unlikely in practice, > 1.6-RC2 breaks binary compatibility with 1.5 (see Clirr). I think we > started discussing this and after some hand-waving so

Re: [VOTE] Release Compress 1.6 based on RC2

On 2013-10-15, Stefan Bodewig wrote: > Please review the release candidate and vote. +1 [making my own vote explicit] Stefan - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail:

[VOTE] Release Compress 1.6 based on RC2

Hi all, I've addressed most of the issues brought up during the RC1 vote. I'll have limited net time the next three days, but hopefully I won't be needed. Stefan Compress 1.6 RC2 is available for review here: https://dist.apache.org/repos/dist/dev/commons/compress/ (svn revision 3272)

Re: [compress] Dave's Code Review (was Re: [CANCELLED][VOTE] Release Commons Compress 1.6)

On 2013-10-15, Stefan Bodewig wrote: > But we probably should store the password as a char[] anyway s/char/byte/ Stefan - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: de

[compress] Dave's Code Review (was Re: [CANCELLED][VOTE] Release Commons Compress 1.6)

Hi I'm going to address Dave's three mails in a single response dam6923 . wrote: > In SevenZFile.java > > Constructor... > 1) Close file on exception instead of the current technique of keeping > a "succeeded" flag. This means I have to catch and rethrow the exception. I don't think I like th

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