Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

COMPRESS-375 Allow the deferred creation of ZipArchiveEntry for parallel zips #12

Closed
wants to merge 1 commit into from
Closed

COMPRESS-375 Allow the deferred creation of ZipArchiveEntry for parallel zips #12

wants to merge 1 commit into from

Conversation

plamentotev
Copy link
Contributor

This is my attempt to implement the changes suggested in COMPRESS-375.

@coveralls
Copy link

coveralls commented Dec 3, 2016

Coverage Status

Coverage increased (+0.008%) to 82.616% when pulling 60fe42d on plamentotev:COMPRESS-375-ZipArchiveEntryRequestSupplier into 9238eab on apache:master.

@plamentotev plamentotev changed the title COMPRESS-375 Allow the differed creation of ZipArchiveEntry for parallel zips COMPRESS-375 Allow the deffered creation of ZipArchiveEntry for parallel zips Dec 3, 2016
@plamentotev plamentotev changed the title COMPRESS-375 Allow the deffered creation of ZipArchiveEntry for parallel zips COMPRESS-375 Allow the deferred creation of ZipArchiveEntry for parallel zips Dec 3, 2016
…allel zips

In some cases when creating parallel zip archive the `ZipArchiveEntry`
to be added could not be created before the `InputStream` is read.
In those cases there is no point in passing `ZipArchiveEntry` and
`InputStreamSupplier` as you can't actually defer the creation
of the `InputStream` as it's needed for the `ZipArchiveEntry`.

Add `ZipArchiveEntryRequestSupplier` to allow the deferred
creation of both `ZipArchiveEntry` and `InputStream`.
@coveralls
Copy link

coveralls commented Dec 3, 2016

Coverage Status

Coverage increased (+0.03%) to 82.634% when pulling 3e8a619 on plamentotev:COMPRESS-375-ZipArchiveEntryRequestSupplier into 9238eab on apache:master.

@plamentotev
Copy link
Contributor Author

plamentotev commented Dec 3, 2016

Hmm, looks like @coveralls acts strange. The first time it says my commits are increasing the code coverage and after that they are decreasing it. And there are no code changes - I only fixed the commit message.

@bodewig
Copy link
Member

bodewig commented Dec 4, 2016

Don't worry about Coveralls, I see the same behaviour for other projects as well.

I think this is related to our Travis CI setup using different JDKs and Coveralls picks whichever build finishes first. For different JDKs you get slightly different coverage values.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
3 participants