[jira] [Commented] (TEXT-29) Add a builder to StringEscapeUtils

[Rob Tompkins (JIRA)]

[ 
https://issues.apache.org/jira/browse/TEXT-29?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15710212#comment-15710212
 ] 

Rob Tompkins commented on TEXT-29:
--

I can look into this.

> Add a builder to StringEscapeUtils
> --
>
> Key: TEXT-29
> URL: https://issues.apache.org/jira/browse/TEXT-29
> Project: Commons Text
>  Issue Type: New Feature
>Reporter: Pascal Schumacher
>Priority: Minor
>
> supplied in patch for LANG-1066



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (TEXT-2) Add Jaccard Index and Jaccard Distance

[Rob Tompkins (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TEXT-2?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rob Tompkins resolved TEXT-2.
-
Resolution: Implemented

> Add Jaccard Index and Jaccard Distance
> --
>
> Key: TEXT-2
> URL: https://issues.apache.org/jira/browse/TEXT-2
> Project: Commons Text
>  Issue Type: New Feature
>Reporter: Bruno P. Kinoshita
>Priority: Minor
>
> Implement the Jaccard Index and Jaccard Distance as in 
> http://en.wikipedia.org/wiki/Jaccard_index



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TEXT-2) Add Jaccard Index and Jaccard Distance

[Rob Tompkins (JIRA)]

[ 
https://issues.apache.org/jira/browse/TEXT-2?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15710207#comment-15710207
 ] 

Rob Tompkins commented on TEXT-2:
-

I'm going to go ahead and close this jira now that we've got the change in.

> Add Jaccard Index and Jaccard Distance
> --
>
> Key: TEXT-2
> URL: https://issues.apache.org/jira/browse/TEXT-2
> Project: Commons Text
>  Issue Type: New Feature
>Reporter: Bruno P. Kinoshita
>Priority: Minor
>
> Implement the Jaccard Index and Jaccard Distance as in 
> http://en.wikipedia.org/wiki/Jaccard_index



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (TEXT-2) Add Jaccard Index and Jaccard Distance

[Rob Tompkins (JIRA)]

[ 
https://issues.apache.org/jira/browse/TEXT-2?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15710207#comment-15710207
 ] 

Rob Tompkins edited comment on TEXT-2 at 11/30/16 11:35 PM:


I'm going to go ahead and resolve this jira now that we've got the change in.


was (Author: chtompki):
I'm going to go ahead and close this jira now that we've got the change in.

> Add Jaccard Index and Jaccard Distance
> --
>
> Key: TEXT-2
> URL: https://issues.apache.org/jira/browse/TEXT-2
> Project: Commons Text
>  Issue Type: New Feature
>Reporter: Bruno P. Kinoshita
>Priority: Minor
>
> Implement the Jaccard Index and Jaccard Distance as in 
> http://en.wikipedia.org/wiki/Jaccard_index



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TEXT-31) Remove org.apache.commons.text.names

[Rob Tompkins (JIRA)]

[ 
https://issues.apache.org/jira/browse/TEXT-31?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15710170#comment-15710170
 ] 

Rob Tompkins commented on TEXT-31:
--

Processed by:
https://github.com/apache/commons-text/pull/13

> Remove org.apache.commons.text.names
> 
>
> Key: TEXT-31
> URL: https://issues.apache.org/jira/browse/TEXT-31
> Project: Commons Text
>  Issue Type: Task
>Affects Versions: 1.x
>Reporter: Rob Tompkins
>Assignee: Rob Tompkins
>
> We want to remove the package org.apache.commons.text.names for release 1.0.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TEXT-31) Remove org.apache.commons.text.names

[Rob Tompkins (JIRA)]

[ 
https://issues.apache.org/jira/browse/TEXT-31?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15709768#comment-15709768
 ] 

Rob Tompkins commented on TEXT-31:
--

Note TEXT-30 created a branch under the name of the issue that contains the 
code.

> Remove org.apache.commons.text.names
> 
>
> Key: TEXT-31
> URL: https://issues.apache.org/jira/browse/TEXT-31
> Project: Commons Text
>  Issue Type: Task
>Affects Versions: 1.x
>Reporter: Rob Tompkins
>Assignee: Rob Tompkins
>
> We want to remove the package org.apache.commons.text.names for release 1.0.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (TEXT-31) Remove org.apache.commons.text.names

[Rob Tompkins (JIRA)]

Rob Tompkins created TEXT-31:


 Summary: Remove org.apache.commons.text.names
 Key: TEXT-31
 URL: https://issues.apache.org/jira/browse/TEXT-31
 Project: Commons Text
  Issue Type: Task
Affects Versions: 1.x
Reporter: Rob Tompkins
Assignee: Rob Tompkins


We want to remove the package org.apache.commons.text.names for release 1.0.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (TEXT-30) Create a branch for HumanNameParser

[Rob Tompkins (JIRA)]

[ 
https://issues.apache.org/jira/browse/TEXT-30?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15706757#comment-15706757
 ] 

Rob Tompkins edited comment on TEXT-30 at 11/30/16 9:00 PM:


Checked in under branch:
{noformat}
TEXT-30
{noformat} 
Visible here:

https://git-wip-us.apache.org/repos/asf?p=commons-text.git;a=shortlog;h=refs/heads/TEXT-30


was (Author: chtompki):
Checked in under branch "TEXT-30". Visible here:

https://git-wip-us.apache.org/repos/asf?p=commons-text.git;a=shortlog;h=refs/heads/TEXT-30

> Create a branch for HumanNameParser
> ---
>
> Key: TEXT-30
> URL: https://issues.apache.org/jira/browse/TEXT-30
> Project: Commons Text
>  Issue Type: Task
>Reporter: Rob Tompkins
>Assignee: Rob Tompkins
>Priority: Minor
>
> Move HumanNameParser off onto its own branch.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (TEXT-30) Create a branch for HumanNameParser

[Rob Tompkins (JIRA)]

[ 
https://issues.apache.org/jira/browse/TEXT-30?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15706757#comment-15706757
 ] 

Rob Tompkins edited comment on TEXT-30 at 11/30/16 8:58 PM:


Checked in under branch "TEXT-30". Visible here:

https://git-wip-us.apache.org/repos/asf?p=commons-text.git;a=shortlog;h=refs/heads/TEXT-30


was (Author: chtompki):
Checked in under branch "{{TEXT-30}}" . Visible here:

https://git-wip-us.apache.org/repos/asf?p=commons-text.git;a=shortlog;h=refs/heads/TEXT-30

> Create a branch for HumanNameParser
> ---
>
> Key: TEXT-30
> URL: https://issues.apache.org/jira/browse/TEXT-30
> Project: Commons Text
>  Issue Type: Task
>Reporter: Rob Tompkins
>Assignee: Rob Tompkins
>Priority: Minor
>
> Move HumanNameParser off onto its own branch.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (TEXT-30) Create a branch for HumanNameParser

[Rob Tompkins (JIRA)]

[ 
https://issues.apache.org/jira/browse/TEXT-30?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15706757#comment-15706757
 ] 

Rob Tompkins edited comment on TEXT-30 at 11/30/16 8:57 PM:


Checked in under branch "{{TEXT-30}}" . Visible here:

https://git-wip-us.apache.org/repos/asf?p=commons-text.git;a=shortlog;h=refs/heads/TEXT-30


was (Author: chtompki):
Checked in under branch {{TEXT-30}} . Visible here:

https://git-wip-us.apache.org/repos/asf?p=commons-text.git;a=shortlog;h=refs/heads/TEXT-30

> Create a branch for HumanNameParser
> ---
>
> Key: TEXT-30
> URL: https://issues.apache.org/jira/browse/TEXT-30
> Project: Commons Text
>  Issue Type: Task
>Reporter: Rob Tompkins
>Assignee: Rob Tompkins
>Priority: Minor
>
> Move HumanNameParser off onto its own branch.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (TEXT-30) Create a branch for HumanNameParser

[Rob Tompkins (JIRA)]

[ 
https://issues.apache.org/jira/browse/TEXT-30?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15706757#comment-15706757
 ] 

Rob Tompkins edited comment on TEXT-30 at 11/30/16 8:56 PM:


Checked in under branch {{TEXT-30}} . Visible here:

https://git-wip-us.apache.org/repos/asf?p=commons-text.git;a=shortlog;h=refs/heads/TEXT-30


was (Author: chtompki):
Checked in under branch {{TEXT-30}}}. Visible here:

https://git-wip-us.apache.org/repos/asf?p=commons-text.git;a=shortlog;h=refs/heads/TEXT-30

> Create a branch for HumanNameParser
> ---
>
> Key: TEXT-30
> URL: https://issues.apache.org/jira/browse/TEXT-30
> Project: Commons Text
>  Issue Type: Task
>Reporter: Rob Tompkins
>Assignee: Rob Tompkins
>Priority: Minor
>
> Move HumanNameParser off onto its own branch.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (TEXT-30) Create a branch for HumanNameParser

[Rob Tompkins (JIRA)]

[ 
https://issues.apache.org/jira/browse/TEXT-30?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15706757#comment-15706757
 ] 

Rob Tompkins edited comment on TEXT-30 at 11/30/16 8:55 PM:


Checked in under branch {TEXT-30}. Visible here:

https://git-wip-us.apache.org/repos/asf?p=commons-text.git;a=shortlog;h=refs/heads/TEXT-30


was (Author: chtompki):
Checked in under branch TEXT-30. Visible here:

https://git-wip-us.apache.org/repos/asf?p=commons-text.git;a=shortlog;h=refs/heads/TEXT-30

> Create a branch for HumanNameParser
> ---
>
> Key: TEXT-30
> URL: https://issues.apache.org/jira/browse/TEXT-30
> Project: Commons Text
>  Issue Type: Task
>Reporter: Rob Tompkins
>Assignee: Rob Tompkins
>Priority: Minor
>
> Move HumanNameParser off onto its own branch.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (TEXT-30) Create a branch for HumanNameParser

[Rob Tompkins (JIRA)]

[ 
https://issues.apache.org/jira/browse/TEXT-30?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15706757#comment-15706757
 ] 

Rob Tompkins edited comment on TEXT-30 at 11/30/16 8:55 PM:


Checked in under branch {{TEXT-30}}}. Visible here:

https://git-wip-us.apache.org/repos/asf?p=commons-text.git;a=shortlog;h=refs/heads/TEXT-30


was (Author: chtompki):
Checked in under branch {TEXT-30}. Visible here:

https://git-wip-us.apache.org/repos/asf?p=commons-text.git;a=shortlog;h=refs/heads/TEXT-30

> Create a branch for HumanNameParser
> ---
>
> Key: TEXT-30
> URL: https://issues.apache.org/jira/browse/TEXT-30
> Project: Commons Text
>  Issue Type: Task
>Reporter: Rob Tompkins
>Assignee: Rob Tompkins
>Priority: Minor
>
> Move HumanNameParser off onto its own branch.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (CONFIGURATION-644) Header comment duplicated when saving

[Oliver Heger (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CONFIGURATION-644?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Oliver Heger resolved CONFIGURATION-644.

   Resolution: Fixed
Fix Version/s: 2.2

Patch applied in revision 1772115. Many thanks!

If you want to be added to the contributors section of the pom, just post your 
data.

> Header comment duplicated when saving
> -
>
> Key: CONFIGURATION-644
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-644
> Project: Commons Configuration
>  Issue Type: Bug
>  Components: File reloading
>Affects Versions: 2.0, 2.1, 2.2
>Reporter: Andrew DeMaria
>Priority: Minor
> Fix For: 2.2
>
> Attachments: patch
>
>
> If I set the header comment for the properties layout, then load a 
> configuration with a header comment already existing, then save, I end up 
> with duplicate header comments.
> I have a patch to fix this issue, and will attach when JIRA decides to 
> cooperate.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] commons-lang pull request #220: Fix javadoc for isAnyNotEmpty

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/commons-lang/pull/220


---
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, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] commons-lang issue #220: Fix javadoc for isAnyNotEmpty

[PascalSchumacher]

Github user PascalSchumacher commented on the issue:

https://github.com/apache/commons-lang/pull/220
  
Thanks!


---
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, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] commons-lang issue #220: Fix javadoc for isAnyNotEmpty

[coveralls]

Github user coveralls commented on the issue:

https://github.com/apache/commons-lang/pull/220
  

[![Coverage 
Status](https://coveralls.io/builds/9069314/badge)](https://coveralls.io/builds/9069314)

Coverage increased (+0.03%) to 94.301% when pulling 
**014c616aeb119a1bf0184b688f64338f6a24c924 on martin-tarjanyi:patch-1** into 
**2cd3f0f10a797b744509903b8eca4fd2fd4ed6f6 on apache:master**.



---
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, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] commons-lang pull request #220: Fix javadoc for isAnyNotEmpty

[martin-tarjanyi]

GitHub user martin-tarjanyi opened a pull request:

https://github.com/apache/commons-lang/pull/220

Fix javadoc for isAnyNotEmpty



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/martin-tarjanyi/commons-lang patch-1

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/commons-lang/pull/220.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #220


commit 014c616aeb119a1bf0184b688f64338f6a24c924
Author: martin-tarjanyi 
Date:   2016-11-30T19:27:55Z

Fix javadoc for isAnyNotEmpty




---
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, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Updated] (COMPRESS-375) Allow the clients of ParallelScatterZipCreator to provide ZipArchiveEntryRequestSupplier

[Plamen Totev (JIRA)]

 [ 
https://issues.apache.org/jira/browse/COMPRESS-375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Plamen Totev updated COMPRESS-375:
--
Description: 
Currently clients of {{ParallelScatterZipCreator}} could provide 
{{ZipArchiveEntry}} and {{InputStreamSupplier}} through 
{{ParallelScatterZipCreator#addArchiveEntry}}. From those two a 
{{ZipArchiveEntryRequest}} is created. Providing {{InputStreamSupplier}} solves 
the problem with opening too many files - streams are opened just-in-time - 
when an entry is  compressed, not when it's submitted.

But there are use cases when the stream may contain information about the 
{{ZipArchiveEntry}}. In those cases creating {{ZipArchiveEntry}} before the 
{{InputStream}} is opened won't work. If there is an option to supply both 
{{ZipArchiveEntry}} and {{InputStreamSupplier}} ({{ZipArchiveEntryRequest}}), 
this will solve the issue.

There is a bug in Plexus Archiver 
(https://github.com/codehaus-plexus/plexus-archiver/issues/53) that is example 
for such use case. Plexus Archiver have option that allows entries that are 
already zip files to be stored instead of compressed 
({{AbstractZipArchiver.recompressAddedZips}}). To detect if given entry is zip 
archive, {{AbstractZipArchiver}} should read the first several bytes of the 
stream. So creating {{ZipArchiveEntry}} before the stream is opened is not 
useful - the compress mode is not known. Opening the stream when the  
{{ZipArchiveEntry}} is created won't work either. Because you can add entries 
to {{ParallelScatterZipCreator}} a lot faster than you could compress them you 
could open too many files very fast. And I don't think opening and closing the 
stream is an option as such operations could be relatively expensive in the 
general case. But if it could supply both the {{ZipArchiveEntry}} and the 
{{InputStream}} just-in-time (by passing {{ZipArchiveEntryRequestSupplier}} to 
{{ParallelScatterZipCreator}}) then the problem is solved.

What do you think? Does the addition of 
{{ParallelScatterZipCreator#addArchiveEntry(ZipArchiveEntryRequestSupplier)}} 
make sense?

  was:
Currently clients of {{ParallelScatterZipCreator}} could provide 
{{ZipArchiveEntry}} and {{InputStreamSupplier}} through 
{{ParallelScatterZipCreator#addArchiveEntry}}. From those two a 
{{ZipArchiveEntryRequest}} is created. Providing {{InputStreamSupplier}} solves 
the problem with opening too many files - streams are opened just-in-time - 
when an entry is  compressed, not when it's submitted.

But there are use cases when the stream may contain information about the 
{{ZipArchiveEntry}}. In those cases creating {{ZipArchiveEntry}} before the 
{{InputStream}} is opened won't work. If there is an option to supply both 
{{ZipArchiveEntry}} and {{InputStreamSupplier}} ({{ZipArchiveEntryRequest}}), 
this will solve the issue.

There is a bug in Plexus Archiver 
(https://github.com/codehaus-plexus/plexus-archiver/issues/53) that is example 
for such use case. Plexus Archiver have option that allows entries that are 
already zip files to be stored instead of compressed 
({{AbstractZipArchiver.recompressAddedZips}}). To detect if given entry is zip 
archive, {{AbstractZipArchiver}} should read the first several bytes of the 
stream. So creating {{ZipArchiveEntry}} before the stream is opened is not 
useful - the compress mode is not known. Opening the stream when the  
{{ZipArchiveEntry}} is created won't work either. Because you can add entries 
to {{ParallelScatterZipCreator}} a lot faster than you could compress them you 
could open too many files very fast. And I don't think opening and closing the 
stream is an option as such operations could be relatively expensive in the 
general case. But if it could supply both the {{ZipArchiveEntry}} and the 
{{InputStream}} just-in-time (by passing {{ZipArchiveEntryRequestSupplier}} to 
{{ParallelScatterZipCreator}}) then the problem is solved.

What do you think. Does the addition of 
{{ParallelScatterZipCreator#addArchiveEntry(ZipArchiveEntryRequestSupplier)}} 
make sense?


> Allow the clients of ParallelScatterZipCreator to provide 
> ZipArchiveEntryRequestSupplier
> 
>
> Key: COMPRESS-375
> URL: https://issues.apache.org/jira/browse/COMPRESS-375
> Project: Commons Compress
>  Issue Type: Improvement
>  Components: Archivers
>Reporter: Plamen Totev
>
> Currently clients of {{ParallelScatterZipCreator}} could provide 
> {{ZipArchiveEntry}} and {{InputStreamSupplier}} through 
> {{ParallelScatterZipCreator#addArchiveEntry}}. From those two a 
> {{ZipArchiveEntryRequest}} is created. Providing {{InputStreamSupplier}} 
> solves the problem with opening too many files - streams are opened 
> just-in-time - when an entry is  compressed, not when it's submitted.
> But there 

[jira] [Updated] (COMPRESS-375) Allow the clients of ParallelScatterZipCreator to provide ZipArchiveEntryRequestSupplier

[Plamen Totev (JIRA)]

 [ 
https://issues.apache.org/jira/browse/COMPRESS-375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Plamen Totev updated COMPRESS-375:
--
Description: 
Currently clients of {{ParallelScatterZipCreator}} could provide 
{{ZipArchiveEntry}} and {{InputStreamSupplier}} through 
{{ParallelScatterZipCreator#addArchiveEntry}}. From those two a 
{{ZipArchiveEntryRequest}} is created. Providing {{InputStreamSupplier}} solves 
the problem with opening too many files - streams are opened just-in-time - 
when an entry is  compressed, not when it's submitted.

But there are use cases when the stream may contain information about the 
{{ZipArchiveEntry}}. In those cases creating {{ZipArchiveEntry}} before the 
{{InputStream}} is opened won't work. If there is an option to supply both 
{{ZipArchiveEntry}} and {{InputStreamSupplier}} ({{ZipArchiveEntryRequest}}), 
this will solve the issue.

There is a bug in Plexus Archiver 
(https://github.com/codehaus-plexus/plexus-archiver/issues/53) that is example 
for such use case. Plexus Archiver have option that allows entries that are 
already zip files to be stored instead of compressed 
({{AbstractZipArchiver.recompressAddedZips}}). To detect if given entry is zip 
archive, {{AbstractZipArchiver}} should read the first several bytes of the 
stream. So creating {{ZipArchiveEntry}} before the stream is opened is not 
useful - the compress mode is not known. Opening the stream when the  
{{ZipArchiveEntry}} is created won't work either. Because you can add entries 
to {{ParallelScatterZipCreator}} a lot faster than you could compress them you 
could open too many files very fast. And I don't think opening and closing the 
stream is an option as such operations could be relatively expensive in the 
general case. But if it could supply both the {{ZipArchiveEntry}} and the 
{{InputStream}} just-in-time (by passing {{ZipArchiveEntryRequestSupplier}} to 
{{ParallelScatterZipCreator}}) then the problem is solved.

What do you think? Does the addition of 
{{ParallelScatterZipCreator#addArchiveEntry(ZipArchiveEntryRequestSupplier)}} 
makes sense?

  was:
Currently clients of {{ParallelScatterZipCreator}} could provide 
{{ZipArchiveEntry}} and {{InputStreamSupplier}} through 
{{ParallelScatterZipCreator#addArchiveEntry}}. From those two a 
{{ZipArchiveEntryRequest}} is created. Providing {{InputStreamSupplier}} solves 
the problem with opening too many files - streams are opened just-in-time - 
when an entry is  compressed, not when it's submitted.

But there are use cases when the stream may contain information about the 
{{ZipArchiveEntry}}. In those cases creating {{ZipArchiveEntry}} before the 
{{InputStream}} is opened won't work. If there is an option to supply both 
{{ZipArchiveEntry}} and {{InputStreamSupplier}} ({{ZipArchiveEntryRequest}}), 
this will solve the issue.

There is a bug in Plexus Archiver 
(https://github.com/codehaus-plexus/plexus-archiver/issues/53) that is example 
for such use case. Plexus Archiver have option that allows entries that are 
already zip files to be stored instead of compressed 
({{AbstractZipArchiver.recompressAddedZips}}). To detect if given entry is zip 
archive, {{AbstractZipArchiver}} should read the first several bytes of the 
stream. So creating {{ZipArchiveEntry}} before the stream is opened is not 
useful - the compress mode is not known. Opening the stream when the  
{{ZipArchiveEntry}} is created won't work either. Because you can add entries 
to {{ParallelScatterZipCreator}} a lot faster than you could compress them you 
could open too many files very fast. And I don't think opening and closing the 
stream is an option as such operations could be relatively expensive in the 
general case. But if it could supply both the {{ZipArchiveEntry}} and the 
{{InputStream}} just-in-time (by passing {{ZipArchiveEntryRequestSupplier}} to 
{{ParallelScatterZipCreator}}) then the problem is solved.

What do you think? Does the addition of 
{{ParallelScatterZipCreator#addArchiveEntry(ZipArchiveEntryRequestSupplier)}} 
make sense?


> Allow the clients of ParallelScatterZipCreator to provide 
> ZipArchiveEntryRequestSupplier
> 
>
> Key: COMPRESS-375
> URL: https://issues.apache.org/jira/browse/COMPRESS-375
> Project: Commons Compress
>  Issue Type: Improvement
>  Components: Archivers
>Reporter: Plamen Totev
>
> Currently clients of {{ParallelScatterZipCreator}} could provide 
> {{ZipArchiveEntry}} and {{InputStreamSupplier}} through 
> {{ParallelScatterZipCreator#addArchiveEntry}}. From those two a 
> {{ZipArchiveEntryRequest}} is created. Providing {{InputStreamSupplier}} 
> solves the problem with opening too many files - streams are opened 
> just-in-time - when an entry is  compressed, not when it's submitted.
> But there 

[jira] [Created] (COMPRESS-375) Allow the clients of ParallelScatterZipCreator to provide ZipArchiveEntryRequestSupplier

[Plamen Totev (JIRA)]

Plamen Totev created COMPRESS-375:
-

 Summary: Allow the clients of ParallelScatterZipCreator to provide 
ZipArchiveEntryRequestSupplier
 Key: COMPRESS-375
 URL: https://issues.apache.org/jira/browse/COMPRESS-375
 Project: Commons Compress
  Issue Type: Improvement
  Components: Archivers
Reporter: Plamen Totev


Currently clients of {{ParallelScatterZipCreator}} could provide 
{{ZipArchiveEntry}} and {{InputStreamSupplier}} through 
{{ParallelScatterZipCreator#addArchiveEntry}}. From those two a 
{{ZipArchiveEntryRequest}} is created. Providing {{InputStreamSupplier}} solves 
the problem with opening too many files - streams are opened just-in-time - 
when an entry is  compressed, not when it's submitted.

But there are use cases when the stream may contain information about the 
{{ZipArchiveEntry}}. In those cases creating {{ZipArchiveEntry}} before the 
{{InputStream}} is opened won't work. If there is an option to supply both 
{{ZipArchiveEntry}} and {{InputStreamSupplier}} ({{ZipArchiveEntryRequest}}), 
this will solve the issue.

There is a bug in Plexus Archiver 
(https://github.com/codehaus-plexus/plexus-archiver/issues/53) that is example 
for such use case. Plexus Archiver have option that allows entries that are 
already zip files to be stored instead of compressed 
({{AbstractZipArchiver.recompressAddedZips}}). To detect if given entry is zip 
archive, {{AbstractZipArchiver}} should read the first several bytes of the 
stream. So creating {{ZipArchiveEntry}} before the stream is opened is not 
useful - the compress mode is not known. Opening the stream when the  
{{ZipArchiveEntry}} is created won't work either. Because you can add entries 
to {{ParallelScatterZipCreator}} a lot faster than you could compress them you 
could open too many files very fast. And I don't think opening and closing the 
stream is an option as such operations could be relatively expensive in the 
general case. But if it could supply both the {{ZipArchiveEntry}} and the 
{{InputStream}} just-in-time (by passing {{ZipArchiveEntryRequestSupplier}} to 
{{ParallelScatterZipCreator}}) then the problem is solved.

What do you think. Does the addition of 
{{ParallelScatterZipCreator#addArchiveEntry(ZipArchiveEntryRequestSupplier)}} 
make sense?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)