Re: [compress] TarArchiveEntry and Windows drive letter

On 22 January 2018 at 09:53, Stefan Bodewig wrote: > On 2018-01-21, sebb wrote: > >> On 21 January 2018 at 16:07, Stefan Bodewig wrote: > >>> The contract of tar archives is they contain relative path names. GNU >>> tar strips leading slashes both when

Re: [compress] TarArchiveEntry and Windows drive letter

On 2018-01-21, sebb wrote: > On 21 January 2018 at 16:07, Stefan Bodewig wrote: >> The contract of tar archives is they contain relative path names. GNU >> tar strips leading slashes both when creating archives and when >> extracting archives who's entry names contain

Re: [compress] TarArchiveEntry and Windows drive letter

that from Ant and it really stems from a rather odd usecase > over there. > >>> I could be convinced that we should only strip drive letters when we >>> don't preserve leading slashes either :-) > >> IMO there is just no case at all when compress should strip driv

Re: [compress] TarArchiveEntry and Windows drive letter

ip drive letters when we >> don't preserve leading slashes either :-) > IMO there is just no case at all when compress should strip drive letters. > Sure it might be convenient (for some) but this is too much magic. Again, I have no idea what tar ports do on Windows. By now all my Wind

Re: Build failed in Jenkins: Commons-Compress-Windows #455

che Jenkins Server <jenk...@builds.apache.org> > Date: Tue, Jan 9, 2018 at 12:28 PM > Subject: Build failed in Jenkins: Commons-Compress-Windows #455 > To: notificati...@commons.apache.org > > > See <https://builds.apache.org/job/Commons-Compress-Windows/ > 455/display/redirect

Re: [compress] javac uses --release on Jenkins/Windows

On 2018-01-10, sebb wrote: > I just changed the build to use Java 8 for running Maven (not for > compilation/testing) > [On the basis that one starts by fixing the easy issues] > This has got rid of the warning about using an incompatible Java. > Furthermore it seems to have fixed the main

Re: [compress] javac uses --release on Jenkins/Windows

I just changed the build to use Java 8 for running Maven (not for compilation/testing) [On the basis that one starts by fixing the easy issues] This has got rid of the warning about using an incompatible Java. Furthermore it seems to have fixed the main problem. Looks like when Jenkins retries

[compress] javac uses --release on Jenkins/Windows

Hi all has anybody got any idea why javac should suddenly start using --release for a Java7 javac on the windows boxes but not for Linux? I recall Gary updatng all kinds of Maven plugins as well as infra updating the jenkins nodes to run Java9 but the build explicitly selects Java7 - and this

Re: [compress]

On 2018-01-09, Gary Gregory wrote: > Any one else seeing this? I have changed the gitattributes after you first reported it. If your version of git honors it you can apply the attributes to your existing working copy by pulling, removing .git/index and then running "git reset --hard". Stefan

Re: [compress]

Indeed this reeks of Windows vs. Linux... Gary On Tue, Jan 9, 2018 at 2:23 PM, Matt Sicker wrote: > ASCII 13 is \r and 10 is \n. I bet it's a Windows line encoding related > issue specifically. > > On 9 January 2018 at 13:20, Gary Gregory wrote: > > >

Fwd: Build failed in Jenkins: Commons-Compress-Windows #455

Does anyone know how to fix this? Gary -- Forwarded message -- From: Apache Jenkins Server <jenk...@builds.apache.org> Date: Tue, Jan 9, 2018 at 12:28 PM Subject: Build failed in Jenkins: Commons-Compress-Windows #455 To: notificati...@commons.apache.org See

Re: [compress]

ASCII 13 is \r and 10 is \n. I bet it's a Windows line encoding related issue specifically. On 9 January 2018 at 13:20, Gary Gregory wrote: > Any one else seeing this? > > [INFO] Running > org.apache.commons.compress.compressors.zstandard. > ZstdCompressorInputStreamTest

[compress]

Any one else seeing this? [INFO] Running org.apache.commons.compress.compressors.zstandard.ZstdCompressorInputStreamTest [ERROR] Tests run: 8, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.034 s <<< FAILURE! - in

Re: [compress] TarArchiveEntry and Windows drive letter

on is how to fix it without breaking too many things. I am not such a big fan of "preserveLeadingSlashes" either. I could be convinced that we should only strip drive letters when we > don't preserve leading slashes either :-) > IMO there is just no case at all when compress should strip drive lette

Re: commons-compress git commit: Update XZ for Java dependency

Great news. Thank you for the update. Gary On Thu, Jan 4, 2018 at 10:58 AM, Stefan Bodewig wrote: > On 2018-01-04, Gary Gregory wrote: > > > Didn't XZ change their Java reqs? > > XZ 1.7 was compiled with -target 9 and I asked whether this was an > intentional change. Turned

Re: commons-compress git commit: Update XZ for Java dependency

On 2018-01-04, Gary Gregory wrote: > Didn't XZ change their Java reqs? XZ 1.7 was compiled with -target 9 and I asked whether this was an intentional change. Turned out is was not and XZ 1.8 changed the Java requirement back to 5. Kudos to Lasse Collin for pushing out the next release quickly.

Re: commons-compress git commit: Update XZ for Java dependency

Didn't XZ change their Java reqs? Gary On Thu, Jan 4, 2018 at 9:55 AM, <bode...@apache.org> wrote: > Repository: commons-compress > Updated Branches: > refs/heads/master ff5fb8a7a -> c3be6fb3d > > > Update XZ for Java dependency > > > Project: http://git

Re: [compress] TarArchiveEntry and Windows drive letter

On 2018-01-03, Torsten Curdt wrote: > I just found a new issue with compress. > It's the "normalizeFileName" in TarArchiveEntry again. > On Windows it just strips the drive letter > https://github.com/apache/commons-compress/blob/master/src/ > main/java/org/apache/commo

Re: [compress] AR docs confusion

Thanks - that was quick :) On Wed, Jan 3, 2018 at 5:20 PM, Stefan Bodewig wrote: > On 2018-01-03, Torsten Curdt wrote: > > > I think I'd just add a little table. OK? > > I've gone ahead and added a table, just not regenerated the site, > > Stefan > >

Re: [compress] AR docs confusion

On 2018-01-03, Torsten Curdt wrote: > I think I'd just add a little table. OK? I've gone ahead and added a table, just not regenerated the site, Stefan - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For

Re: [compress] TarArchiveEntry and Windows drive letter

I do not see how skipping the drive letter on Windows is not normalizing, it is _moving_ sounds like a bug to me. Gary On Wed, Jan 3, 2018 at 8:46 AM, Torsten Curdt <tcu...@vafer.org> wrote: > I just found a new issue with compress. > > It's the "normalizeFileName"

[compress] TarArchiveEntry and Windows drive letter

I just found a new issue with compress. It's the "normalizeFileName" in TarArchiveEntry again. On Windows it just strips the drive letter https://github.com/apache/commons-compress/blob/master/src/ main/java/org/apache/commons/compress/archivers/tar/ TarArchiveEntry.java#L1337 whi

Re: [compress] AR docs confusion

On 3 January 2018 at 13:34, Torsten Curdt <tcu...@vafer.org> wrote: ... > I got one more thing... :) > I just found a new issue with compress. > It's the "normalizeFileName" in TarArchiveEntry again. On Windows it just > strips the drive letter > > > https

Re: [compress] AR docs confusion

nfused about the docs on the AR support > > in compress > > > https://commons.apache.org/proper/commons-compress/examples.html > > >> Commons Compress 1.0 to 1.2 can only read archives using the GNU/SRV4 > >> variant, support for the BSD variant has been adde

Re: [compress] AR docs confusion

to say I was a little confused about the docs on the AR support > in compress > https://commons.apache.org/proper/commons-compress/examples.html >> Commons Compress 1.0 to 1.2 can only read archives using the GNU/SRV4 >> variant, support for the BSD variant has been added in Commo

[compress] AR docs confusion

Someone raised an issue over at jdeb https://github.com/tcurdt/jdeb/issues/241 and I have to say I was a little confused about the docs on the AR support in compress https://commons.apache.org/proper/commons-compress/examples.html Commons Compress 1.0 to 1.2 can only read archives using

Re: [compress] ZstdCompressorInputStreamTest failure

On 2017-12-30, Gary Gregory wrote: > With git master, I get: > ZstdCompressorInputStreamTest.testZstdDecode:59 arrays first differed at > element [70]; expected:<13> but was:<10> > Anyone else? Passes for me and Jenkins (even the Windows builds). My guess is your working copy has Windows

[compress] ZstdCompressorInputStreamTest failure

With git master, I get: ZstdCompressorInputStreamTest.testZstdDecode:59 arrays first differed at element [70]; expected:<13> but was:<10> Anyone else? Gary

Re: [compress] release for Zstandard?

On 2017-12-22, Gary Gregory wrote: > When can we get a [compress] release? It would be nice to get Zstandard out > there. It's incomplete as it is read-only and adding write support would be as trivial as adding read-only support has been. It's only a matter of finding tme to do it. In ad

[compress] release for Zstandard?

When can we get a [compress] release? It would be nice to get Zstandard out there. Gary

[compress] zstandard and [vfs]

If we get a new version of [compress] out with Zstandard, then we can update [vfs] to support it as well. Thoughts? Gary

Re: [1/2] commons-compress git commit: COMPRESS-423 - Add ZStandard decompression support using Zstd-JNI

On 2017-10-17, Gary Gregory wrote: > Should it be "Z_STANDARD" instead of "ZSTANDARD" since "standard" is a word? Zstandard seems to be the official captitalization: http://www.zstd.net/ But I should check whether it's been used consistently over the last few commits, I doubt it. Stefan

Re: [1/2] commons-compress git commit: COMPRESS-423 - Add ZStandard decompression support using Zstd-JNI

Should it be "Z_STANDARD" instead of "ZSTANDARD" since "standard" is a word? Gary On Tue, Oct 17, 2017 at 12:23 PM, <bode...@apache.org> wrote: > Repository: commons-compress > Updated Branches: > refs/heads/master 89bc17055 -> 1c382914c

Re: [ANN] Apache Commons Compress 1.15 Released

Thank you Stefan for shepherding this release. Gary On Tue, Oct 17, 2017 at 11:55 AM, Stefan Bodewig <bode...@apache.org> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > The Apache Commons Team is pleased to announce the release of Apache > Commons Compress

[ANN] Apache Commons Compress 1.15 Released

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

[RESULT] Release Compress 1.15 based on RC1

Hi all with +1s by Bruno P. Kinoshita, Gary Gregory, Oliver Heger and my own implicit one the vote has passed. I'll publish the artifacts, give the mirrors some time to catch up and announce the release later today. Thanks to all wh looked into the RC. Stefan

Re: [VOTE] Release Compress 1.15 based on RC1

Build works fine with Java 1.7 and 1.8 on Windows 10. Artifacts and site look good. +1 Oliver Am 14.10.2017 um 15:45 schrieb Stefan Bodewig: > Hi all > > this is mostly a bugfix release but it was about time for a new release. > > Compress 1.15 RC1 is available for review he

Re: [VOTE] Release Compress 1.15 based on RC1

ows" > > Not a blocker: > > [WARNING] Javadoc Warnings > [WARNING] C:\temp\rc\commons-compress-1.15-src\src\main\java\org\ > apache\commons\compress\archivers\zip\ZipLong.java:127: warning: no > description for @return > [WARNING] * @return > [WARNING] ^ > [W

Re: [VOTE] Release Compress 1.15 based on RC1

On 2017-10-15, Bruno P. Kinoshita wrote: > Oh, don't know how I didn't see the building file. Will make a mental > note to look for it the next time :-) thank you. No, thank you. I've made a mental note to include site building instructions with the vote thread next time :-) Stefan

Re: [VOTE] Release Compress 1.15 based on RC1

96-generic", arch: "amd64", family: "unix" Had a quick look at release notes, readme, building, and notice files. Everything looks OK. Checked signatures from staged artefacts in Maven, found no issues. Thank you for taking your time to

Re: [VOTE] Release Compress 1.15 based on RC1

9 2017 +0200 prepare RC1 of Commons Compress 1.15 Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-11T05:41:47+13:00) Maven home: /opt/maven Java version: 1.8.0_144, vendor: Oracle Corporation Java home: /usr/lib/jvm/java-8-oracle/jre Default locale: en_US, platform en

Re: [VOTE] Release Compress 1.15 based on RC1

On 2017-10-15, Bruno P. Kinoshita wrote: > I may be doing something wrong, but the site generation with `mvn > clean site` appears to be failing [snip] > With: > (...) > [INFO] Loading execution data file > /home/kinow/Development/java/apache/commons-compress/target/j

Re: [VOTE] Release Compress 1.15 based on RC1

Hi, I may be doing something wrong, but the site generation with `mvn clean site` appears to be failing on $ git log -n 1 commit 01b06d5ef5c5ac3bd651bedcfec7433231cea371 Author: Stefan Bodewig <bode...@apache.org> Date: Sat Oct 14 15:17:09 2017 +0200 prepare RC1 of Commons Compres

Re: [VOTE] Release Compress 1.15 based on RC1

: Cp1252 OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows" Not a blocker: [WARNING] Javadoc Warnings [WARNING] C:\temp\rc\commons-compress-1.15-src\src\main\java\org\apache\commons\compress\archivers\zip\ZipLong.java:127: warning: no des

[VOTE] Release Compress 1.15 based on RC1

Hi all this is mostly a bugfix release but it was about time for a new release. Compress 1.15 RC1 is available for review here: https://dist.apache.org/repos/dist/dev/commons/compress/ (svn revision 22476) The tag is here: https://git-wip-us.apache.org/repos/asf?p=commons-compress.git

Re: [compress] Cutting 1.15

Go for it! :-) Gary On Oct 8, 2017 11:46, "Stefan Bodewig" wrote: > Hi all > > there's not been the single big feature or bugfix since 1.14, but we've > accumulated a few changes. Also the last release hasn't included the > Automatic-Module name while master does. > > I

[compress] Cutting 1.15

Hi all there's not been the single big feature or bugfix since 1.14, but we've accumulated a few changes. Also the last release hasn't included the Automatic-Module name while master does. I plan to cut a new release, likely by the next weekend. If you feel there is an important issue that

Re: [compress] Tar stream signature detection regression as of 1.11

.14 As already pointed out by James Ring, please see https://issues.apache.org/jira/browse/COMPRESS-331 The code in 1.10 would accept streams as tar archives that were not valid. We made the check as strict as the one of GNU tar and only accept streams with a correct header checksum as tar archiv

Re: [compress] Tar stream signature detection regression as of 1.11

According to git bisect, 1fb42987de0d21c9b6777272320b64230eadb277 is the first bad commit commit 1fb42987de0d21c9b6777272320b64230eadb277 Author: Stefan Bodewig <bode...@apache.org> Date: Sun Jan 31 13:12:31 2016 +0100 COMPRESS-331 make tar checksum check as strict as GNU tar

[compress] Tar stream signature detection regression as of 1.11

Hello, I think I may have found a regression in ArchiveFormatFactory.createArchiveInputStream. Please run the JUnit testcase at the end of this mail. It demonstrates the archive detection working with 1.10, but failing from 1.11 through 1.14 The file "COMPRESS-117.tar" is taken fr

Re: [compress] HasCharset is a bad name

On Wed, Jul 12, 2017 at 6:32 AM, Benedikt Ritter wrote: > Hello, > > > Am 11.07.2017 um 06:55 schrieb Simon Spero : > > > > Since it's an interface, I could change it to IHasACharset? > > > > Or If you prefer I could rename it to YouGiveLove? (Lucky

Re: [compress] HasCharset is a bad name

Hello, > Am 11.07.2017 um 06:55 schrieb Simon Spero : > > Since it's an interface, I could change it to IHasACharset? > > Or If you prefer I could rename it to YouGiveLove? (Lucky Millenials- you > aren't headsonged) I recommend to leave this kind of irony out of mailing

Re: [compress] HasCharset is a bad name

HasCharset is certainly bad and also CharsetAccessor sounds like class name not as Interface , I think Charsetable CharsetAccesable or CharsetAware Is better as Interface name. Regards, Amey On Tue, Jul 11, 2017, 3:33 AM Gary Gregory wrote: > I renamed HasCharset to

Re: [compress] HasCharset is a bad name

Since it's an interface, I could change it to IHasACharset? Or If you prefer I could rename it to YouGiveLove? (Lucky Millenials- you aren't headsonged) The name follows a pattern for interfaces of this sort, which are basically retrofit markers for the presence of property, (with associated

Re: [compress] HasCharset is a bad name

the book! ;-) On Mon, Jul 10, 2017 at 5:29 PM, Matt Sicker wrote: > The colour, dish, or liqueur? Or mountains apparently. > > On 10 July 2017 at 17:53, Gary Gregory wrote: > > > On Mon, Jul 10, 2017 at 3:04 PM, Matt Sicker wrote: >

Re: [compress] differences in implementation of Zip ibm vs. oracle?

:32 PM, "Allison, Timothy B." <talli...@mitre.org> wrote: Compress colleagues, Over on https://bz.apache.org/bugzilla/show_bug.cgi?id=61275, a user submitted two .xlsx files generated with Apache POI, one by IBM's jvm and one by Oracle's jvm. The file generated with Oracle's j

Re: [compress] HasCharset is a bad name

The colour, dish, or liqueur? Or mountains apparently. On 10 July 2017 at 17:53, Gary Gregory wrote: > On Mon, Jul 10, 2017 at 3:04 PM, Matt Sicker wrote: > > > Charsetable? CharsetAware? ;P > > > > Chartreuse? ChartreuseDeParme? > > Gary > > > > > >

Re: [compress] HasCharset is a bad name

On Mon, Jul 10, 2017 at 3:04 PM, Matt Sicker wrote: > Charsetable? CharsetAware? ;P > Chartreuse? ChartreuseDeParme? Gary > > On 10 July 2017 at 17:03, Gary Gregory wrote: > > > I renamed HasCharset to CharsetAccessor (until someone comes up with a

Re: [compress] HasCharset is a bad name

Charsetable? CharsetAware? ;P On 10 July 2017 at 17:03, Gary Gregory wrote: > I renamed HasCharset to CharsetAccessor (until someone comes up with a > better name before 1.15.) > > Gary > > On Wed, Jul 5, 2017 at 11:57 PM, Stefan Bodewig > wrote: > >

Re: [compress] HasCharset is a bad name

I renamed HasCharset to CharsetAccessor (until someone comes up with a better name before 1.15.) Gary On Wed, Jul 5, 2017 at 11:57 PM, Stefan Bodewig wrote: > On 2017-07-05, Gary Gregory wrote: > > > The new interface name HasCharset is pretty bad IMO. > > fair enough. > >

[compress] differences in implementation of Zip ibm vs. oracle?

Compress colleagues, Over on https://bz.apache.org/bugzilla/show_bug.cgi?id=61275, a user submitted two .xlsx files generated with Apache POI, one by IBM's jvm and one by Oracle's jvm. The file generated with Oracle's jvm opens without issue; however, MSOffice complains but can fix the file

Re: [compress] HasCharset is a bad name

On 2017-07-05, Gary Gregory wrote: > The new interface name HasCharset is pretty bad IMO. fair enough. > CharsetProvider is the obvious (to me) better name even though there > already is a class called java.nio.charset.spi.CharsetProvider. I don't think so, this really is a marker interface

Re: [compress] HasCharset is a bad name

Supplied and Provider are both good. Gary On Wed, Jul 5, 2017 at 10:22 AM, Jeremy Gustie < jgus...@blackducksoftware.com> wrote: > CharsetSupplier? > > -Jeremy > > > On Jul 5, 2017, at 1:14 PM, Gary Gregory wrote: > > > > Hi All, > > > > The new interface name

Re: [compress] HasCharset is a bad name

CharsetSupplier? -Jeremy > On Jul 5, 2017, at 1:14 PM, Gary Gregory wrote: > > Hi All, > > The new interface name HasCharset is pretty bad IMO. > > CharsetProvider is the obvious (to me) better name even though there > already is a class called

[compress] HasCharset is a bad name

Hi All, The new interface name HasCharset is pretty bad IMO. CharsetProvider is the obvious (to me) better name even though there already is a class called java.nio.charset.spi.CharsetProvider. Alternatives could be CharsetContainer, CharsetAccessor, CharsetGetter, ? Gary

Re: [compress] FW: Tika content detection and crawled "remote" content

This looks great, well done Tika! Thank you for sharing, Tim Cheers Stefan On 2017-07-05, Allison, Timothy B. wrote: > Fellow file-philes on [compress], > Sebastian Nagel has added file type id via Apache Tika to Common Crawl. > While Tika is not 100% accurate, this mean

[compress] FW: Tika content detection and crawled "remote" content

Fellow file-philes on [compress], Sebastian Nagel has added file type id via Apache Tika to Common Crawl. While Tika is not 100% accurate, this means that we have far better clarity on mime type than relying on the http header+file suffix. So, for testing purposes, you (or we over on Tika

[GitHub] commons-compress issue #38: Testing hudson/jenkins (added contributor line t...

Github user sesuncedu commented on the issue: https://github.com/apache/commons-compress/pull/38 Hudkins is happy. Happy happy Hudkins. So I will close this. Though I think some of the changes might actually be useful. --- If your project is set up for it, you can reply

[GitHub] commons-compress pull request #38: Testing hudson/jenkins (added contributor...

Github user sesuncedu closed the pull request at: https://github.com/apache/commons-compress/pull/38 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so

[GitHub] commons-compress pull request #36: COMPRESS-410 Remove Non-NIO character set...

Github user sesuncedu closed the pull request at: https://github.com/apache/commons-compress/pull/36 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so

[GitHub] commons-compress pull request #36: COMPRESS-410 Remove Non-NIO character set...

GitHub user sesuncedu reopened a pull request: https://github.com/apache/commons-compress/pull/36 COMPRESS-410 Remove Non-NIO character set encoders. As a special case, the UTF-8 encoder will replace malformed / unmappable input with '?'. This behavior is required

[GitHub] commons-compress issue #36: COMPRESS-410 Remove Non-NIO character set encode...

Github user sesuncedu commented on the issue: https://github.com/apache/commons-compress/pull/36 reopening just to see if I didn't need to create a new branch and cherry pick --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub

Re: [compress][all]Fwd: Build failed in Jenkins: Commons-Compress PullRequest Builder #56

Hudkins is alive! On Tue, Jun 20, 2017 at 12:49 AM, Dave Fisher wrote: > Check with Infra weird errors are happening. > > Regards, > Dave > > Sent from my iPhone > > > On Jun 19, 2017, at 8:53 PM, Stefan Bodewig wrote: > > > >> On 2017-06-19, Gary

[GitHub] commons-compress issue #37: COMPRESS-410 - cherry picked to fix merging issu...

Github user coveralls commented on the issue: https://github.com/apache/commons-compress/pull/37 [](https://:/builds/12055314) Coverage increased (+0.04%) to 84.77% when pulling

[GitHub] commons-compress pull request #37: COMPRESS-410 - cherry picked to fix mergi...

Github user sesuncedu closed the pull request at: https://github.com/apache/commons-compress/pull/37 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so

[GitHub] commons-compress pull request #37: COMPRESS-410 - cherry picked to fix mergi...

GitHub user sesuncedu reopened a pull request: https://github.com/apache/commons-compress/pull/37 COMPRESS-410 - cherry picked to fix merging issues Remove non-NIO character set encoders. Fixes rebasing related issues in previous PR You can merge this pull request

[GitHub] commons-compress issue #38: Testing hudson/jenkins (added contributor line t...

Github user coveralls commented on the issue: https://github.com/apache/commons-compress/pull/38 [](https://:/builds/12055144) Coverage increased (+0.2%) to 84.885% when pulling

Re: [compress][all]Fwd: Build failed in Jenkins: Commons-Compress PullRequest Builder #56

Check with Infra weird errors are happening. Regards, Dave Sent from my iPhone > On Jun 19, 2017, at 8:53 PM, Stefan Bodewig wrote: > >> On 2017-06-19, Gary Gregory wrote: >> >> Is it just me or have there been Jenkins failures left and right for the >> last week or so? >

Re: [compress][all]Fwd: Build failed in Jenkins: Commons-Compress PullRequest Builder #56

On 2017-06-19, Gary Gregory wrote: > Is it just me or have there been Jenkins failures left and right for the > last week or so? That's the Jenkins job I've created for github pull requests and it fails whenever there are merge conflicts, for example. Right now it looks as if the workspace was

[compress][all]Fwd: Build failed in Jenkins: Commons-Compress PullRequest Builder #56

Is it just me or have there been Jenkins failures left and right for the last week or so? Gary -- Forwarded message -- From: Apache Jenkins Server <jenk...@builds.apache.org> Date: Mon, Jun 19, 2017 at 1:47 PM Subject: Build failed in Jenkins: Commons-Compress PullRequest B

[GitHub] commons-compress issue #38: Testing hudson/jenkins (added contributor line t...

Github user coveralls commented on the issue: https://github.com/apache/commons-compress/pull/38 [](https://:/builds/12038184) Coverage increased (+0.02%) to 84.744% when pulling

[GitHub] commons-compress issue #38: Testing hudson/jenkins (added contributor line t...

Github user coveralls commented on the issue: https://github.com/apache/commons-compress/pull/38 [](https://:/builds/12038134) Coverage decreased (-0.005%) to 84.723% when pulling

[GitHub] commons-compress issue #38: Testing hudson/jenkins (added contributor line t...

Github user coveralls commented on the issue: https://github.com/apache/commons-compress/pull/38 [](https://:/builds/12038097) Coverage increased (+0.02%) to 84.747% when pulling

[GitHub] commons-compress issue #38: Testing hudson/jenkins (added contributor line t...

Github user coveralls commented on the issue: https://github.com/apache/commons-compress/pull/38 [](https://:/builds/12037873) Coverage increased (+0.02%) to 84.747% when pulling

[GitHub] commons-compress issue #38: Testing hudson/jenkins (added contributor line t...

Github user coveralls commented on the issue: https://github.com/apache/commons-compress/pull/38 [](https://:/builds/12037816) Coverage increased (+0.02%) to 84.747% when pulling

[GitHub] commons-compress issue #38: Testing hudson/jenkins (added contributor line t...

Github user coveralls commented on the issue: https://github.com/apache/commons-compress/pull/38 [](https://:/builds/12037759) Coverage remained the same at 84.728% when pulling

[GitHub] commons-compress issue #38: Testing hudson/jenkins (added contributor line t...

Github user coveralls commented on the issue: https://github.com/apache/commons-compress/pull/38 [](https://:/builds/12037681) Coverage remained the same at 84.728% when pulling

[GitHub] commons-compress issue #38: Testing hudson/jenkins (added contributor line t...

Github user coveralls commented on the issue: https://github.com/apache/commons-compress/pull/38 [](https://:/builds/12037681) Coverage remained the same at 84.728% when pulling

[GitHub] commons-compress issue #38: Testing hudson/jenkins (added contributor line t...

Github user coveralls commented on the issue: https://github.com/apache/commons-compress/pull/38 [](https://:/builds/12037517) Coverage remained the same at 84.728% when pulling

[GitHub] commons-compress issue #38: Testing hudson/jenkins (added contributor line t...

Github user coveralls commented on the issue: https://github.com/apache/commons-compress/pull/38 [](https://:/builds/12037439) Coverage decreased (-0.005%) to 84.723% when pulling

[GitHub] commons-compress issue #38: Testing hudson/jenkins (added contributor line t...

Github user coveralls commented on the issue: https://github.com/apache/commons-compress/pull/38 [](https://:/builds/12036920) Coverage decreased (-0.008%) to 84.72% when pulling

[GitHub] commons-compress issue #38: Testing hudson/jenkins (added contributor line t...

Github user coveralls commented on the issue: https://github.com/apache/commons-compress/pull/38 [](https://:/builds/12036920) Coverage decreased (-0.008%) to 84.72% when pulling

[GitHub] commons-compress issue #38: Testing hudson/jenkins (added contributor line t...

Github user coveralls commented on the issue: https://github.com/apache/commons-compress/pull/38 [](https://:/builds/12036920) Coverage decreased (-0.005%) to 84.723% when pulling

[GitHub] commons-compress issue #38: Testing hudson/jenkins (added contributor line t...

Github user coveralls commented on the issue: https://github.com/apache/commons-compress/pull/38 [](https://:/builds/12036561) Coverage remained the same at 84.728% when pulling

[GitHub] commons-compress issue #38: Testing hudson/jenkins (added contributor line t...

Github user coveralls commented on the issue: https://github.com/apache/commons-compress/pull/38 [](https://:/builds/12036386) Coverage increased (+0.2%) to 84.885% when pulling

[GitHub] commons-compress issue #38: Testing hudson/jenkins (added contributor line t...

Github user coveralls commented on the issue: https://github.com/apache/commons-compress/pull/38 [](https://:/builds/12036300) Coverage increased (+0.02%) to 84.744% when pulling

[GitHub] commons-compress pull request #38: Testing hudson/jenkins (added contributor...

GitHub user sesuncedu opened a pull request: https://github.com/apache/commons-compress/pull/38 Testing hudson/jenkins (added contributor line to pom.xml so that there would be a change) They've been failing PRs on the checkout of master. Lets try this. You can merge this pull

[GitHub] commons-compress issue #37: COMPRESS-410 - cherry picked to fix merging issu...

Github user coveralls commented on the issue: https://github.com/apache/commons-compress/pull/37 [](https://:/builds/12027861) Coverage increased (+0.04%) to 84.77% when pulling

Build failed in Jenkins: Commons-Compress PullRequest Builder #30

See <https://builds.apache.org/job/Commons-Compress%20PullRequest%20Builder/30/display/redirect> -- GitHub pull request #37 to apache/commons-compress [EnvInject] - Loading node environment variables. Building remotely on H14 (ubuntu xenial) in wor

[GitHub] commons-compress issue #37: COMPRESS-410 - cherry picked to fix merging issu...

Github user coveralls commented on the issue: https://github.com/apache/commons-compress/pull/37 [](https://:/builds/12024033) Coverage decreased (-0.08%) to 84.652% when pulling

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