Re: [All] Convention for "courtesy" codes?

On 2018-02-10, Gilles wrote: > On Sat, 10 Feb 2018 08:08:12 -0700, Gary Gregory wrote: >> If a Java package and artifact ID contain "internal" or "private" in >> the >> name, that would be pretty clear. > Do you suggest that, say, the benchmarking codes in > "commons-rng-jmh" should be located in

Re: Updating the web site

On 2018-02-23, Jochen Wiedmann wrote: > I urgently need to update the page on [1]. Now, could someone, please > explain to me in plain, simple words (suitable for a 54 years old, or, > even worse: Me), how to do that using cms.apache.org? You don't (directly) use the CMS at all. http://commons.a

Re: [COMPRESS] TIFF file identified as TAR

On 2018-02-27, Allison, Timothy B. wrote: >On TIKA-2591[0], a user reports that a specific type of TIFF is >being identified as a TAR file. Is this something we should try to >fix at the Tika level, or is this something that would be better >fixed in COMPRESS? TAR auto-detection

Re: [COMPRESS] TIFF file identified as TAR

On 2018-02-27, Stefan Bodewig wrote: > On 2018-02-27, Allison, Timothy B. wrote: >>On TIKA-2591[0], a user reports that a specific type of TIFF is >>being identified as a TAR file. Is this something we should try to >>fix at the Tika level, or is this something

[all] Maven Build with Java 10/11?

Hi all I wanted to see whether anything was broken in COMPRESS with the Java10 RC or the EA version of Java11 - unfortunately the build fails with NullPointerException inside of Surefire. I run $ mvn clean test '-P!jacoco' as Jacoco doesn't seem to work for Java10+ either. I end up with [ERROR

Re: [all] Maven Build with Java 10/11?

On 2018-03-09, Stephen Colebourne wrote: > Just to note that surefire v2.21.0 is out now. No idea if that helps. > Stephen It does, many thanks. Strangely it also helps with Java11, so I guess the newer Surefire doesn't use SystemUtils.isJavaVersionAtLeast anymore. I'll update commons-parent.

Re: [all] Maven Build with Java 10/11?

On 2018-03-09, Stefan Bodewig wrote: > On 2018-03-09, Stephen Colebourne wrote: >> Just to note that surefire v2.21.0 is out now. No idea if that helps. >> Stephen > I'll update commons-parent. Somebody el

[CVE-2018-1324] Apache Commons Compress denial of service vulnerability

CVE-2018-1324: Apache Commons Compress denial of service vulnerability Severity: Low Vendor: The Apache Software Foundation Versions Affected: Apache Commons Compress 1.11 to 1.15 Description: A specially crafted ZIP archive can be used to cause an infinite loop inside of Compress' extra field

[compress][io] Avoid InputStream#skip?

Hi all while looking into https://issues.apache.org/jira/browse/COMPRESS-449 I realized that calling skip on any InputStream probably means you are up to receiving an IOException because some stream in there decided to implement skip via seek and now faces a stream that doesn't support seek. And t

Re: [VOTE] Migrate existing Git repos to GitBox

On 2018-04-22, Matt Sicker wrote: > This is a vote to migrate existing Git repositories from the old git-wip-us > infrastructure to the new gitbox infrastructure. New Apache projects are > not allowed to use git-wip-us and are instead directed to use gitbox. As > such, it makes sense for us to sta

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

On 2018-04-22, Gary Gregory wrote: > We should at the very least document all of this carefully. commons-io's IOUtils already quite clearly states it is using read and not using skip at all. > My gut reaction is that an API called skip should call skip internally. > Doing anything else clever as

[compress] High Level API for Archives

Hi all I've started to work on COMPRESS-118 and added Archiver and Expander classes - without any tests for now. As I'm trying to cover a bunch of possible use cases there are lots of inputs or outputs that can represent archives. When expanding archives you may want to use auto-detect the format

[compress] Need Help With PAX Exam Tests

Hi all I'm trying to resolve COMPRESS-443 which talks about having a regression test that fails if we break the OSGi bundle again (has already happened three times duing the life of Compress so far). But unfortunately I'm getting stuck with my limited Maven and even more limited PAX Exam Fu. You

Re: [compress] Need Help With PAX Exam Tests

On 2018-04-24, Gary Gregory wrote: > You should take a look at the Log4j 2 module log4j-osgi. We do some "bare > bones let's make sure we can load modules" tests using both Eclipse Equinox > and Apache Felix. Will do, thanks. Stefan --

Re: [compress] High Level API for Archives

On 2018-04-23, Torsten Curdt wrote: > TBH I am not such super big fan of adding and maintaining a high level > API at this stage. You will never find the right abstraction that > everyone is happy with. TIt's not my intention to make everybody happy, there will still be use cases that won't be c

Re: [compress] Need Help With PAX Exam Tests

On 2018-04-24, Oliver Heger wrote: > at work we used PaxExam to test OSGi-based applications consisting of > multiple modules. Here the (integration) tests have always been in a > separate module as they require a more complex setup. > To have only a single module, maybe it would work to run the

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

On 2018-04-23, sebb wrote: > On 23 April 2018 at 19:45, Stefan Bodewig wrote: >> On 2018-04-22, Gary Gregory wrote: >>> We should at the very least document all of this carefully. >> commons-io's IOUtils already quite clearly states it is using read and >>

Re: [compress] Need Help With PAX Exam Tests

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

Re: [compress] Need Help With PAX Exam Tests

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

Re: [compress] Need Help With PAX Exam Tests

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

Re: [compress] High Level API for Archives

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

Re: [compress] High Level API for Archives

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

Re: [compress] High Level API for Archives

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

Re: [compress] High Level API for Archives

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

Re: [compress] High Level API for Archives

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

Re: [compress] High Level API for Archives

On 2018-04-29, Matt Sicker wrote: > On 29 April 2018 at 06:24, Stefan Bodewig wrote: >> I'm not sure what you mean by modular in this context. > As in one module/jar per implementation. One module for a zipfs, one for an > sshfs, etc., instead of just "commons-vfs&quo

Re: [compress] High Level API for Archives

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

[compress][POLL] High Level API

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

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

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

Re: [compress] High Level API for Archives

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

Re: [compress][POLL] High Level API

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

Re: [compress][POLL] High Level API

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

Re: [compress][POLL] High Level API

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

[compress] High Level API / Examples

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

Re: [compress] High Level API / Examples

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

[compress] Thinking about 1.17 release

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

Re: [compress] Thinking about 1.17 release

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

[io] Black Duck apparently sees vulnerability in 2.5

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

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

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

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

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

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

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

[VOTE] Release Compress 1.17 based on RC1

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

Re: [VOTE] Release Compress 1.17 based on RC1

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

[RESULT] Release Compress 1.17 based on RC1

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

[ANN] Apache Commons Compress 1.17 Released

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

Re: [ANN] Apache Commons Compress 1.17 Released

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

[compress] close() and writing invalid streams

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

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

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

[compress] Cutting 1.18 soon

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

Re: [compress] Cutting 1.18 soon

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

Re: [compress] Cutting 1.18 soon

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

[parent] japicmp problems

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

Re: [parent] japicmp problems

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

Re: [parent] japicmp problems

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

[VOTE] Release Compress 1.18 based on RC1

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

Re: [VOTE] Release Compress 1.18 based on RC1

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

Re: [VOTE] Release Compress 1.18 based on RC1

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

Re: [VOTE] Release Compress 1.18 based on RC1

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

[RESULT] Release Compress 1.18 based on RC1

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

[ANN] Apache Commons Compress 1.18 Released

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

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

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

[parent] change in commons.scmPubUrl in Parent 47

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

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

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

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

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

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

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

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

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

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

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

Re: Use of Java 8 features in the commons

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

Re: [ALL] SHA256/512 hashes

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

Re: [ALL] SHA256/512 hashes

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

Re: [ALL] SHA256/512 hashes

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

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

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

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

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

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

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

Re: Multiplicity of GitBox messages

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

Re: [VOTE] Redirect github notifications to issues@

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

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

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

Re: [ALL] Why is the component's web site part of the release vote?

On 2016-12-08, Gilles wrote: > Hi. > I've just noticed a small problem in the (staged) web site > submitted for the release of Commons RNG v1.0: > http://home.apache.org/~erans/commons-rng-1.0-RC6-site/rat-report.html > Since this must be fixed in the regenerated site will > not reflect the re

Re: [compress] release?

On 2016-12-09, Gary Gregory wrote: > What is the outlook on a release? I'd like to make use of > in LZMACompressorOutputStream. There are two unresolved issues assigned to 1.13. No idea who assigned them but it would be good if who ever did it could look into them: https://issues.apache.org/jira

Re: [1/2] commons-compress git commit: [COMPRESS-362] Bullet-proof code using try-with-resources statements.

On 2016-12-09, wrote: > Repository: commons-compress > Updated Branches: > refs/heads/master 05415c0ee -> c3d2cecc8 > http://git-wip-us.apache.org/repos/asf/commons-compress/blob/c3d2cecc/src/main/java/org/apache/commons/compress/archivers/zip/ZipFile.java you've changed line-ends on this fi

Re: [compress] release?

On 2016-12-09, Gary Gregory wrote: > On Thu, Dec 8, 2016 at 9:19 PM, Stefan Bodewig wrote: >> On 2016-12-09, Gary Gregory wrote: >>> What is the outlook on a release? I'd like to make use of >>> in LZMACompressorOutputStream. >> There are two unresolve

Re: [compress] release?

On 2016-12-09, Gary Gregory wrote: > Just FWIW, we fail on Java 9 with: > Failed tests: > X5455_ExtendedTimestampTest.testSampleFile:185 > expected:<[2105-01-01/00:00:02] +> but was:<[1968-11-24/17:31:45] +> > Tests in error: > SevenZNativeHeapTest.initializationError » Objenesis > ja

Re: [1/2] commons-compress git commit: [COMPRESS-362] Bullet-proof code using try-with-resources statements.

On 2016-12-09, Gary Gregory wrote: > My setting in appear to be "AutoCrLf". I can make that explicit to some > value like... true/false/warn (this is in TortoiseGit). Egit is broken for > me ATM. I don't use either. Do you know whether TortoiseGit honors .gitattributes? We've already got this in

[compress] SonarQube Build Added

Hi all I've added https://builds.apache.org/view/Apache%20Commons/job/Commons-Compress%20SonarQube/ which results in https://builds.apache.org/analysis/overview?id=12601 Right now it builds whenever the "normal" build has been successfull and I intend to enable email on failed builds once I figur

Re: Fwd: Developing fix that spans across several Apache projects

On 2016-12-19, Gary Gregory wrote: > FYI: We have an Apache project waiting on a Commons Compress release. AFAICT we could cut a release immediately, I've been waiting for you and COMPRESS-362 before re-raising the issue. I don't see a real solution for COMPRESS-376 (which I promised to look into

Re: interested in contributing

Welcome Shan On 2016-12-20, Padmashantha Rajapakshe wrote: > I have 10+ years of Java experience, so would like to contribute for > common project at the beginner level. This sounds great. > really appreciate if guide me with initial setup. Commons isn't a whole but rather a group of component

[all] Clirr or japicmp - does either work for anybody?

Hi I'm trying to figure out how to get a report on API changes in compress. If I enable Clirr the site build dies with a NullPointerException (I vaguely recall it might work if I used Java7, so that might by my last resort). If I enable japicmp it dies because it thinks it has found binary incom

Re: [all] Clirr or japicmp - does either work for anybody?

On 2016-12-21, Gilles wrote: > On Tue, 20 Dec 2016 16:35:46 +0100, Stefan Bodewig wrote: >> Hi >> I'm trying to figure out how to get a report on API changes in >> compress. >> If I enable Clirr the site build dies with a NullPointerException (I >> vaguel

[compress] nearing 1.13 release, backwards incompatible change(?)

Hi I've managed to build japicmp reports for COMPRESS, the full site of the current master is at http://stefan.samaflost.de/staging/commons-compress-1.13/ If you look at http://stefan.samaflost.de/staging/commons-compress-1.13/japicmp-maven-plugin-report.html you'll see a few strange things. Some

[parent] japicmp configuration

Hi I've just figured out how to get japicmp working for me and have a few questions / suggestions for the parent POM. Currently the configuration of the plugin happens inside the pluginManagement section, not inside the japicmp profile. Should we move this? The current configuration breaks the b

Re: [compress] nearing 1.13 release, backwards incompatible change(?)

On 2016-12-22, sebb wrote: > On 22 December 2016 at 07:28, Stefan Bodewig wrote: >> Hi >> I've managed to build japicmp reports for COMPRESS, the full site of the >> current master is at >> http://stefan.samaflost.de/staging/commons-compress-

Re: [compress] nearing 1.13 release, backwards incompatible change(?)

On 2016-12-22, Stefan Bodewig wrote: > On 2016-12-22, sebb wrote: >> Adding a thrown Exception does affect source compilation of calling >> code, but exceptions are not part of method signatures so do not >> affect BC. > All cases are completely new methods, there is n

Re: [compress] nearing 1.13 release, backwards incompatible change(?)

On 2016-12-22, Stefan Bodewig wrote: > On 2016-12-22, Stefan Bodewig wrote: >> On 2016-12-22, sebb wrote: >>> Adding a thrown Exception does affect source compilation of calling >>> code, but exceptions are not part of method signatures so do not >>> affect

Re: [parent] japicmp configuration

On 2016-12-22, Jörg Schaible wrote: > Stefan Bodewig wrote: >> Currently the configuration of the plugin happens inside the >> pluginManagement section, not inside the japicmp profile. Should we move >> this? > It does not really matter. Since profiles do not have a pl

Re: [compress] nearing 1.13 release, backwards incompatible change(?)

On 2016-12-22, Gary Gregory wrote: > It would be nice if you could push a Commons Parent release as well. Never done that, but I can try. > My RC1 failed on that front. Why did it fail? Stefan - To unsubscribe, e-mail: dev-un

[parent] Publishing src Distributions to Nexus?

Hi all the RC1 vote for Parent 42 failed because it no longer pulishes the source tarballs/zips to Nexus. The change was which has obviously been a conscious decision. A decision that I personally agree with, I've manually removed the

Re: [parent] Publishing src Distributions to Nexus?

On 2016-12-23, Charles Honton wrote: > Unfortunately, I have reverted that change for the moment. Many thanks. With that out of the way I'll try to release parent 42 and we can go from there with the next parent if we wanted to change the release process. Stefan ---

[VOTE][LAZY] Release Commons Parent 42 Based on RC3

Hi all as far as I can tell there has benver been a vote for RC2 but the tag exists, therefore I went with RC3 Parent 42 RC3 is available for review here: https://dist.apache.org/repos/dist/dev/commons/commons-parent/42-RC3/ (svn revision 17566) The tag is here: http://svn.apache.or

[VOTE] Release Compress 1.13 based on RC1

The Release Candidate is available for review at: https://dist.apache.org/repos/dist/dev/commons/compress/ (svn revision 17569) Maven artifacts are here: https://repository.apache.org/content/repositories/orgapachecommons-1231/org/apache/commons/commons-compress/1.13/ These are the Maven a

Re: [VOTE] Release Compress 1.13 based on RC1

Many thanks, Oliver On 2016-12-27, Oliver Heger wrote: > build works fine with Java 1.7 and 1.8 on Windows 10. Artifacts and site > look good. > When building the site with Java 1.8 I get the failure below. Is there > any special configuration needed? Could this be a Windows problem? > [INFO] G

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