[jira] [Resolved] (CLI-336) Deprecation use not always reported.
[
https://issues.apache.org/jira/browse/CLI-336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claude Warren resolved CLI-336.
---
Fix Version/s: Nightly Builds
Resolution: Fixed
> Deprecation use not always reported.
>
>
> Key: CLI-336
> URL: https://issues.apache.org/jira/browse/CLI-336
> Project: Commons CLI
> Issue Type: Improvement
> Components: CLI-1.x
>Affects Versions: 1.8.0
>Reporter: Claude Warren
>Assignee: Claude Warren
>Priority: Minor
> Fix For: Nightly Builds
>
>
> I have a case where I have multiple no-argument options in an OptionGroup.
> The group comprises a deprecated option and a current option. Basically an
> option rename.
> When I check for the option I simply check if (OptionGroup.getSelected() !=
> null). However if the deprecated value is selected this does not print the
> log message that says a deprecated value was selected. The only way I could
> find to do this was to do
> if (OptionGroup.getSelected() != null) {
> commandLine.hasOption(OptionGroup.getSelected());
> ... other processing
> }
> I don't think there is a way to log the issue when the option is selected.
> There are 2 requested changes here:
> # Document the issue in the javadoc for OptionGroup.getSelected() and
> OptionGroup.isSelected() methods.
> # Add a commandLine.hasOption(OptionGroup) method that basically performs the
> OptionGorup equivalent of the commandLine.hasOption(Option) call as well as
> the similar getOptionValue(), getOptionValues(), getParsedOption(), and
> getParsedOptionValues() methods.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CLI-336) Deprecation use not always reported.
[
https://issues.apache.org/jira/browse/CLI-336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17859702#comment-17859702
]
Claude Warren commented on CLI-336:
---
Added to CommandLine to accept OptionGroup for
* hasOption()
* getOptionValue()
* getOptionValues()
* getParsedOptionValue()
> Deprecation use not always reported.
>
>
> Key: CLI-336
> URL: https://issues.apache.org/jira/browse/CLI-336
> Project: Commons CLI
> Issue Type: Improvement
> Components: CLI-1.x
>Affects Versions: 1.8.0
>Reporter: Claude Warren
>Assignee: Claude Warren
>Priority: Minor
>
> I have a case where I have multiple no-argument options in an OptionGroup.
> The group comprises a deprecated option and a current option. Basically an
> option rename.
> When I check for the option I simply check if (OptionGroup.getSelected() !=
> null). However if the deprecated value is selected this does not print the
> log message that says a deprecated value was selected. The only way I could
> find to do this was to do
> if (OptionGroup.getSelected() != null) {
> commandLine.hasOption(OptionGroup.getSelected());
> ... other processing
> }
> I don't think there is a way to log the issue when the option is selected.
> There are 2 requested changes here:
> # Document the issue in the javadoc for OptionGroup.getSelected() and
> OptionGroup.isSelected() methods.
> # Add a commandLine.hasOption(OptionGroup) method that basically performs the
> OptionGorup equivalent of the commandLine.hasOption(Option) call as well as
> the similar getOptionValue(), getOptionValues(), getParsedOption(), and
> getParsedOptionValues() methods.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (COLLECTIONS-857) Update documentation to match bloomfilter implementation.
[ https://issues.apache.org/jira/browse/COLLECTIONS-857?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17859661#comment-17859661 ] Claude Warren commented on COLLECTIONS-857: --- Made corrections in pull request #508 > Update documentation to match bloomfilter implementation. > - > > Key: COLLECTIONS-857 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-857 > Project: Commons Collections > Issue Type: Bug > Components: Bloomfilter >Affects Versions: 4.5.0-M2 >Reporter: Claude Warren >Assignee: Claude Warren >Priority: Major > Fix For: 4.5.0-M3 > > > Documentation for Bloom filter implementation references old class names and > methods. Documentation should be updated to reflect changes and new > implementations (e.g. layered Bloom filter) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (COLLECTIONS-857) Update documentation to match bloomfilter implementation.
[ https://issues.apache.org/jira/browse/COLLECTIONS-857?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17859467#comment-17859467 ] Claude Warren commented on COLLECTIONS-857: --- Pull [507|https://github.com/apache/commons-collections/pull/507] is a fix > Update documentation to match bloomfilter implementation. > - > > Key: COLLECTIONS-857 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-857 > Project: Commons Collections > Issue Type: Bug > Components: Bloomfilter >Affects Versions: 4.5.0-M2 >Reporter: Claude Warren >Assignee: Claude Warren >Priority: Major > > Documentation for Bloom filter implementation references old class names and > methods. Documentation should be updated to reflect changes and new > implementations (e.g. layered Bloom filter) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (COLLECTIONS-857) Update documentation to match bloomfilter implementation.
[ https://issues.apache.org/jira/browse/COLLECTIONS-857?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claude Warren updated COLLECTIONS-857: -- Assignee: Claude Warren > Update documentation to match bloomfilter implementation. > - > > Key: COLLECTIONS-857 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-857 > Project: Commons Collections > Issue Type: Bug > Components: Bloomfilter >Affects Versions: 4.5.0-M2 >Reporter: Claude Warren >Assignee: Claude Warren >Priority: Major > > Documentation for Bloom filter implementation references old class names and > methods. Documentation should be updated to reflect changes and new > implementations (e.g. layered Bloom filter) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (COLLECTIONS-857) Update documentation to match bloomfilter implementation.
Claude Warren created COLLECTIONS-857: - Summary: Update documentation to match bloomfilter implementation. Key: COLLECTIONS-857 URL: https://issues.apache.org/jira/browse/COLLECTIONS-857 Project: Commons Collections Issue Type: Bug Components: Bloomfilter Affects Versions: 4.5.0-M2 Reporter: Claude Warren Documentation for Bloom filter implementation references old class names and methods. Documentation should be updated to reflect changes and new implementations (e.g. layered Bloom filter) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CLI-335) Defining Default Properties documentation has errors.
[ https://issues.apache.org/jira/browse/CLI-335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claude Warren updated CLI-335: -- Assignee: Claude Warren > Defining Default Properties documentation has errors. > - > > Key: CLI-335 > URL: https://issues.apache.org/jira/browse/CLI-335 > Project: Commons CLI > Issue Type: Bug > Components: Documentation >Affects Versions: 1.8.0 >Reporter: Claude Warren >Assignee: Claude Warren >Priority: Major > > https://commons.apache.org/proper/commons-cli/properties.html specifically > links to the deprecated OptionBuilder class. It should reference the > Option.Builder (note the dot) class. > In addition there are methods defined in Option.Builder that are not > described in the properties document. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CLI-336) Deprecation use not always reported.
Claude Warren created CLI-336:
-
Summary: Deprecation use not always reported.
Key: CLI-336
URL: https://issues.apache.org/jira/browse/CLI-336
Project: Commons CLI
Issue Type: Improvement
Components: CLI-1.x
Affects Versions: 1.8.0
Reporter: Claude Warren
I have a case where I have multiple no-argument options in an OptionGroup. The
group comprises a deprecated option and a current option. Basically an option
rename.
When I check for the option I simply check if (OptionGroup.getSelected() !=
null). However if the deprecated value is selected this does not print the log
message that says a deprecated value was selected. The only way I could find
to do this was to do
if (OptionGroup.getSelected() != null) {
commandLine.hasOption(OptionGroup.getSelected());
... other processing
}
I don't think there is a way to log the issue when the option is selected.
There are 2 requested changes here:
# Document the issue in the javadoc for OptionGroup.getSelected() and
OptionGroup.isSelected() methods.
# Add a commandLine.hasOption(OptionGroup) method that basically performs the
OptionGorup equivalent of the commandLine.hasOption(Option) call as well as the
similar getOptionValue(), getOptionValues(), getParsedOption(), and
getParsedOptionValues() methods.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CLI-336) Deprecation use not always reported.
[
https://issues.apache.org/jira/browse/CLI-336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claude Warren updated CLI-336:
--
Assignee: Claude Warren
> Deprecation use not always reported.
>
>
> Key: CLI-336
> URL: https://issues.apache.org/jira/browse/CLI-336
> Project: Commons CLI
> Issue Type: Improvement
> Components: CLI-1.x
>Affects Versions: 1.8.0
>Reporter: Claude Warren
>Assignee: Claude Warren
>Priority: Minor
>
> I have a case where I have multiple no-argument options in an OptionGroup.
> The group comprises a deprecated option and a current option. Basically an
> option rename.
> When I check for the option I simply check if (OptionGroup.getSelected() !=
> null). However if the deprecated value is selected this does not print the
> log message that says a deprecated value was selected. The only way I could
> find to do this was to do
> if (OptionGroup.getSelected() != null) {
> commandLine.hasOption(OptionGroup.getSelected());
> ... other processing
> }
> I don't think there is a way to log the issue when the option is selected.
> There are 2 requested changes here:
> # Document the issue in the javadoc for OptionGroup.getSelected() and
> OptionGroup.isSelected() methods.
> # Add a commandLine.hasOption(OptionGroup) method that basically performs the
> OptionGorup equivalent of the commandLine.hasOption(Option) call as well as
> the similar getOptionValue(), getOptionValues(), getParsedOption(), and
> getParsedOptionValues() methods.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (COLLECTIONS-855) Update the EnhancedDoubleHasher to correct the cube component of the hash
[
https://issues.apache.org/jira/browse/COLLECTIONS-855?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claude Warren updated COLLECTIONS-855:
--
Description:
The EnhancedDoubleHasher currently computes the hash with the cube component
lagging by 1:
{noformat}
hash[i] = ( h1(x) - i*h2(x) - ((i-1)^3 - (i-1))/6 ) wrapped in [0,
bits){noformat}
Correct this to the intended:
{noformat}
hash[i] = ( h1(x) - i*h2(x) - (i*i*i - i)/6 ) wrapped in [0, bits){noformat}
This is a simple change in the current controlling loop from:
{code:java}
for (int i = 0; i < k; i++) { {code}
to:
{code:java}
for (int i = 1; i <= k; i++) { {code}
Issue notified by Juan Manuel Gimeno Illa on the Commons dev mailing list (see
[https://lists.apache.org/thread/wjmwxzozrtf41ko9r0g7pzrrg11o923o]).
Pull request: https://github.com/apache/commons-collections/pull/501
was:
The EnhancedDoubleHasher currently computes the hash with the cube component
lagging by 1:
{noformat}
hash[i] = ( h1(x) - i*h2(x) - ((i-1)^3 - (i-1))/6 ) wrapped in [0,
bits){noformat}
Correct this to the intended:
{noformat}
hash[i] = ( h1(x) - i*h2(x) - (i*i*i - i)/6 ) wrapped in [0, bits){noformat}
This is a simple change in the current controlling loop from:
{code:java}
for (int i = 0; i < k; i++) { {code}
to:
{code:java}
for (int i = 1; i <= k; i++) { {code}
Issue notified by Juan Manuel Gimeno Illa on the Commons dev mailing list (see
[https://lists.apache.org/thread/wjmwxzozrtf41ko9r0g7pzrrg11o923o]).
> Update the EnhancedDoubleHasher to correct the cube component of the hash
> -
>
> Key: COLLECTIONS-855
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-855
> Project: Commons Collections
> Issue Type: Bug
> Components: Bloomfilter
>Affects Versions: 4.5.0-M1
>Reporter: Alex Herbert
>Assignee: Claude Warren
>Priority: Blocker
>
> The EnhancedDoubleHasher currently computes the hash with the cube component
> lagging by 1:
> {noformat}
> hash[i] = ( h1(x) - i*h2(x) - ((i-1)^3 - (i-1))/6 ) wrapped in [0,
> bits){noformat}
> Correct this to the intended:
> {noformat}
> hash[i] = ( h1(x) - i*h2(x) - (i*i*i - i)/6 ) wrapped in [0, bits){noformat}
> This is a simple change in the current controlling loop from:
> {code:java}
> for (int i = 0; i < k; i++) { {code}
> to:
> {code:java}
> for (int i = 1; i <= k; i++) { {code}
>
> Issue notified by Juan Manuel Gimeno Illa on the Commons dev mailing list
> (see [https://lists.apache.org/thread/wjmwxzozrtf41ko9r0g7pzrrg11o923o]).
> Pull request: https://github.com/apache/commons-collections/pull/501
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (COLLECTIONS-855) Update the EnhancedDoubleHasher to correct the cube component of the hash
[
https://issues.apache.org/jira/browse/COLLECTIONS-855?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claude Warren updated COLLECTIONS-855:
--
Assignee: Claude Warren
> Update the EnhancedDoubleHasher to correct the cube component of the hash
> -
>
> Key: COLLECTIONS-855
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-855
> Project: Commons Collections
> Issue Type: Bug
> Components: Bloomfilter
>Affects Versions: 4.5.0-M1
>Reporter: Alex Herbert
>Assignee: Claude Warren
>Priority: Blocker
>
> The EnhancedDoubleHasher currently computes the hash with the cube component
> lagging by 1:
> {noformat}
> hash[i] = ( h1(x) - i*h2(x) - ((i-1)^3 - (i-1))/6 ) wrapped in [0,
> bits){noformat}
> Correct this to the intended:
> {noformat}
> hash[i] = ( h1(x) - i*h2(x) - (i*i*i - i)/6 ) wrapped in [0, bits){noformat}
> This is a simple change in the current controlling loop from:
> {code:java}
> for (int i = 0; i < k; i++) { {code}
> to:
> {code:java}
> for (int i = 1; i <= k; i++) { {code}
>
> Issue notified by Juan Manuel Gimeno Illa on the Commons dev mailing list
> (see [https://lists.apache.org/thread/wjmwxzozrtf41ko9r0g7pzrrg11o923o]).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CLI-335) Defining Default Properties documentation has errors.
[ https://issues.apache.org/jira/browse/CLI-335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17851169#comment-17851169 ] Claude Warren commented on CLI-335: --- I plan on doing so in the next few weeks. I am tied up next week with community over code and then I'll need to spend some time at my $ job to catch up there. If someone else does not catch this before the end of the month I should be able to submit a pull by then. > Defining Default Properties documentation has errors. > - > > Key: CLI-335 > URL: https://issues.apache.org/jira/browse/CLI-335 > Project: Commons CLI > Issue Type: Bug > Components: Documentation >Affects Versions: 1.8.0 >Reporter: Claude Warren >Priority: Major > > https://commons.apache.org/proper/commons-cli/properties.html specifically > links to the deprecated OptionBuilder class. It should reference the > Option.Builder (note the dot) class. > In addition there are methods defined in Option.Builder that are not > described in the properties document. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (COLLECTIONS-855) Update the EnhancedDoubleHasher to correct the cube component of the hash
[
https://issues.apache.org/jira/browse/COLLECTIONS-855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17850493#comment-17850493
]
Claude Warren commented on COLLECTIONS-855:
---
I agree. I was just pointing out that it sorta falls into that space where
we have to think about if the change would break something in the wild. Do
we have a marker for such things? An annotation of something like that to
inform other developers going forward?
On Wed, May 29, 2024 at 10:13 PM Gary D. Gregory (Jira)
> Update the EnhancedDoubleHasher to correct the cube component of the hash
> -
>
> Key: COLLECTIONS-855
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-855
> Project: Commons Collections
> Issue Type: Bug
> Components: Bloomfilter
>Affects Versions: 4.5.0-M1
>Reporter: Alex Herbert
>Priority: Blocker
>
> The EnhancedDoubleHasher currently computes the hash with the cube component
> lagging by 1:
> {noformat}
> hash[i] = ( h1(x) - i*h2(x) - ((i-1)^3 - (i-1))/6 ) wrapped in [0,
> bits){noformat}
> Correct this to the intended:
> {noformat}
> hash[i] = ( h1(x) - i*h2(x) - (i*i*i - i)/6 ) wrapped in [0, bits){noformat}
> This is a simple change in the current controlling loop from:
> {code:java}
> for (int i = 0; i < k; i++) { {code}
> to:
> {code:java}
> for (int i = 1; i <= k; i++) { {code}
>
> Issue notified by Juan Manuel Gimeno Illa on the Commons dev mailing list
> (see [https://lists.apache.org/thread/wjmwxzozrtf41ko9r0g7pzrrg11o923o]).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (COLLECTIONS-855) Update the EnhancedDoubleHasher to correct the cube component of the hash
[
https://issues.apache.org/jira/browse/COLLECTIONS-855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17850427#comment-17850427
]
Claude Warren commented on COLLECTIONS-855:
---
Users are expected to rely on the output. They are expected to use it to
calculate hashes for the filters. So any stored filters will not match if
there is a change. If this code had been released this change would be
like the breaking change in the murmur3 hash in commons codec awhile back.
> Update the EnhancedDoubleHasher to correct the cube component of the hash
> -
>
> Key: COLLECTIONS-855
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-855
> Project: Commons Collections
> Issue Type: Bug
> Components: Bloomfilter
>Affects Versions: 4.5.0-M1
>Reporter: Alex Herbert
>Priority: Blocker
>
> The EnhancedDoubleHasher currently computes the hash with the cube component
> lagging by 1:
> {noformat}
> hash[i] = ( h1(x) - i*h2(x) - ((i-1)^3 - (i-1))/6 ) wrapped in [0,
> bits){noformat}
> Correct this to the intended:
> {noformat}
> hash[i] = ( h1(x) - i*h2(x) - (i*i*i - i)/6 ) wrapped in [0, bits){noformat}
> This is a simple change in the current controlling loop from:
> {code:java}
> for (int i = 0; i < k; i++) { {code}
> to:
> {code:java}
> for (int i = 1; i <= k; i++) { {code}
>
> Issue notified by Juan Manuel Gimeno Illa on the Commons dev mailing list
> (see [https://lists.apache.org/thread/wjmwxzozrtf41ko9r0g7pzrrg11o923o]).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (COLLECTIONS-855) Update the EnhancedDoubleHasher to correct the cube component of the hash
[
https://issues.apache.org/jira/browse/COLLECTIONS-855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17850343#comment-17850343
]
Claude Warren commented on COLLECTIONS-855:
---
With c/c Eu next week i am a bit slammed but I wanted to make sure this was
on the radar before we cut the next candidate.
If it is not resolved by the end of next week i will take a look at it
Claude
> Update the EnhancedDoubleHasher to correct the cube component of the hash
> -
>
> Key: COLLECTIONS-855
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-855
> Project: Commons Collections
> Issue Type: Bug
> Components: Bloomfilter
>Affects Versions: 4.5.0-M1
>Reporter: Alex Herbert
>Priority: Blocker
>
> The EnhancedDoubleHasher currently computes the hash with the cube component
> lagging by 1:
> {noformat}
> hash[i] = ( h1(x) - i*h2(x) - ((i-1)^3 - (i-1))/6 ) wrapped in [0,
> bits){noformat}
> Correct this to the intended:
> {noformat}
> hash[i] = ( h1(x) - i*h2(x) - (i*i*i - i)/6 ) wrapped in [0, bits){noformat}
> This is a simple change in the current controlling loop from:
> {code:java}
> for (int i = 0; i < k; i++) { {code}
> to:
> {code:java}
> for (int i = 1; i <= k; i++) { {code}
>
> Issue notified by Juan Manuel Gimeno Illa on the Commons dev mailing list
> (see [https://lists.apache.org/thread/wjmwxzozrtf41ko9r0g7pzrrg11o923o]).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (COLLECTIONS-855) Update the EnhancedDoubleHasher to correct the cube component of the hash
[
https://issues.apache.org/jira/browse/COLLECTIONS-855?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claude Warren updated COLLECTIONS-855:
--
Component/s: Bloomfilter
> Update the EnhancedDoubleHasher to correct the cube component of the hash
> -
>
> Key: COLLECTIONS-855
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-855
> Project: Commons Collections
> Issue Type: Bug
> Components: Bloomfilter
>Affects Versions: 4.5.0-M1
>Reporter: Alex Herbert
>Priority: Blocker
>
> The EnhancedDoubleHasher currently computes the hash with the cube component
> lagging by 1:
> {noformat}
> hash[i] = ( h1(x) - i*h2(x) - ((i-1)^3 - (i-1))/6 ) wrapped in [0,
> bits){noformat}
> Correct this to the intended:
> {noformat}
> hash[i] = ( h1(x) - i*h2(x) - (i*i*i - i)/6 ) wrapped in [0, bits){noformat}
> This is a simple change in the current controlling loop from:
> {code:java}
> for (int i = 0; i < k; i++) { {code}
> to:
> {code:java}
> for (int i = 1; i <= k; i++) { {code}
>
> Issue notified by Juan Manuel Gimeno Illa on the Commons dev mailing list
> (see [https://lists.apache.org/thread/wjmwxzozrtf41ko9r0g7pzrrg11o923o]).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (COLLECTIONS-855) Update the EnhancedDoubleHasher to correct the cube component of the hash
[
https://issues.apache.org/jira/browse/COLLECTIONS-855?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claude Warren updated COLLECTIONS-855:
--
Priority: Blocker (was: Trivial)
This is a breaking API change and should be fixed before 4.5.0-M2 or release.
The effect is that the values generated from the 4.5.0-M1 EnhancedDoubleHasher
will not be the same as values generated after this fix.
> Update the EnhancedDoubleHasher to correct the cube component of the hash
> -
>
> Key: COLLECTIONS-855
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-855
> Project: Commons Collections
> Issue Type: Bug
>Affects Versions: 4.5.0-M1
>Reporter: Alex Herbert
>Priority: Blocker
>
> The EnhancedDoubleHasher currently computes the hash with the cube component
> lagging by 1:
> {noformat}
> hash[i] = ( h1(x) - i*h2(x) - ((i-1)^3 - (i-1))/6 ) wrapped in [0,
> bits){noformat}
> Correct this to the intended:
> {noformat}
> hash[i] = ( h1(x) - i*h2(x) - (i*i*i - i)/6 ) wrapped in [0, bits){noformat}
> This is a simple change in the current controlling loop from:
> {code:java}
> for (int i = 0; i < k; i++) { {code}
> to:
> {code:java}
> for (int i = 1; i <= k; i++) { {code}
>
> Issue notified by Juan Manuel Gimeno Illa on the Commons dev mailing list
> (see [https://lists.apache.org/thread/wjmwxzozrtf41ko9r0g7pzrrg11o923o]).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CLI-335) Defining Default Properties documentation has errors.
Claude Warren created CLI-335: - Summary: Defining Default Properties documentation has errors. Key: CLI-335 URL: https://issues.apache.org/jira/browse/CLI-335 Project: Commons CLI Issue Type: Bug Components: Documentation Affects Versions: 1.8.0 Reporter: Claude Warren https://commons.apache.org/proper/commons-cli/properties.html specifically links to the deprecated OptionBuilder class. It should reference the Option.Builder (note the dot) class. In addition there are methods defined in Option.Builder that are not described in the properties document. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (TEXT-217) Snake case utility method: CaseUtils.toSnakeCase(....)
[ https://issues.apache.org/jira/browse/TEXT-217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claude Warren updated TEXT-217: --- Fix Version/s: 1.12.1 (was: 1.9) > Snake case utility method: CaseUtils.toSnakeCase() > -- > > Key: TEXT-217 > URL: https://issues.apache.org/jira/browse/TEXT-217 > Project: Commons Text > Issue Type: New Feature >Affects Versions: 1.9 >Reporter: Adil Iqbal >Assignee: Claude Warren >Priority: Major > Fix For: 1.12.1 > > Time Spent: 1h > Remaining Estimate: 0h > > Requesting a feature to convert any string to snake case, as per > CaseUtils.toCamelCase(...) > *Rationale:* > As per the OpenAPI Specification 3.0, keys should be in snake case. There is > currently no common utility that can be used to accomplish that task. > Any interaction between Java and Python is hindered, since Python uses snake > case as a best practice. > *Feature Set Requested:* > All features currently included in CaseUtils.toCamelCase(...) sans > capitalization flag. As you know, the capitalization flag was implemented to > support PascalCase, which is a convention even in Java, for many situations. > There is no equivalent for snake case. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (TEXT-217) Snake case utility method: CaseUtils.toSnakeCase(....)
[ https://issues.apache.org/jira/browse/TEXT-217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17849450#comment-17849450 ] Claude Warren commented on TEXT-217: pull request #552 solves the problem by creating a generic converter that should be able to handle any conversion that can be done with look ahead parsing. > Snake case utility method: CaseUtils.toSnakeCase() > -- > > Key: TEXT-217 > URL: https://issues.apache.org/jira/browse/TEXT-217 > Project: Commons Text > Issue Type: New Feature >Affects Versions: 1.9 >Reporter: Adil Iqbal >Assignee: Claude Warren >Priority: Major > Fix For: 1.9 > > Time Spent: 1h > Remaining Estimate: 0h > > Requesting a feature to convert any string to snake case, as per > CaseUtils.toCamelCase(...) > *Rationale:* > As per the OpenAPI Specification 3.0, keys should be in snake case. There is > currently no common utility that can be used to accomplish that task. > Any interaction between Java and Python is hindered, since Python uses snake > case as a best practice. > *Feature Set Requested:* > All features currently included in CaseUtils.toCamelCase(...) sans > capitalization flag. As you know, the capitalization flag was implemented to > support PascalCase, which is a convention even in Java, for many situations. > There is no equivalent for snake case. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (TEXT-217) Snake case utility method: CaseUtils.toSnakeCase(....)
[ https://issues.apache.org/jira/browse/TEXT-217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claude Warren updated TEXT-217: --- Assignee: Claude Warren > Snake case utility method: CaseUtils.toSnakeCase() > -- > > Key: TEXT-217 > URL: https://issues.apache.org/jira/browse/TEXT-217 > Project: Commons Text > Issue Type: New Feature >Affects Versions: 1.9 >Reporter: Adil Iqbal >Assignee: Claude Warren >Priority: Major > Fix For: 1.9 > > Time Spent: 1h > Remaining Estimate: 0h > > Requesting a feature to convert any string to snake case, as per > CaseUtils.toCamelCase(...) > *Rationale:* > As per the OpenAPI Specification 3.0, keys should be in snake case. There is > currently no common utility that can be used to accomplish that task. > Any interaction between Java and Python is hindered, since Python uses snake > case as a best practice. > *Feature Set Requested:* > All features currently included in CaseUtils.toCamelCase(...) sans > capitalization flag. As you know, the capitalization flag was implemented to > support PascalCase, which is a convention even in Java, for many situations. > There is no equivalent for snake case. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CLI-321) Add and use a Converter interface and implementations without using BeanUtils
[ https://issues.apache.org/jira/browse/CLI-321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claude Warren updated CLI-321: -- Description: The current TypeHandler implementation notes indicate that the BeanUtils.Converters should be used to create instances of the various types. This issue is to complete the implementation of TypeHandler so that it does NOT use the BeanUtils.Converters. (was: The current TypeHandler implementation notes indicate that the BeanUtils.Converters should be used to create instances of the various types. This issue is to complete the implementation of TypeHandler so that it uses the BeanUtils.Converters.) > Add and use a Converter interface and implementations without using BeanUtils > -- > > Key: CLI-321 > URL: https://issues.apache.org/jira/browse/CLI-321 > Project: Commons CLI > Issue Type: Improvement > Components: Parser >Affects Versions: 1.6.0 >Reporter: Claude Warren >Assignee: Claude Warren >Priority: Minor > Fix For: 1.7.0 > > > The current TypeHandler implementation notes indicate that the > BeanUtils.Converters should be used to create instances of the various types. > This issue is to complete the implementation of TypeHandler so that it does > NOT use the BeanUtils.Converters. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CLI-321) Add and use a Converter interface and implementations without using BeanUtils
[ https://issues.apache.org/jira/browse/CLI-321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claude Warren resolved CLI-321. --- Fix Version/s: 1.7.0 (was: 1.8.1) Resolution: Fixed Fixed with pull request #216 > Add and use a Converter interface and implementations without using BeanUtils > -- > > Key: CLI-321 > URL: https://issues.apache.org/jira/browse/CLI-321 > Project: Commons CLI > Issue Type: Improvement > Components: Parser >Affects Versions: 1.6.0 >Reporter: Claude Warren >Assignee: Claude Warren >Priority: Minor > Fix For: 1.7.0 > > > The current TypeHandler implementation notes indicate that the > BeanUtils.Converters should be used to create instances of the various types. > This issue is to complete the implementation of TypeHandler so that it uses > the BeanUtils.Converters. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CLI-321) Add and use a Converter interface and implementations without using BeanUtils
[ https://issues.apache.org/jira/browse/CLI-321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17849190#comment-17849190 ] Claude Warren commented on CLI-321: --- This should have been closed in 1.7 > Add and use a Converter interface and implementations without using BeanUtils > -- > > Key: CLI-321 > URL: https://issues.apache.org/jira/browse/CLI-321 > Project: Commons CLI > Issue Type: Improvement > Components: Parser >Affects Versions: 1.6.0 >Reporter: Claude Warren >Assignee: Claude Warren >Priority: Minor > Fix For: 1.8.1 > > > The current TypeHandler implementation notes indicate that the > BeanUtils.Converters should be used to create instances of the various types. > This issue is to complete the implementation of TypeHandler so that it uses > the BeanUtils.Converters. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CLI-322) Allow minus for kebab-case options
[
https://issues.apache.org/jira/browse/CLI-322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claude Warren resolved CLI-322.
---
Fix Version/s: 1.8.0
(was: 1.8.1)
Resolution: Fixed
Resolved by pull request #217
> Allow minus for kebab-case options
> --
>
> Key: CLI-322
> URL: https://issues.apache.org/jira/browse/CLI-322
> Project: Commons CLI
> Issue Type: New Feature
> Components: Parser
>Affects Versions: 1.6.0
>Reporter: Claude Warren
>Assignee: Claude Warren
>Priority: Minor
> Fix For: 1.8.0
>
>
> Currently minus (“-“) is not allowed in option names,
> which makes common long options in kebab-case
> (like {{--is-not-allowed}}) impossible.
> This change is to allow it inside an option name.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CLI-322) Allow minus for kebab-case options
[
https://issues.apache.org/jira/browse/CLI-322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17849187#comment-17849187
]
Claude Warren commented on CLI-322:
---
I think this should have been closed in 1.7.0 pull #217 resolved the issue.
> Allow minus for kebab-case options
> --
>
> Key: CLI-322
> URL: https://issues.apache.org/jira/browse/CLI-322
> Project: Commons CLI
> Issue Type: New Feature
> Components: Parser
>Affects Versions: 1.6.0
>Reporter: Claude Warren
>Assignee: Claude Warren
>Priority: Minor
> Fix For: 1.8.1
>
>
> Currently minus (“-“) is not allowed in option names,
> which makes common long options in kebab-case
> (like {{--is-not-allowed}}) impossible.
> This change is to allow it inside an option name.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (COLLECTIONS-854) Changes suggested to M1 release
[ https://issues.apache.org/jira/browse/COLLECTIONS-854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17847204#comment-17847204 ] Claude Warren edited comment on COLLECTIONS-854 at 5/17/24 10:57 AM: - changed forEachRemaining() in the CountingLongPredicate and CountingPredicate classes to processRemaining() to keep in spririt with Extractor usage. Added missing FunctionalInterface annotation to BloomFilterExtractor. was (Author: claudenw): changed forEachRemaining() in the CountingLongPredicate and CountingPredicate classes to processRemaining() to keep in spririt with Extractor usage. > Changes suggested to M1 release > --- > > Key: COLLECTIONS-854 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-854 > Project: Commons Collections > Issue Type: Improvement > Components: Bloomfilter >Affects Versions: 4.5.0-M1 >Reporter: Claude Warren >Assignee: Claude Warren >Priority: Minor > > This is a list of items that we have agreed need to be changed for clarity of > API. > see [https://lists.apache.org/thread/4fds9094c06o4gp1r8pf0xx4l0jthhds] > > * Rename classes: > ** CellConsumer to CellPredicate > ** BitMap to BitMaps. > ** BitMapProducer to BitMapExtractor > ** BloomFilterProducer to BloomFilterExtractor > ** IndexProducer to IndexExtractor > ** CellProducer to CellExtractor > * Rename methods: > ** Extractor methods forEachX() to processXs(Predicate) > * Be clear that extractors are like interruptible iterators with predicate > tests acting as a switch to stop the iteration before the final item. > * Document the semantic nomenclature: > ** Bitmaps are arrays of bits not a BitMaps object. > ** Indexes are ints and not an instance of a Collection object. > ** Cells are pairs of ints representing an index and a value. They are not > Pair<> objects. > ** Extractors > *** are extractors of representations of Bloom filter enabled bits. > *** iterate over logical collections of the object (Bitmap, Index, Cell) > applying a predicate to do work and stop the iteration early if necessary. > *** allow us to query the contents of the Bloom filter in an implementation > agnostic way. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (COLLECTIONS-854) Changes suggested to M1 release
[ https://issues.apache.org/jira/browse/COLLECTIONS-854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17847204#comment-17847204 ] Claude Warren commented on COLLECTIONS-854: --- changed forEachRemaining() in the CountingLongPredicate and CountingPredicate classes to processRemaining() to keep in spririt with Extractor usage. > Changes suggested to M1 release > --- > > Key: COLLECTIONS-854 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-854 > Project: Commons Collections > Issue Type: Improvement > Components: Bloomfilter >Affects Versions: 4.5.0-M1 >Reporter: Claude Warren >Assignee: Claude Warren >Priority: Minor > > This is a list of items that we have agreed need to be changed for clarity of > API. > see [https://lists.apache.org/thread/4fds9094c06o4gp1r8pf0xx4l0jthhds] > > * Rename classes: > ** CellConsumer to CellPredicate > ** BitMap to BitMaps. > ** BitMapProducer to BitMapExtractor > ** BloomFilterProducer to BloomFilterExtractor > ** IndexProducer to IndexExtractor > ** CellProducer to CellExtractor > * Rename methods: > ** Extractor methods forEachX() to processXs(Predicate) > * Be clear that extractors are like interruptible iterators with predicate > tests acting as a switch to stop the iteration before the final item. > * Document the semantic nomenclature: > ** Bitmaps are arrays of bits not a BitMaps object. > ** Indexes are ints and not an instance of a Collection object. > ** Cells are pairs of ints representing an index and a value. They are not > Pair<> objects. > ** Extractors > *** are extractors of representations of Bloom filter enabled bits. > *** iterate over logical collections of the object (Bitmap, Index, Cell) > applying a predicate to do work and stop the iteration early if necessary. > *** allow us to query the contents of the Bloom filter in an implementation > agnostic way. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (COLLECTIONS-854) Changes suggested to M1 release
[ https://issues.apache.org/jira/browse/COLLECTIONS-854?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claude Warren updated COLLECTIONS-854: -- Description: This is a list of items that we have agreed need to be changed for clarity of API. see [https://lists.apache.org/thread/4fds9094c06o4gp1r8pf0xx4l0jthhds] * Rename classes: ** CellConsumer to CellPredicate ** BitMap to BitMaps. ** BitMapProducer to BitMapExtractor ** BloomFilterProducer to BloomFilterExtractor ** IndexProducer to IndexExtractor ** CellProducer to CellExtractor * Rename methods: ** Extractor methods forEachX() to processXs(Predicate) * Be clear that extractors are like interruptible iterators with predicate tests acting as a switch to stop the iteration before the final item. * Document the semantic nomenclature: ** Bitmaps are arrays of bits not a BitMaps object. ** Indexes are ints and not an instance of a Collection object. ** Cells are pairs of ints representing an index and a value. They are not Pair<> objects. ** Extractors *** are extractors of representations of Bloom filter enabled bits. *** iterate over logical collections of the object (Bitmap, Index, Cell) applying a predicate to do work and stop the iteration early if necessary. *** allow us to query the contents of the Bloom filter in an implementation agnostic way. was: This is a list of items that we have agreed need to be changed for clarity of API. see [https://lists.apache.org/thread/4fds9094c06o4gp1r8pf0xx4l0jthhds] * Rename classes: ** CellConsumer to CellPredicate ** BitMap to BitMaps. ** BitMapProducer to BitMapExtractor ** BloomFilterProducer to BloomFilterExtractor ** IndexProducer to IndexExtractor ** CellProducer to CellExtractor * Rename methods: ** Extractor methods forEachX() to processX(Predicate) * Be clear that extractors are like interruptible iterators with predicate tests acting as a switch to stop the iteration before the final item. * Document the semantic nomenclature: ** Bitmaps are arrays of bits not a BitMaps object. ** Indexes are ints and not an instance of a Collection object. ** Cells are pairs of ints representing an index and a value. They are not Pair<> objects. ** Extractors *** are extractors of representations of Bloom filter enabled bits. *** iterate over logical collections of the object (Bitmap, Index, Cell) applying a predicate to do work and stop the iteration early if necessary. *** allow us to query the contents of the Bloom filter in an implementation agnostic way. > Changes suggested to M1 release > --- > > Key: COLLECTIONS-854 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-854 > Project: Commons Collections > Issue Type: Improvement > Components: Bloomfilter >Affects Versions: 4.5.0-M1 >Reporter: Claude Warren >Assignee: Claude Warren >Priority: Minor > > This is a list of items that we have agreed need to be changed for clarity of > API. > see [https://lists.apache.org/thread/4fds9094c06o4gp1r8pf0xx4l0jthhds] > > * Rename classes: > ** CellConsumer to CellPredicate > ** BitMap to BitMaps. > ** BitMapProducer to BitMapExtractor > ** BloomFilterProducer to BloomFilterExtractor > ** IndexProducer to IndexExtractor > ** CellProducer to CellExtractor > * Rename methods: > ** Extractor methods forEachX() to processXs(Predicate) > * Be clear that extractors are like interruptible iterators with predicate > tests acting as a switch to stop the iteration before the final item. > * Document the semantic nomenclature: > ** Bitmaps are arrays of bits not a BitMaps object. > ** Indexes are ints and not an instance of a Collection object. > ** Cells are pairs of ints representing an index and a value. They are not > Pair<> objects. > ** Extractors > *** are extractors of representations of Bloom filter enabled bits. > *** iterate over logical collections of the object (Bitmap, Index, Cell) > applying a predicate to do work and stop the iteration early if necessary. > *** allow us to query the contents of the Bloom filter in an implementation > agnostic way. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (COLLECTIONS-854) Changes suggested to M1 release
[ https://issues.apache.org/jira/browse/COLLECTIONS-854?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claude Warren updated COLLECTIONS-854: -- Description: This is a list of items that we have agreed need to be changed for clarity of API. see [https://lists.apache.org/thread/4fds9094c06o4gp1r8pf0xx4l0jthhds] * Rename classes: ** CellConsumer to CellPredicate ** BitMap to BitMaps. ** BitMapProducer to BitMapExtractor ** BloomFilterProducer to BloomFilterExtractor ** IndexProducer to IndexExtractor ** CellProducer to CellExtractor * Rename methods: ** Extractor methods forEachX() to processX(Predicate) * Be clear that extractors are like interruptible iterators with predicate tests acting as a switch to stop the iteration before the final item. * Document the semantic nomenclature: ** Bitmaps are arrays of bits not a BitMaps object. ** Indexes are ints and not an instance of a Collection object. ** Cells are pairs of ints representing an index and a value. They are not Pair<> objects. ** Extractors *** are extractors of representations of Bloom filter enabled bits. *** iterate over logical collections of the object (Bitmap, Index, Cell) applying a predicate to do work and stop the iteration early if necessary. *** allow us to query the contents of the Bloom filter in an implementation agnostic way. was: This is a list of items that we have agreed need to be changed for clarity of API. see [https://lists.apache.org/thread/4fds9094c06o4gp1r8pf0xx4l0jthhds] * Rename classes: ** CellConsumer to CellPredicate ** BitMap to BitMaps. ** BitMapProducer to BitMapExtractor ** BloomFilterProducer to BloomFilterExtractor ** IndexProducer to IndexExtractor * Rename methods: ** Extractor methods forEachX() to processX(Predicate) * Be clear that extractors are like interruptible iterators with predicate tests acting as a switch to stop the iteration before the final item. * Document the semantic nomenclature: ** Bitmaps are arrays of bits not a BitMaps object. ** Indexes are ints and not an instance of a Collection object. ** Cells are pairs of ints representing an index and a value. They are not Pair<> objects. ** Extractors *** are extractors of representations of Bloom filter enabled bits. *** iterate over logical collections of the object (Bitmap, Index, Cell) applying a predicate to do work and stop the iteration early if necessary. *** allow us to query the contents of the Bloom filter in an implementation agnostic way. > Changes suggested to M1 release > --- > > Key: COLLECTIONS-854 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-854 > Project: Commons Collections > Issue Type: Improvement > Components: Bloomfilter >Affects Versions: 4.5.0-M1 >Reporter: Claude Warren >Assignee: Claude Warren >Priority: Minor > > This is a list of items that we have agreed need to be changed for clarity of > API. > see [https://lists.apache.org/thread/4fds9094c06o4gp1r8pf0xx4l0jthhds] > > * Rename classes: > ** CellConsumer to CellPredicate > ** BitMap to BitMaps. > ** BitMapProducer to BitMapExtractor > ** BloomFilterProducer to BloomFilterExtractor > ** IndexProducer to IndexExtractor > ** CellProducer to CellExtractor > * Rename methods: > ** Extractor methods forEachX() to processX(Predicate) > * Be clear that extractors are like interruptible iterators with predicate > tests acting as a switch to stop the iteration before the final item. > * Document the semantic nomenclature: > ** Bitmaps are arrays of bits not a BitMaps object. > ** Indexes are ints and not an instance of a Collection object. > ** Cells are pairs of ints representing an index and a value. They are not > Pair<> objects. > ** Extractors > *** are extractors of representations of Bloom filter enabled bits. > *** iterate over logical collections of the object (Bitmap, Index, Cell) > applying a predicate to do work and stop the iteration early if necessary. > *** allow us to query the contents of the Bloom filter in an implementation > agnostic way. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (COLLECTIONS-853) API changes to LayeredBloomFilter, LayerManager and WrappedBloomFilter
[ https://issues.apache.org/jira/browse/COLLECTIONS-853?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claude Warren resolved COLLECTIONS-853. --- Resolution: Fixed fixed with pull request #481 > API changes to LayeredBloomFilter, LayerManager and WrappedBloomFilter > -- > > Key: COLLECTIONS-853 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-853 > Project: Commons Collections > Issue Type: Improvement >Affects Versions: 4.5.0-M1 >Reporter: Claude Warren >Assignee: Claude Warren >Priority: Major > > After looking at the LayeredBloomFilter and the LayerManager and the way it > is intended to be used I found a couple of changes that we might want to > consider. > 1) WrappedBloomFilter should not implement copy(), that should be left to the > wrapping implementation. > 2) We change LayerManager to be a templated type that contains a List extends BloomFilter> and add two methods first() and last() to retrieve the > first and last internal filters respectively. These are common queries and > should be directly implemented. > 3) We change LayeredBloomFilter to be a templated type BloomFilter> where T is the type of BloomFilter to be used for each Layer. > For example the use of LayeredBloomFilter for KIP-936 requires a BloomFilter > with an associated timestamp. So when copy() is called for duplication it > must create the same BloomFilter. It uses WrappedBloomFilter to add the > timestamp property. The LayeredBloomFilter in KIP-936 actually stores a > custom TimestampedBloomFilter implementation that extends WrappedBloomFilter. > This is a rather deep change to LayeredBloomFilter but I think Alex is > correct that we should use List, but that usage dictates that we use T > extends BloomFilter as the type. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (COLLECTIONS-852) LayeredBloomFilter needs a way to call clean without adding a new layer
[ https://issues.apache.org/jira/browse/COLLECTIONS-852?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claude Warren resolved COLLECTIONS-852. --- Resolution: Fixed Fixed with pull request 476 > LayeredBloomFilter needs a way to call clean without adding a new layer > --- > > Key: COLLECTIONS-852 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-852 > Project: Commons Collections > Issue Type: Improvement >Affects Versions: 4.5.0-M1 >Reporter: Claude Warren >Assignee: Claude Warren >Priority: Major > > Currently the LayeredBloomFilter has no mechanism to clean the filter without > adding something. > The only path to clean is to call next() adding a new layer or to add a > filter which changes the state of the last layer. In some cases it is > necessary to simply removed expired layers without changing the state of > existing layers. > This proposal is to add a clean() method to the LayeredBloomFilter that will > cause the filterCleanup consumer on the LayerManager to execute thus removing > any expired layers. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CLI-333) Define Builder as an implementation of Supplier
[ https://issues.apache.org/jira/browse/CLI-333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claude Warren updated CLI-333: -- Assignee: Claude Warren > Define Builder as an implementation of Supplier > --- > > Key: CLI-333 > URL: https://issues.apache.org/jira/browse/CLI-333 > Project: Commons CLI > Issue Type: New Feature > Components: CLI-1.x, Help formatter, Parser >Affects Versions: 1.7.0 >Reporter: Claude Warren >Assignee: Claude Warren >Priority: Minor > > The Builder pattern as described by the gang of four and general > implementations across multiple blogs and source packages creates a complex > pattern when a method is called. That method specified in the pattern > description is "getResult", however the review of several blogs and > implementations indicate that "build", "getX" "toX" are all popular names for > the production method. > In Java the Supplier interface defines a producer of X and stipulates that > every time the production method is called an instance of X must be returned. > It does allow for the same instance to be returned for every call. > Thus a Builder is a customization of the Supplier. As commons strives to > utilize the JRE patterns over custom patterns, it makes sense that all > Builders should implement Supplier. > Therefore this change is to have all Builders > # implement Supplier and add a get() method (if not already present) > # have the current producer method delegate to the get() method > # mark the current producer method as deprecated with a note to use get. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (COLLECTIONS-854) Changes suggested to M1 release
[ https://issues.apache.org/jira/browse/COLLECTIONS-854?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claude Warren updated COLLECTIONS-854: -- Description: This is a list of items that we have agreed need to be changed for clarity of API. see [https://lists.apache.org/thread/4fds9094c06o4gp1r8pf0xx4l0jthhds] * Rename classes: ** CellConsumer to CellPredicate ** BitMap to BitMaps. ** BitMapProducer to BitMapExtractor ** BloomFilterProducer to BloomFilterExtractor ** IndexProducer to IndexExtractor * Rename methods: ** Extractor methods forEachX() to processX(Predicate) * Be clear that extractors are like interruptible iterators with predicate tests acting as a switch to stop the iteration before the final item. * Document the semantic nomenclature: ** Bitmaps are arrays of bits not a BitMaps object. ** Indexes are ints and not an instance of a Collection object. ** Cells are pairs of ints representing an index and a value. They are not Pair<> objects. ** Extractors *** are extractors of representations of Bloom filter enabled bits. *** iterate over logical collections of the object (Bitmap, Index, Cell) applying a predicate to do work and stop the iteration early if necessary. *** allow us to query the contents of the Bloom filter in an implementation agnostic way. was: This is a list of items that we have agreed need to be changed for clarity of API. see [https://lists.apache.org/thread/4fds9094c06o4gp1r8pf0xx4l0jthhds] * Be clear that producers are like interruptible iterators with predicate tests acting as a switch to short-circuit the iteration. * Rename classes: * CellConsumer to CellPredicate * Rename BitMap to BitMaps. * Rename BitMapProducer to BitMapExtractor * Rename * Rename methods: * Producer forEachX() to forEachUntil() * The semantic nomenclature: * Bitmaps are arrays of bits not a BitMaps object. * Indexes are ints and not an instance of a Collection object. * Cells are pairs of ints representing an index and a value. They are not Pair<> objects. * Producers iterate over collections of the object (Bitmap, Index, Cell) applying a predicate to do work and stop the iteration early if necessary. They are carriers/transporters of Bloom filter enabled bits. They allow us to query the contents of the Bloom filter in an implementation agnostic way. > Changes suggested to M1 release > --- > > Key: COLLECTIONS-854 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-854 > Project: Commons Collections > Issue Type: Improvement > Components: Bloomfilter >Affects Versions: 4.5.0-M1 >Reporter: Claude Warren >Assignee: Claude Warren >Priority: Minor > > This is a list of items that we have agreed need to be changed for clarity of > API. > see [https://lists.apache.org/thread/4fds9094c06o4gp1r8pf0xx4l0jthhds] > > * Rename classes: > ** CellConsumer to CellPredicate > ** BitMap to BitMaps. > ** BitMapProducer to BitMapExtractor > ** BloomFilterProducer to BloomFilterExtractor > ** IndexProducer to IndexExtractor > * Rename methods: > ** Extractor methods forEachX() to processX(Predicate) > * Be clear that extractors are like interruptible iterators with predicate > tests acting as a switch to stop the iteration before the final item. > * Document the semantic nomenclature: > ** Bitmaps are arrays of bits not a BitMaps object. > ** Indexes are ints and not an instance of a Collection object. > ** Cells are pairs of ints representing an index and a value. They are not > Pair<> objects. > ** Extractors > *** are extractors of representations of Bloom filter enabled bits. > *** iterate over logical collections of the object (Bitmap, Index, Cell) > applying a predicate to do work and stop the iteration early if necessary. > *** allow us to query the contents of the Bloom filter in an implementation > agnostic way. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (COLLECTIONS-854) Changes suggested to M1 release
[ https://issues.apache.org/jira/browse/COLLECTIONS-854?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claude Warren updated COLLECTIONS-854: -- Description: This is a list of items that we have agreed need to be changed for clarity of API. see [https://lists.apache.org/thread/4fds9094c06o4gp1r8pf0xx4l0jthhds] * Be clear that producers are like interruptible iterators with predicate tests acting as a switch to short-circuit the iteration. * Rename classes: * CellConsumer to CellPredicate * Rename BitMap to BitMaps. * Rename BitMapProducer to BitMapExtractor * Rename * Rename methods: * Producer forEachX() to forEachUntil() * The semantic nomenclature: * Bitmaps are arrays of bits not a BitMaps object. * Indexes are ints and not an instance of a Collection object. * Cells are pairs of ints representing an index and a value. They are not Pair<> objects. * Producers iterate over collections of the object (Bitmap, Index, Cell) applying a predicate to do work and stop the iteration early if necessary. They are carriers/transporters of Bloom filter enabled bits. They allow us to query the contents of the Bloom filter in an implementation agnostic way. was: This is a list of items that we have agreed need to be changed for clarity of API. see https://lists.apache.org/thread/4fds9094c06o4gp1r8pf0xx4l0jthhds * Be clear that producers are like interruptible iterators with predicate tests acting as a switch to short-circuit the iteration. * Rename classes: * CellConsumer to CellPredicate (?) * Rename BitMap to BitMaps. * Rename methods: * Producer forEachX() to forEachUntil() * The semantic nomenclature: * Bitmaps are arrays of bits not a BitMaps object. * Indexes are ints and not an instance of a Collection object. * Cells are pairs of ints representing an index and a value. They are not Pair<> objects. * Producers iterate over collections of the object (Bitmap, Index, Cell) applying a predicate to do work and stop the iteration early if necessary. They are carriers/transporters of Bloom filter enabled bits. They allow us to query the contents of the Bloom filter in an implementation agnostic way. > Changes suggested to M1 release > --- > > Key: COLLECTIONS-854 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-854 > Project: Commons Collections > Issue Type: Improvement > Components: Bloomfilter >Affects Versions: 4.5.0-M1 >Reporter: Claude Warren >Assignee: Claude Warren >Priority: Minor > > This is a list of items that we have agreed need to be changed for clarity of > API. > see [https://lists.apache.org/thread/4fds9094c06o4gp1r8pf0xx4l0jthhds] > > * Be clear that producers are like interruptible iterators with predicate > tests acting as a switch to short-circuit the iteration. > * Rename classes: > * CellConsumer to CellPredicate > * Rename BitMap to BitMaps. > * Rename BitMapProducer to BitMapExtractor > * Rename > * Rename methods: > * Producer forEachX() to forEachUntil() > * The semantic nomenclature: > * Bitmaps are arrays of bits not a BitMaps object. > * Indexes are ints and not an instance of a Collection object. > * Cells are pairs of ints representing an index and a value. They are not > Pair<> objects. > * Producers iterate over collections of the object (Bitmap, Index, Cell) > applying a predicate to do work and stop the iteration early if necessary. > They are carriers/transporters of Bloom filter enabled bits. They allow us > to query the contents of the Bloom filter in an implementation agnostic way. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CLI-333) Define Builder as an implementation of Supplier
Claude Warren created CLI-333: - Summary: Define Builder as an implementation of Supplier Key: CLI-333 URL: https://issues.apache.org/jira/browse/CLI-333 Project: Commons CLI Issue Type: New Feature Components: CLI-1.x, Help formatter, Parser Affects Versions: 1.7.0 Reporter: Claude Warren The Builder pattern as described by the gang of four and general implementations across multiple blogs and source packages creates a complex pattern when a method is called. That method specified in the pattern description is "getResult", however the review of several blogs and implementations indicate that "build", "getX" "toX" are all popular names for the production method. In Java the Supplier interface defines a producer of X and stipulates that every time the production method is called an instance of X must be returned. It does allow for the same instance to be returned for every call. Thus a Builder is a customization of the Supplier. As commons strives to utilize the JRE patterns over custom patterns, it makes sense that all Builders should implement Supplier. Therefore this change is to have all Builders # implement Supplier and add a get() method (if not already present) # have the current producer method delegate to the get() method # mark the current producer method as deprecated with a note to use get. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CLI-332) Deprecated option details not specified in HelpFormatter
[ https://issues.apache.org/jira/browse/CLI-332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claude Warren updated CLI-332: -- Description: Currently the HelpFormatter just prings "[Deprecated]" at the front of the description for items that are deprecated. It would be nice to be able to provide more information in the help output. My proposal is to add a Function that will be applied to deprecated Options and to provide the text output. The default implementation will return "[Deprecated} "+option.getDescription(). was:Currently the HelpFormatter just prings "[Deprecated]" at the front of the description for items that are deprecated. It would be nice to be able to provide more information in the help output. > Deprecated option details not specified in HelpFormatter > > > Key: CLI-332 > URL: https://issues.apache.org/jira/browse/CLI-332 > Project: Commons CLI > Issue Type: Improvement > Components: Help formatter >Affects Versions: 1.7.0 >Reporter: Claude Warren >Priority: Minor > > Currently the HelpFormatter just prings "[Deprecated]" at the front of the > description for items that are deprecated. It would be nice to be able to > provide more information in the help output. > > My proposal is to add a Function that will be applied to > deprecated Options and to provide the text output. The default > implementation will return "[Deprecated} "+option.getDescription(). > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CLI-332) Deprecated option details not specified in HelpFormatter
[ https://issues.apache.org/jira/browse/CLI-332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claude Warren updated CLI-332: -- Assignee: Claude Warren > Deprecated option details not specified in HelpFormatter > > > Key: CLI-332 > URL: https://issues.apache.org/jira/browse/CLI-332 > Project: Commons CLI > Issue Type: Improvement > Components: Help formatter >Affects Versions: 1.7.0 >Reporter: Claude Warren >Assignee: Claude Warren >Priority: Minor > > Currently the HelpFormatter just prings "[Deprecated]" at the front of the > description for items that are deprecated. It would be nice to be able to > provide more information in the help output. > > My proposal is to add a Function that will be applied to > deprecated Options and to provide the text output. The default > implementation will return "[Deprecated} "+option.getDescription(). > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CLI-332) Deprecated option details not specified in HelpFormatter
Claude Warren created CLI-332: - Summary: Deprecated option details not specified in HelpFormatter Key: CLI-332 URL: https://issues.apache.org/jira/browse/CLI-332 Project: Commons CLI Issue Type: Improvement Components: Help formatter Affects Versions: 1.7.0 Reporter: Claude Warren Currently the HelpFormatter just prings "[Deprecated]" at the front of the description for items that are deprecated. It would be nice to be able to provide more information in the help output. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CLI-331) Deprecated option usage is not detected if non string keys are used for resolution.
[ https://issues.apache.org/jira/browse/CLI-331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claude Warren updated CLI-331: -- Assignee: Claude Warren > Deprecated option usage is not detected if non string keys are used for > resolution. > --- > > Key: CLI-331 > URL: https://issues.apache.org/jira/browse/CLI-331 > Project: Commons CLI > Issue Type: Bug > Components: CLI-1.x >Affects Versions: 1.7.0 >Reporter: Claude Warren >Assignee: Claude Warren >Priority: Major > > CommandLine.handleDeprecated() is not called if the option key is not a > string. > > For example getOptionValue() has both String and Option parameter types. > * getOptionValue(String) calls handleDeprecated() > * getOptionValue(Option) does not call handleDeprecated(). > In most cases the String parameter resolves the Option and calls the Option > parameter method of the same name. > The fix is to move the handleDeprecated() into the Option processing path. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CLI-331) Deprecated option usage is not detected if non string keys are used for resolution.
Claude Warren created CLI-331: - Summary: Deprecated option usage is not detected if non string keys are used for resolution. Key: CLI-331 URL: https://issues.apache.org/jira/browse/CLI-331 Project: Commons CLI Issue Type: Bug Components: CLI-1.x Affects Versions: 1.7.0 Reporter: Claude Warren CommandLine.handleDeprecated() is not called if the option key is not a string. For example getOptionValue() has both String and Option parameter types. * getOptionValue(String) calls handleDeprecated() * getOptionValue(Option) does not call handleDeprecated(). In most cases the String parameter resolves the Option and calls the Option parameter method of the same name. The fix is to move the handleDeprecated() into the Option processing path. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (COLLECTIONS-854) Changes suggested to M1 release
[ https://issues.apache.org/jira/browse/COLLECTIONS-854?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claude Warren updated COLLECTIONS-854: -- Assignee: Claude Warren > Changes suggested to M1 release > --- > > Key: COLLECTIONS-854 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-854 > Project: Commons Collections > Issue Type: Improvement > Components: Bloomfilter >Affects Versions: 4.5.0-M1 >Reporter: Claude Warren >Assignee: Claude Warren >Priority: Minor > > This is a list of items that we have agreed need to be changed for clarity of > API. > see https://lists.apache.org/thread/4fds9094c06o4gp1r8pf0xx4l0jthhds > > * Be clear that producers are like interruptible iterators with predicate > tests acting as a switch to short-circuit the iteration. > * Rename classes: > * CellConsumer to CellPredicate (?) > * Rename BitMap to BitMaps. > * Rename methods: > * Producer forEachX() to forEachUntil() > * The semantic nomenclature: > * Bitmaps are arrays of bits not a BitMaps object. > * Indexes are ints and not an instance of a Collection object. > * Cells are pairs of ints representing an index and a value. They are not > Pair<> objects. > * Producers iterate over collections of the object (Bitmap, Index, Cell) > applying a predicate to do work and stop the iteration early if necessary. > They are carriers/transporters of Bloom filter enabled bits. They allow us > to query the contents of the Bloom filter in an implementation agnostic way. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (COLLECTIONS-854) Changes suggested to M1 release
Claude Warren created COLLECTIONS-854: - Summary: Changes suggested to M1 release Key: COLLECTIONS-854 URL: https://issues.apache.org/jira/browse/COLLECTIONS-854 Project: Commons Collections Issue Type: Improvement Components: Bloomfilter Affects Versions: 4.5.0-M1 Reporter: Claude Warren This is a list of items that we have agreed need to be changed for clarity of API. see https://lists.apache.org/thread/4fds9094c06o4gp1r8pf0xx4l0jthhds * Be clear that producers are like interruptible iterators with predicate tests acting as a switch to short-circuit the iteration. * Rename classes: * CellConsumer to CellPredicate (?) * Rename BitMap to BitMaps. * Rename methods: * Producer forEachX() to forEachUntil() * The semantic nomenclature: * Bitmaps are arrays of bits not a BitMaps object. * Indexes are ints and not an instance of a Collection object. * Cells are pairs of ints representing an index and a value. They are not Pair<> objects. * Producers iterate over collections of the object (Bitmap, Index, Cell) applying a predicate to do work and stop the iteration early if necessary. They are carriers/transporters of Bloom filter enabled bits. They allow us to query the contents of the Bloom filter in an implementation agnostic way. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (COLLECTIONS-853) API changes to LayeredBloomFilter, LayerManager and WrappedBloomFilter
[ https://issues.apache.org/jira/browse/COLLECTIONS-853?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claude Warren updated COLLECTIONS-853: -- Assignee: Claude Warren > API changes to LayeredBloomFilter, LayerManager and WrappedBloomFilter > -- > > Key: COLLECTIONS-853 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-853 > Project: Commons Collections > Issue Type: Improvement >Affects Versions: 4.5.0-M1 >Reporter: Claude Warren >Assignee: Claude Warren >Priority: Major > > After looking at the LayeredBloomFilter and the LayerManager and the way it > is intended to be used I found a couple of changes that we might want to > consider. > 1) WrappedBloomFilter should not implement copy(), that should be left to the > wrapping implementation. > 2) We change LayerManager to be a templated type that contains a List extends BloomFilter> and add two methods first() and last() to retrieve the > first and last internal filters respectively. These are common queries and > should be directly implemented. > 3) We change LayeredBloomFilter to be a templated type BloomFilter> where T is the type of BloomFilter to be used for each Layer. > For example the use of LayeredBloomFilter for KIP-936 requires a BloomFilter > with an associated timestamp. So when copy() is called for duplication it > must create the same BloomFilter. It uses WrappedBloomFilter to add the > timestamp property. The LayeredBloomFilter in KIP-936 actually stores a > custom TimestampedBloomFilter implementation that extends WrappedBloomFilter. > This is a rather deep change to LayeredBloomFilter but I think Alex is > correct that we should use List, but that usage dictates that we use T > extends BloomFilter as the type. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (COLLECTIONS-853) API changes to LayeredBloomFilter, LayerManager and WrappedBloomFilter
Claude Warren created COLLECTIONS-853: - Summary: API changes to LayeredBloomFilter, LayerManager and WrappedBloomFilter Key: COLLECTIONS-853 URL: https://issues.apache.org/jira/browse/COLLECTIONS-853 Project: Commons Collections Issue Type: Improvement Affects Versions: 4.5.0-M1 Reporter: Claude Warren After looking at the LayeredBloomFilter and the LayerManager and the way it is intended to be used I found a couple of changes that we might want to consider. 1) WrappedBloomFilter should not implement copy(), that should be left to the wrapping implementation. 2) We change LayerManager to be a templated type that contains a List and add two methods first() and last() to retrieve the first and last internal filters respectively. These are common queries and should be directly implemented. 3) We change LayeredBloomFilter to be a templated type where T is the type of BloomFilter to be used for each Layer. For example the use of LayeredBloomFilter for KIP-936 requires a BloomFilter with an associated timestamp. So when copy() is called for duplication it must create the same BloomFilter. It uses WrappedBloomFilter to add the timestamp property. The LayeredBloomFilter in KIP-936 actually stores a custom TimestampedBloomFilter implementation that extends WrappedBloomFilter. This is a rather deep change to LayeredBloomFilter but I think Alex is correct that we should use List, but that usage dictates that we use T extends BloomFilter as the type. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (COLLECTIONS-852) LayeredBloomFilter needs a way to call clean without adding a new layer
[ https://issues.apache.org/jira/browse/COLLECTIONS-852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17836596#comment-17836596 ] Claude Warren commented on COLLECTIONS-852: --- Opened [https://github.com/apache/commons-collections/pull/476] to address this issue > LayeredBloomFilter needs a way to call clean without adding a new layer > --- > > Key: COLLECTIONS-852 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-852 > Project: Commons Collections > Issue Type: Improvement >Affects Versions: 4.5.0-M1 >Reporter: Claude Warren >Assignee: Claude Warren >Priority: Major > > Currently the LayeredBloomFilter has no mechanism to clean the filter without > adding something. > The only path to clean is to call next() adding a new layer or to add a > filter which changes the state of the last layer. In some cases it is > necessary to simply removed expired layers without changing the state of > existing layers. > This proposal is to add a clean() method to the LayeredBloomFilter that will > cause the filterCleanup consumer on the LayerManager to execute thus removing > any expired layers. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (COLLECTIONS-852) LayeredBloomFilter needs a way to call clean without adding a new layer
Claude Warren created COLLECTIONS-852: - Summary: LayeredBloomFilter needs a way to call clean without adding a new layer Key: COLLECTIONS-852 URL: https://issues.apache.org/jira/browse/COLLECTIONS-852 Project: Commons Collections Issue Type: Improvement Affects Versions: 4.5.0-M1 Reporter: Claude Warren Assignee: Claude Warren Currently the LayeredBloomFilter has no mechanism to clean the filter without adding something. The only path to clean is to call next() adding a new layer or to add a filter which changes the state of the last layer. In some cases it is necessary to simply removed expired layers without changing the state of existing layers. This proposal is to add a clean() method to the LayeredBloomFilter that will cause the filterCleanup consumer on the LayerManager to execute thus removing any expired layers. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CLI-221) cli's with last option as list type values and have argument are not parsed correctly
[
https://issues.apache.org/jira/browse/CLI-221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17824920#comment-17824920
]
Claude Warren commented on CLI-221:
---
The problem with closing this is thst the bug still exists in the
DefaultParser.
> cli's with last option as list type values and have argument are not parsed
> correctly
> -
>
> Key: CLI-221
> URL: https://issues.apache.org/jira/browse/CLI-221
> Project: Commons CLI
> Issue Type: Bug
> Components: Parser
>Affects Versions: 1.2
>Reporter: Gagan Jain
>Priority: Major
>
> I have set the value separator for an option to be comma (',').
> Consider the following cli:
> cli definition : cmd1 -o1 a1
> command name: 'cmd1'
> options: 'o1' accpets list of values separated by ','
> arguments: 'a1' single valued argument
> {code}cmd1 -o1 o1v1,o1v2,o1v3 a1v1{code}
> GnuParser parses this the cli with o1 having values {o1v1, o1v2, o1v3, a1v1}
> instead of {o1v1,o1v2,o1v3}
> Bug seems to be in org.apache.commons.cli.Parser's class processArgs method.
> {code:java}
> public void processArgs(Option opt, ListIterator iter) throws
> ParseException
> {
> // loop until an option is found
> while (iter.hasNext())
> {
> String str = (String) iter.next();
> // found an Option, not an argument
> if (getOptions().hasOption(str) && str.startsWith("-"))
> {
> iter.previous();
> break;
> }
> // found a value
> try
> {
>
> opt.addValueForProcessing(Util.stripLeadingAndTrailingQuotes(str));
> }
> catch (RuntimeException exp)
> {
> iter.previous();
> break;
> }
> }
> if (opt.getValues() == null && !opt.hasOptionalArg())
> {
> throw new MissingArgumentException(opt);
> }
> }
> {code}
> In my opinion, if a value separator is defined for option, and is other than
> space (' '), loop should break immediately after one iteration.
> Correct me, if I am wrong in my understanding.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (CLI-221) cli's with last option as list type values and have argument are not parsed correctly
[
https://issues.apache.org/jira/browse/CLI-221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17824678#comment-17824678
]
Claude Warren edited comment on CLI-221 at 3/8/24 9:20 AM:
---
We could change the function of the double dash. Currently it stops all
processing and interprets the rest of the command line as arguments (not
options). If the double dash were used to stop args to options processing then
something like
{noformat}
--has-multiple-values a,b c -2 -- -2 x
{noformat}
Would be correctly interpreted as
option --has-multiple-values having values a, b, c, -2
option -2 having value x
It does break the old interpretation of the above which would have rendered the
result as:
option --has-multiple-values having values a, b, c, -2
and there being 2 extra arguments: -2 and x
We could reinstate this by adding a second double dash so that
{noformat}
--has-multiple-values a,b c -2 -- -- -2 x
{noformat}
would be interpreted as
option --has-multiple-values having values a, b, c, -2
and there being 2 extra arguments: -2 and x
was (Author: claudenw):
We could change the function of the double '{-}'. Currently it stops all
processing and interprets the rest of the command line as arguments (not
options). If the double '{-}' were used to stop args to options processing
then something like
{noformat}
--has-multiple-values a,b c -2 -- -2 x
{noformat}
Would be correctly interpreted as
option --has-multiple-values having values a, b, c, -2
option -2 having value x
It does break the old interpretation of the above which would have rendered the
result as:
option --has-multiple-values having values a, b, c, -2
and there being 2 extra arguments: -2 and x
> cli's with last option as list type values and have argument are not parsed
> correctly
> -
>
> Key: CLI-221
> URL: https://issues.apache.org/jira/browse/CLI-221
> Project: Commons CLI
> Issue Type: Bug
> Components: Parser
>Affects Versions: 1.2
>Reporter: Gagan Jain
>Priority: Major
>
> I have set the value separator for an option to be comma (',').
> Consider the following cli:
> cli definition : cmd1 -o1 a1
> command name: 'cmd1'
> options: 'o1' accpets list of values separated by ','
> arguments: 'a1' single valued argument
> {code}cmd1 -o1 o1v1,o1v2,o1v3 a1v1{code}
> GnuParser parses this the cli with o1 having values {o1v1, o1v2, o1v3, a1v1}
> instead of {o1v1,o1v2,o1v3}
> Bug seems to be in org.apache.commons.cli.Parser's class processArgs method.
> {code:java}
> public void processArgs(Option opt, ListIterator iter) throws
> ParseException
> {
> // loop until an option is found
> while (iter.hasNext())
> {
> String str = (String) iter.next();
> // found an Option, not an argument
> if (getOptions().hasOption(str) && str.startsWith("-"))
> {
> iter.previous();
> break;
> }
> // found a value
> try
> {
>
> opt.addValueForProcessing(Util.stripLeadingAndTrailingQuotes(str));
> }
> catch (RuntimeException exp)
> {
> iter.previous();
> break;
> }
> }
> if (opt.getValues() == null && !opt.hasOptionalArg())
> {
> throw new MissingArgumentException(opt);
> }
> }
> {code}
> In my opinion, if a value separator is defined for option, and is other than
> space (' '), loop should break immediately after one iteration.
> Correct me, if I am wrong in my understanding.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CLI-221) cli's with last option as list type values and have argument are not parsed correctly
[
https://issues.apache.org/jira/browse/CLI-221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17824678#comment-17824678
]
Claude Warren commented on CLI-221:
---
We could change the function of the double '{-}'. Currently it stops all
processing and interprets the rest of the command line as arguments (not
options). If the double '{-}' were used to stop args to options processing
then something like
{noformat}
--has-multiple-values a,b c -2 -- -2 x
{noformat}
Would be correctly interpreted as
option --has-multiple-values having values a, b, c, -2
option -2 having value x
It does break the old interpretation of the above which would have rendered the
result as:
option --has-multiple-values having values a, b, c, -2
and there being 2 extra arguments: -2 and x
> cli's with last option as list type values and have argument are not parsed
> correctly
> -
>
> Key: CLI-221
> URL: https://issues.apache.org/jira/browse/CLI-221
> Project: Commons CLI
> Issue Type: Bug
> Components: Parser
>Affects Versions: 1.2
>Reporter: Gagan Jain
>Priority: Major
>
> I have set the value separator for an option to be comma (',').
> Consider the following cli:
> cli definition : cmd1 -o1 a1
> command name: 'cmd1'
> options: 'o1' accpets list of values separated by ','
> arguments: 'a1' single valued argument
> {code}cmd1 -o1 o1v1,o1v2,o1v3 a1v1{code}
> GnuParser parses this the cli with o1 having values {o1v1, o1v2, o1v3, a1v1}
> instead of {o1v1,o1v2,o1v3}
> Bug seems to be in org.apache.commons.cli.Parser's class processArgs method.
> {code:java}
> public void processArgs(Option opt, ListIterator iter) throws
> ParseException
> {
> // loop until an option is found
> while (iter.hasNext())
> {
> String str = (String) iter.next();
> // found an Option, not an argument
> if (getOptions().hasOption(str) && str.startsWith("-"))
> {
> iter.previous();
> break;
> }
> // found a value
> try
> {
>
> opt.addValueForProcessing(Util.stripLeadingAndTrailingQuotes(str));
> }
> catch (RuntimeException exp)
> {
> iter.previous();
> break;
> }
> }
> if (opt.getValues() == null && !opt.hasOptionalArg())
> {
> throw new MissingArgumentException(opt);
> }
> }
> {code}
> In my opinion, if a value separator is defined for option, and is other than
> space (' '), loop should break immediately after one iteration.
> Correct me, if I am wrong in my understanding.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CLI-285) Multiple Options in Option Group
[ https://issues.apache.org/jira/browse/CLI-285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17824636#comment-17824636 ] Claude Warren commented on CLI-285: --- Upon further reflection I think that to complete the set of check of valid option conditions, it is necessary to have a "requires" field that will accept either an OptionsCollection or an Option. In this case the option would only be valid if the requires were also valid and present. > Multiple Options in Option Group > > > Key: CLI-285 > URL: https://issues.apache.org/jira/browse/CLI-285 > Project: Commons CLI > Issue Type: Improvement > Components: CLI-1.x >Reporter: Richard Kao >Priority: Major > > Allow the creation of multiple Options with in an OptionGroup so something > like the following can be created: > [ -a ] [ [ -b ] [ -c ] | [ -d ] | [ -e ]] > So these would be valid: > -b > -c > -b -c > -d > -e > The "-d", "-e", and "-b -c" are mutually exclusive -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CLI-285) Multiple Options in Option Group
[ https://issues.apache.org/jira/browse/CLI-285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17824298#comment-17824298 ] Claude Warren commented on CLI-285: --- First, let's introduce the Interface OptionCollection – Simply a collection of options with methods to add "Option" and "OptionCollection" object to the collection and "boolean isValid()" a method to indicate that some internal reasoning about validity of the internal state. If we think about the "Options" class as an OptionCollection where isValid(CommandLine) returns true as long as there are no unpopulated required Option or OptionGroups. We can also think of OptionGroup as an instance of OptionCollection where isValid(CommandLine) returns true if only one contained Option or OptionCollection objects is valid. Then we can create a total of three OptionCollection implementations. RequireAll: isValid(CommandLine) returns true if all the contained Option or OptionCollection objects are valid. RequireOne: a synonym for the current OptionGroup RequireNone: isValid(CommandLine) returns true if all the contained Options or OptionsCollection objects are not valid. The changes to the internal code will be to replace all "OptionGroup" parameters with OptionCollection types. Implement the 3 RequireX instances of OptionCollection deprecate OptionGroup and reimplement it as subclass of RequireOne. extend Options to implement OptionCollection. I think this will address the issues with CLI-285 > Multiple Options in Option Group > > > Key: CLI-285 > URL: https://issues.apache.org/jira/browse/CLI-285 > Project: Commons CLI > Issue Type: Improvement > Components: CLI-1.x >Reporter: Richard Kao >Priority: Major > > Allow the creation of multiple Options with in an OptionGroup so something > like the following can be created: > [ -a ] [ [ -b ] [ -c ] | [ -d ] | [ -e ]] > So these would be valid: > -b > -c > -b -c > -d > -e > The "-d", "-e", and "-b -c" are mutually exclusive -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CLI-254) "test" gets parsed as test, quotes die :-(
[
https://issues.apache.org/jira/browse/CLI-254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claude Warren resolved CLI-254.
---
Resolution: Fixed
The solution was to add a DefaultParser.Builder with the option
setStripLeadingAndTrailingQuotes to change the way quotes are handled.
> "test" gets parsed as test, quotes die :-(
> --
>
> Key: CLI-254
> URL: https://issues.apache.org/jira/browse/CLI-254
> Project: Commons CLI
> Issue Type: Bug
>Affects Versions: 1.3
>Reporter: Alexander Petrossian (PAF)
>Priority: Major
> Time Spent: 2h 50m
> Remaining Estimate: 0h
>
> {code}
> def cli = new CliBuilder()
> cli.with {
> f longOpt:'json-filter','jq expression', args: 1
> }
> def vals = ['test', 't"es"t',
> "'test", "test'", "'test'",
> '"test', 'test"', '"test"']
> vals.each {
> def opt = cli.parse(['-f', it])
> assert opt.f == it
> }
> {code}
> It fails on last entry: "test".
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CLI-254) "test" gets parsed as test, quotes die :-(
[
https://issues.apache.org/jira/browse/CLI-254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17824283#comment-17824283
]
Claude Warren commented on CLI-254:
---
The solution was to add a DefaultParser.Builder with the option
setStripLeadingAndTrailingQuotes to change the way quotes are handled.
> "test" gets parsed as test, quotes die :-(
> --
>
> Key: CLI-254
> URL: https://issues.apache.org/jira/browse/CLI-254
> Project: Commons CLI
> Issue Type: Bug
>Affects Versions: 1.3
>Reporter: Alexander Petrossian (PAF)
>Priority: Major
> Time Spent: 2h 50m
> Remaining Estimate: 0h
>
> {code}
> def cli = new CliBuilder()
> cli.with {
> f longOpt:'json-filter','jq expression', args: 1
> }
> def vals = ['test', 't"es"t',
> "'test", "test'", "'test'",
> '"test', 'test"', '"test"']
> vals.each {
> def opt = cli.parse(['-f', it])
> assert opt.f == it
> }
> {code}
> It fails on last entry: "test".
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] (CLI-254) "test" gets parsed as test, quotes die :-(
[ https://issues.apache.org/jira/browse/CLI-254 ]
Claude Warren deleted comment on CLI-254:
---
was (Author: claudenw):
The solution was to add a DefaultParser.Builder with the option
setStripLeadingAndTrailingQuotes to change the way quotes are handled.
> "test" gets parsed as test, quotes die :-(
> --
>
> Key: CLI-254
> URL: https://issues.apache.org/jira/browse/CLI-254
> Project: Commons CLI
> Issue Type: Bug
>Affects Versions: 1.3
>Reporter: Alexander Petrossian (PAF)
>Priority: Major
> Time Spent: 2h 50m
> Remaining Estimate: 0h
>
> {code}
> def cli = new CliBuilder()
> cli.with {
> f longOpt:'json-filter','jq expression', args: 1
> }
> def vals = ['test', 't"es"t',
> "'test", "test'", "'test'",
> '"test', 'test"', '"test"']
> vals.each {
> def opt = cli.parse(['-f', it])
> assert opt.f == it
> }
> {code}
> It fails on last entry: "test".
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CLI-221) cli's with last option as list type values and have argument are not parsed correctly
[
https://issues.apache.org/jira/browse/CLI-221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17824006#comment-17824006
]
Claude Warren commented on CLI-221:
---
[~ggregory] The consensus here seems to be that the value separator if provided
should be required.
Closing this ticket will clear the path for several other issues to be closed.
I am tempted to declare that the value separator if provided is required. This
may be a breaking change for some usage but I think it is proper and clears up
a confusion.
> cli's with last option as list type values and have argument are not parsed
> correctly
> -
>
> Key: CLI-221
> URL: https://issues.apache.org/jira/browse/CLI-221
> Project: Commons CLI
> Issue Type: Bug
> Components: Parser
>Affects Versions: 1.2
>Reporter: Gagan Jain
>Priority: Major
>
> I have set the value separator for an option to be comma (',').
> Consider the following cli:
> cli definition : cmd1 -o1 a1
> command name: 'cmd1'
> options: 'o1' accpets list of values separated by ','
> arguments: 'a1' single valued argument
> {code}cmd1 -o1 o1v1,o1v2,o1v3 a1v1{code}
> GnuParser parses this the cli with o1 having values {o1v1, o1v2, o1v3, a1v1}
> instead of {o1v1,o1v2,o1v3}
> Bug seems to be in org.apache.commons.cli.Parser's class processArgs method.
> {code:java}
> public void processArgs(Option opt, ListIterator iter) throws
> ParseException
> {
> // loop until an option is found
> while (iter.hasNext())
> {
> String str = (String) iter.next();
> // found an Option, not an argument
> if (getOptions().hasOption(str) && str.startsWith("-"))
> {
> iter.previous();
> break;
> }
> // found a value
> try
> {
>
> opt.addValueForProcessing(Util.stripLeadingAndTrailingQuotes(str));
> }
> catch (RuntimeException exp)
> {
> iter.previous();
> break;
> }
> }
> if (opt.getValues() == null && !opt.hasOptionalArg())
> {
> throw new MissingArgumentException(opt);
> }
> }
> {code}
> In my opinion, if a value separator is defined for option, and is other than
> space (' '), loop should break immediately after one iteration.
> Correct me, if I am wrong in my understanding.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CLI-306) Issue parsing numeric options following an option which accepts multiple args in DefaultParser
[
https://issues.apache.org/jira/browse/CLI-306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17824004#comment-17824004
]
Claude Warren commented on CLI-306:
---
The issue arises because:
* --one allows multiple args/values
* we support both " --one a,b" and "–one a b" as valid arguments to have both
"a" and "b" as values for "one"
* we support negative numbers as proper values. So "–one -2" would be give
"one" the value of "-2".
* We don't have any way to signal the end of the option. We do have an option
"–" that turns off all argument processing after it.
I can see 3 solutions to this particular issue:
# create a '.enforceValueSeparator(',') that will require all arguments to
have the ','. This way the "-2" in the example will be seen as an option and
not a value.
# create an "end of values" token. Perhaps "-" by itself. So that the valid
input would then be "–one a,b - -2 c" this would force the parsing to stop
after "a,b".
# disallow all numeric options., Thus "-2" would be invalid, as would "-45",
and "-2.1". But options like "-3bf" would still be valid.
[~ggregory] I think #3 is the correct approach. Do you have an opinion.
> Issue parsing numeric options following an option which accepts multiple args
> in DefaultParser
> --
>
> Key: CLI-306
> URL: https://issues.apache.org/jira/browse/CLI-306
> Project: Commons CLI
> Issue Type: Bug
> Components: CLI-1.x
>Affects Versions: 1.4
>Reporter: Todd Ye
>Priority: Major
>
> commons-cli seems to be unable to detect numeric options in their short "opt"
> form following an option which takes multiple arguments.
> Will consistently throw:
> {code:java}
> Exception in thread "main" org.apache.commons.cli.MissingOptionException:
> Missing required option: 2
> {code}
> How to reproduce:
> {code:java}
> Option multipleOptional = Option.builder("1")
> .longOpt("one")
> .argName("value1,value2,...,valueN")
> .hasArgs()
> .valueSeparator(',')
> .build();
> Option singleMandatory = Option.builder("2")
> .argName("value")
> .longOpt("two")
> .hasArg()
> .required()
> .build();
> Options options = new Options();
> options.addOption(singleMandatory);
> options.addOption(multipleOptional);
> CommandLineParser parser = new DefaultParser();
> CommandLine line = parser.parse(options, args);
> for (Option o : line.getOptions()) {
> System.out.println(o.getOpt() + '\t'
> + Arrays.toString(o.getValues()));
> }
> {code}
> now pass in:
> {code:java}
> --one argNumOne,argNumTwo -2 argNumThree
> {code}
> Note that an error will not occur if "opt" is set to a char like "a/b/c" or
> if the previous option is set with hasArg() instead of hasArgs()
> Also error will not occur if the longOpt is used such as:
> {code:java}
> --one argNumOne,argNumTwo --two argNumThree
> {code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (CLI-327) Date processing tests fail on some systems
[ https://issues.apache.org/jira/browse/CLI-327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claude Warren resolved CLI-327. --- Resolution: Fixed Closed with pull request #244 > Date processing tests fail on some systems > -- > > Key: CLI-327 > URL: https://issues.apache.org/jira/browse/CLI-327 > Project: Commons CLI > Issue Type: Bug > Components: CLI-1.x >Affects Versions: 1.7.0 >Reporter: Claude Warren >Assignee: Claude Warren >Priority: Critical > > On one of my systems the date conversions do not work as expected. I suspect > this is some sort of entanglement between time zones and environment settings. > I was able to fix the problem by creating the expected values from known > values rather than hardcoding the expected date time strings. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CLI-326) Make options.getKey() public
[ https://issues.apache.org/jira/browse/CLI-326?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claude Warren resolved CLI-326. --- Resolution: Fixed Resolved with pull #239 > Make options.getKey() public > > > Key: CLI-326 > URL: https://issues.apache.org/jira/browse/CLI-326 > Project: Commons CLI > Issue Type: Bug > Components: Options definition >Affects Versions: 1.7.0 >Reporter: Claude Warren >Assignee: Claude Warren >Priority: Minor > > the Option method getKey() is package private. I believe that this is an > oversight and should have been public. > The method is useful when describing options that have command line issues > when the application is holding option references and not the option keys. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CLI-328) CommandLine does not have a getParsedOptionValues option
[ https://issues.apache.org/jira/browse/CLI-328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claude Warren updated CLI-328: -- Assignee: Claude Warren > CommandLine does not have a getParsedOptionValues option > > > Key: CLI-328 > URL: https://issues.apache.org/jira/browse/CLI-328 > Project: Commons CLI > Issue Type: Improvement >Reporter: Claude Warren >Assignee: Claude Warren >Priority: Major > > The CommandLine has a getParsedOptionValue() method and a getOptionValues() > method. The first returns an object based on the Option type or a Converter > provided on the method call. The second returns an array of String for > options that accept multiple values. > > getParseOptionValues() is to be a method that merges these two > functionalities and allows the retrieval of multiple parsed values for > options that accept multiple values. It will have the method parameters that > match the pattern found in getParsedOptionValue(). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CLI-328) CommandLine does not have a getParsedOptionValues option
Claude Warren created CLI-328: - Summary: CommandLine does not have a getParsedOptionValues option Key: CLI-328 URL: https://issues.apache.org/jira/browse/CLI-328 Project: Commons CLI Issue Type: Improvement Reporter: Claude Warren The CommandLine has a getParsedOptionValue() method and a getOptionValues() method. The first returns an object based on the Option type or a Converter provided on the method call. The second returns an array of String for options that accept multiple values. getParseOptionValues() is to be a method that merges these two functionalities and allows the retrieval of multiple parsed values for options that accept multiple values. It will have the method parameters that match the pattern found in getParsedOptionValue(). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CLI-327) Date processing tests fail on some systems
[
https://issues.apache.org/jira/browse/CLI-327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17822854#comment-17822854
]
Claude Warren commented on CLI-327:
---
Errors include
{{[ERROR] Tests run: 55, Failures: 1, Errors: 0, Skipped: 0, Time elapsed:
0.069 s <<< FAILURE! -- in org.apache.commons.cli.TypeHandlerTest}}
{{[ERROR] org.apache.commons.cli.TypeHandlerTest.createValueTests(String,
Class, Object)[4] -- Time elapsed: 0.002 s <<< FAILURE!}}
{{org.opentest4j.AssertionFailedError: expected: but was: }}
{{ at
org.junit.jupiter.api.AssertionFailureBuilder.build(AssertionFailureBuilder.java:151)}}
{{ at
org.junit.jupiter.api.AssertionFailureBuilder.buildAndThrow(AssertionFailureBuilder.java:132)}}
{{ at
org.junit.jupiter.api.AssertEquals.failNotEqual(AssertEquals.java:197)}}
{{ at
org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:182)}}
{{ at
org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:177)}}
{{ at org.junit.jupiter.api.Assertions.assertEquals(Assertions.java:1145)}}
{{ at
org.apache.commons.cli.TypeHandlerTest.createValueTests(TypeHandlerTest.java:160)}}
{{and }}
[ERROR] Tests run: 14, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.297
s <<< FAILURE! -- in org.apache.commons.cli.ConverterTests
[ERROR] org.apache.commons.cli.ConverterTests.dateTests -- Time elapsed: 0.166
s <<< FAILURE!
org.opentest4j.AssertionFailedError: expected:
but was:
at
org.junit.jupiter.api.AssertionFailureBuilder.build(AssertionFailureBuilder.java:151)
at
org.junit.jupiter.api.AssertionFailureBuilder.buildAndThrow(AssertionFailureBuilder.java:132)
at org.junit.jupiter.api.AssertEquals.failNotEqual(AssertEquals.java:197)
at org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:182)
at org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:177)
at org.junit.jupiter.api.Assertions.assertEquals(Assertions.java:1145)
at org.apache.commons.cli.ConverterTests.dateTests(ConverterTests.java:79)
at java.base/java.lang.reflect.Method.invoke(Method.java:568)
at java.base/java.util.ArrayList.forEach(ArrayList.java:1511)
at java.base/java.util.ArrayList.forEach(ArrayList.java:1511)
> Date processing tests fail on some systems
> --
>
> Key: CLI-327
> URL: https://issues.apache.org/jira/browse/CLI-327
> Project: Commons CLI
> Issue Type: Bug
> Components: CLI-1.x
>Affects Versions: 1.7.0
>Reporter: Claude Warren
>Assignee: Claude Warren
>Priority: Critical
>
> On one of my systems the date conversions do not work as expected. I suspect
> this is some sort of entanglement between time zones and environment settings.
> I was able to fix the problem by creating the expected values from known
> values rather than hardcoding the expected date time strings.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CLI-327) Date processing tests fail on some systems
[ https://issues.apache.org/jira/browse/CLI-327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claude Warren updated CLI-327: -- Assignee: Claude Warren > Date processing tests fail on some systems > -- > > Key: CLI-327 > URL: https://issues.apache.org/jira/browse/CLI-327 > Project: Commons CLI > Issue Type: Bug > Components: CLI-1.x >Affects Versions: 1.7.0 >Reporter: Claude Warren >Assignee: Claude Warren >Priority: Critical > > On one of my systems the date conversions do not work as expected. I suspect > this is some sort of entanglement between time zones and environment settings. > I was able to fix the problem by creating the expected values from known > values rather than hardcoding the expected date time strings. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CLI-327) Date processing tests fail on some systems
Claude Warren created CLI-327: - Summary: Date processing tests fail on some systems Key: CLI-327 URL: https://issues.apache.org/jira/browse/CLI-327 Project: Commons CLI Issue Type: Bug Components: CLI-1.x Affects Versions: 1.7.0 Reporter: Claude Warren On one of my systems the date conversions do not work as expected. I suspect this is some sort of entanglement between time zones and environment settings. I was able to fix the problem by creating the expected values from known values rather than hardcoding the expected date time strings. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CLI-326) Make options.getKey() public
[ https://issues.apache.org/jira/browse/CLI-326?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claude Warren updated CLI-326: -- Assignee: Claude Warren > Make options.getKey() public > > > Key: CLI-326 > URL: https://issues.apache.org/jira/browse/CLI-326 > Project: Commons CLI > Issue Type: Bug > Components: Options definition >Affects Versions: 1.7.0 >Reporter: Claude Warren >Assignee: Claude Warren >Priority: Minor > > the Option method getKey() is package private. I believe that this is an > oversight and should have been public. > The method is useful when describing options that have command line issues > when the application is holding option references and not the option keys. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CLI-326) Make options.getKey() public
Claude Warren created CLI-326: - Summary: Make options.getKey() public Key: CLI-326 URL: https://issues.apache.org/jira/browse/CLI-326 Project: Commons CLI Issue Type: Bug Components: Options definition Affects Versions: 1.7.0 Reporter: Claude Warren the Option method getKey() is package private. I believe that this is an oversight and should have been public. The method is useful when describing options that have command line issues when the application is holding option references and not the option keys. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CLI-325) When properties are retrieve for an Option that has both multiple arguments and a value separator only the first is retrieved.
Claude Warren created CLI-325:
-
Summary: When properties are retrieve for an Option that has both
multiple arguments and a value separator only the first is retrieved.
Key: CLI-325
URL: https://issues.apache.org/jira/browse/CLI-325
Project: Commons CLI
Issue Type: Bug
Components: Parser
Affects Versions: 1.6.0
Reporter: Claude Warren
Assignee: Claude Warren
Fix For: 1.7.0
When the following is executed it fails on the check for 2 values.
{color:#00} {color}{color:#7f0055}final{color}{color:#00} Option
{color}{color:#6a3e3e}option{color}{color:#00} =
Option.{color}{color:#00}builder{color}{color:#00}({color}{color:#2a00ff}"x"{color}{color:#00}){color}
{color:#00} .hasArgs(){color}
{color:#00} .valueSeparator(){color}
{color:#00} .desc({color}{color:#2a00ff}"Multiple arg option with value
separator."{color}{color:#00}){color}
{color:#00} .build();{color}
{color:#00} {color}
{color:#00} String[] {color}{color:#6a3e3e}args{color}{color:#00} =
{{color}{color:#2a00ff}"-x"{color}{color:#00},
{color}{color:#2a00ff}"A=a"{color}{color:#00},
{color}{color:#2a00ff}"B=b"{color}{color:#00}};{color}
{color:#00} CommandLine {color}{color:#6a3e3e}cmdLine{color}{color:#00}
=
DefaultParser.{color}{color:#00}builder{color}{color:#00}().build().parse({color}{color:#7f0055}new{color}{color:#00}
Options().addOption({color}{color:#6a3e3e}option{color}{color:#00}),
{color}{color:#6a3e3e}args{color}{color:#00});{color}
{color:#00} Properties {color}{color:#6a3e3e}props{color}{color:#00} =
{color}{color:#6a3e3e}cmdLine{color}{color:#00}.getOptionProperties({color}{color:#6a3e3e}option{color}{color:#00});{color}
{color:#00} {color}{color:#00}assertEquals{color}{color:#00}(2,
{color}{color:#6a3e3e}props{color}{color:#00}.size());{color}
{color:#00} {color}{color:#00}assertEquals{color}{color:#00}(
{color}{color:#2a00ff}"a"{color}{color:#00},
{color}{color:#6a3e3e}props{color}{color:#00}.get({color}{color:#2a00ff}"A"{color}{color:#00}));{color}
{color:#00} {color}{color:#00}assertEquals{color}{color:#00}(
{color}{color:#2a00ff}"b"{color}{color:#00},
{color}{color:#6a3e3e}props{color}{color:#00}.get({color}{color:#2a00ff}"B"{color}{color:#00}));{color}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CLI-324) Make adding OptionGroups and Options to existing Options easier
Claude Warren created CLI-324: - Summary: Make adding OptionGroups and Options to existing Options easier Key: CLI-324 URL: https://issues.apache.org/jira/browse/CLI-324 Project: Commons CLI Issue Type: Improvement Components: CLI-1.x Affects Versions: 1.6.0 Reporter: Claude Warren Fix For: 1.7.0 Currently it is not possible to add one Options to another Options nor is is possible to retrieve the collection of OptionGroups from the Options. This change fixes both of those issues. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CLI-323) Add methods to accept Supplier for getParsedOptionValue
[ https://issues.apache.org/jira/browse/CLI-323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claude Warren updated CLI-323: -- Description: Currently a Supplier is accepted as the default for getOptionValue() calls but a Supplier is not accepted as the default for getDefaultOptionValue This change is to add the Supplier to those methods. was: Currently a Supplier is accepted as the default for getParsedOption() calls but a Supplier is not accepted as the default for getOptionValue This change is to add the Supplier to those methods. > Add methods to accept Supplier for getParsedOptionValue > -- > > Key: CLI-323 > URL: https://issues.apache.org/jira/browse/CLI-323 > Project: Commons CLI > Issue Type: Improvement > Components: CLI-1.x >Affects Versions: 1.6.0 >Reporter: Claude Warren >Priority: Minor > Fix For: 1.7.0 > > > Currently a Supplier is accepted as the default for getOptionValue() > calls but a Supplier is not accepted as the default for > getDefaultOptionValue > This change is to add the Supplier to those methods. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CLI-323) Add methods to accept Supplier for getParsedOptionValue
[ https://issues.apache.org/jira/browse/CLI-323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claude Warren updated CLI-323: -- Summary: Add methods to accept Supplier for getParsedOptionValue (was: Add methods to accept Supplier for getOptionValue) > Add methods to accept Supplier for getParsedOptionValue > -- > > Key: CLI-323 > URL: https://issues.apache.org/jira/browse/CLI-323 > Project: Commons CLI > Issue Type: Improvement > Components: CLI-1.x >Affects Versions: 1.6.0 >Reporter: Claude Warren >Priority: Minor > Fix For: 1.7.0 > > > Currently a Supplier is accepted as the default for getParsedOption() > calls but a Supplier is not accepted as the default for getOptionValue > This change is to add the Supplier to those methods. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CLI-323) Add methods to accept Supplier for getOptionValue
Claude Warren created CLI-323: - Summary: Add methods to accept Supplier for getOptionValue Key: CLI-323 URL: https://issues.apache.org/jira/browse/CLI-323 Project: Commons CLI Issue Type: Improvement Components: CLI-1.x Affects Versions: 1.6.0 Reporter: Claude Warren Fix For: 1.7.0 Currently a Supplier is accepted as the default for getParsedOption() calls but a Supplier is not accepted as the default for getOptionValue This change is to add the Supplier to those methods. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CLI-321) Complete the implementation of TypeHandler
[ https://issues.apache.org/jira/browse/CLI-321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claude Warren updated CLI-321: -- Assignee: Claude Warren > Complete the implementation of TypeHandler > -- > > Key: CLI-321 > URL: https://issues.apache.org/jira/browse/CLI-321 > Project: Commons CLI > Issue Type: Improvement > Components: Parser >Affects Versions: 1.6.0 >Reporter: Claude Warren >Assignee: Claude Warren >Priority: Minor > Fix For: 1.7.0 > > > The current TypeHandler implementation notes indicate that the > BeanUtils.Converters should be used to create instances of the various types. > This issue is to complete the implementation of TypeHandler so that it uses > the BeanUtils.Converters. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CLI-322) Allow kabab-case options
Claude Warren created CLI-322: - Summary: Allow kabab-case options Key: CLI-322 URL: https://issues.apache.org/jira/browse/CLI-322 Project: Commons CLI Issue Type: New Feature Components: Parser Affects Versions: 1.6.0 Reporter: Claude Warren Fix For: 1.7.0 Currently the '-' is not allowed in the option name. This change is to allow '-' as an option name. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CLI-322) Allow kabab-case options
[ https://issues.apache.org/jira/browse/CLI-322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claude Warren updated CLI-322: -- Assignee: Claude Warren > Allow kabab-case options > > > Key: CLI-322 > URL: https://issues.apache.org/jira/browse/CLI-322 > Project: Commons CLI > Issue Type: New Feature > Components: Parser >Affects Versions: 1.6.0 >Reporter: Claude Warren >Assignee: Claude Warren >Priority: Minor > Fix For: 1.7.0 > > > Currently the '-' is not allowed in the option name. This change is to allow > '-' as an option name. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CLI-321) Complete the implementation of TypeHandler
[ https://issues.apache.org/jira/browse/CLI-321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17802116#comment-17802116 ] Claude Warren commented on CLI-321: --- I Pull request 216 implements the TypeHandler without the use of BeanUtils and provides extensions points for other uses where custom conversions and validations are desired. I think it is the better solution. > Complete the implementation of TypeHandler > -- > > Key: CLI-321 > URL: https://issues.apache.org/jira/browse/CLI-321 > Project: Commons CLI > Issue Type: Improvement > Components: Parser >Affects Versions: 1.6.0 >Reporter: Claude Warren >Priority: Minor > Fix For: 1.7.0 > > > The current TypeHandler implementation notes indicate that the > BeanUtils.Converters should be used to create instances of the various types. > This issue is to complete the implementation of TypeHandler so that it uses > the BeanUtils.Converters. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CLI-321) Complete the implementation of TypeHandler
[ https://issues.apache.org/jira/browse/CLI-321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17801199#comment-17801199 ] Claude Warren commented on CLI-321: --- I think that we also need to add getParsedOptionValue(Option option, Object defaultValue) to define a default return value if the option is empty. > Complete the implementation of TypeHandler > -- > > Key: CLI-321 > URL: https://issues.apache.org/jira/browse/CLI-321 > Project: Commons CLI > Issue Type: Improvement > Components: Parser >Affects Versions: 1.6.0 >Reporter: Claude Warren >Priority: Minor > Fix For: 1.7.0 > > > The current TypeHandler implementation notes indicate that the > BeanUtils.Converters should be used to create instances of the various types. > This issue is to complete the implementation of TypeHandler so that it uses > the BeanUtils.Converters. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CLI-321) Complete the implementation of TypeHandler
Claude Warren created CLI-321: - Summary: Complete the implementation of TypeHandler Key: CLI-321 URL: https://issues.apache.org/jira/browse/CLI-321 Project: Commons CLI Issue Type: Improvement Components: Parser Affects Versions: 1.6.0 Reporter: Claude Warren Fix For: 1.7.0 The current TypeHandler implementation notes indicate that the BeanUtils.Converters should be used to create instances of the various types. This issue is to complete the implementation of TypeHandler so that it uses the BeanUtils.Converters. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (COLLECTIONS-844) Counting Bloom filter expects counts (cells) to be ints
[ https://issues.apache.org/jira/browse/COLLECTIONS-844?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claude Warren updated COLLECTIONS-844: -- Summary: Counting Bloom filter expects counts (cells) to be ints (was: Counting Bloomfilter tests expect counts to be ints) > Counting Bloom filter expects counts (cells) to be ints > --- > > Key: COLLECTIONS-844 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-844 > Project: Commons Collections > Issue Type: Improvement >Affects Versions: 4.5 >Reporter: Claude Warren >Priority: Minor > > The AbstractCountingBloomFilterTest assumes that the Bloom filter is using an > int to track the counts. Any implementation using a smaller storage size > will not be able to pass the test. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (COLLECTIONS-844) Counting Bloomfilter tests expect counts to be ints
Claude Warren created COLLECTIONS-844: - Summary: Counting Bloomfilter tests expect counts to be ints Key: COLLECTIONS-844 URL: https://issues.apache.org/jira/browse/COLLECTIONS-844 Project: Commons Collections Issue Type: Improvement Affects Versions: 4.5 Reporter: Claude Warren The AbstractCountingBloomFilterTest assumes that the Bloom filter is using an int to track the counts. Any implementation using a smaller storage size will not be able to pass the test. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (COLLECTIONS-843) Add LayeredBloomFilter
[
https://issues.apache.org/jira/browse/COLLECTIONS-843?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claude Warren updated COLLECTIONS-843:
--
Description:
Add a Layered Bloom filter implementation along the lines described in
{color:#3f5fbf}Zhiwang{color}{color:#3f5fbf},
{color}{color:#3f5fbf}Cen{color}{color:#3f5fbf};
{color}{color:#3f5fbf}Jungang{color}{color:#3f5fbf},
{color}{color:#3f5fbf}Xu{color}{color:#3f5fbf};
{color}{color:#3f5fbf}Jian{color}{color:#3f5fbf}, Sun{color}
{color:#3f5fbf}(2010), "A
{color}{color:#3f5fbf}multi{color}{color:#7f7f9f}-{color}{color:#3f5fbf}layer
Bloom filter for duplicated URL detection",
{color}{color:#3f5fbf}Proc{color}{color:#3f5fbf}. 3rd{color}
{color:#3f5fbf}International Conference on Advanced Computer Theory and
Engineering (ICACTE{color}
{color:#3f5fbf}2010), {color}{color:#3f5fbf}vol{color}{color:#3f5fbf}. 1,
{color}{color:#3f5fbf}pp{color}{color:#3f5fbf}. V1–586–V1–591,
{color}{color:#3f5fbf}doi{color}{color:#3f5fbf}:10.1109/ICACTE.2010.5578947,
ISBN{color}
{color:#3f5fbf}978{color}{color:#7f7f9f}-{color}{color:#3f5fbf}1{color}{color:#7f7f9f}-{color}{color:#3f5fbf}4244{color}{color:#7f7f9f}-{color}{color:#3f5fbf}6539{color}{color:#7f7f9f}-{color}{color:#3f5fbf}2,
S2CID 3108985{color}
{color:#3f5fbf}in support of Kafka KIP-936.
[https://cwiki.apache.org/confluence/display/KAFKA/KIP-936%3A+Throttle+number+of+active+PIDs]{color}
Pull request: https://github.com/apache/commons-collections/pull/402
was:
Add a Layered Bloom filter implementation along the lines described in
{color:#3f5fbf}Zhiwang{color}{color:#3f5fbf},
{color}{color:#3f5fbf}Cen{color}{color:#3f5fbf};
{color}{color:#3f5fbf}Jungang{color}{color:#3f5fbf},
{color}{color:#3f5fbf}Xu{color}{color:#3f5fbf};
{color}{color:#3f5fbf}Jian{color}{color:#3f5fbf}, Sun{color}
{color:#3f5fbf}(2010), "A
{color}{color:#3f5fbf}multi{color}{color:#7f7f9f}-{color}{color:#3f5fbf}layer
Bloom filter for duplicated URL detection",
{color}{color:#3f5fbf}Proc{color}{color:#3f5fbf}. 3rd{color}
{color:#3f5fbf}International Conference on Advanced Computer Theory and
Engineering (ICACTE{color}
{color:#3f5fbf}2010), {color}{color:#3f5fbf}vol{color}{color:#3f5fbf}. 1,
{color}{color:#3f5fbf}pp{color}{color:#3f5fbf}. V1–586–V1–591,
{color}{color:#3f5fbf}doi{color}{color:#3f5fbf}:10.1109/ICACTE.2010.5578947,
ISBN{color}
{color:#3f5fbf}978{color}{color:#7f7f9f}-{color}{color:#3f5fbf}1{color}{color:#7f7f9f}-{color}{color:#3f5fbf}4244{color}{color:#7f7f9f}-{color}{color:#3f5fbf}6539{color}{color:#7f7f9f}-{color}{color:#3f5fbf}2,
S2CID 3108985{color}
{color:#3f5fbf}in support of Kafka KIP-936.
https://cwiki.apache.org/confluence/display/KAFKA/KIP-936%3A+Throttle+number+of+active+PIDs{color}
> Add LayeredBloomFilter
> --
>
> Key: COLLECTIONS-843
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-843
> Project: Commons Collections
> Issue Type: Improvement
> Components: Collection
>Affects Versions: 4.5
>Reporter: Claude Warren
>Priority: Major
>
> Add a Layered Bloom filter implementation along the lines described in
> {color:#3f5fbf}Zhiwang{color}{color:#3f5fbf},
> {color}{color:#3f5fbf}Cen{color}{color:#3f5fbf};
> {color}{color:#3f5fbf}Jungang{color}{color:#3f5fbf},
> {color}{color:#3f5fbf}Xu{color}{color:#3f5fbf};
> {color}{color:#3f5fbf}Jian{color}{color:#3f5fbf}, Sun{color}
> {color:#3f5fbf}(2010), "A
> {color}{color:#3f5fbf}multi{color}{color:#7f7f9f}-{color}{color:#3f5fbf}layer
> Bloom filter for duplicated URL detection",
> {color}{color:#3f5fbf}Proc{color}{color:#3f5fbf}. 3rd{color}
> {color:#3f5fbf}International Conference on Advanced Computer Theory and
> Engineering (ICACTE{color}
> {color:#3f5fbf}2010), {color}{color:#3f5fbf}vol{color}{color:#3f5fbf}. 1,
> {color}{color:#3f5fbf}pp{color}{color:#3f5fbf}. V1–586–V1–591,
> {color}{color:#3f5fbf}doi{color}{color:#3f5fbf}:10.1109/ICACTE.2010.5578947,
> ISBN{color}
> {color:#3f5fbf}978{color}{color:#7f7f9f}-{color}{color:#3f5fbf}1{color}{color:#7f7f9f}-{color}{color:#3f5fbf}4244{color}{color:#7f7f9f}-{color}{color:#3f5fbf}6539{color}{color:#7f7f9f}-{color}{color:#3f5fbf}2,
> S2CID 3108985{color}
>
> {color:#3f5fbf}in support of Kafka KIP-936.
> [https://cwiki.apache.org/confluence/display/KAFKA/KIP-936%3A+Throttle+number+of+active+PIDs]{color}
>
> Pull request: https://github.com/apache/commons-collections/pull/402
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (COLLECTIONS-843) Add LayeredBloomFilter
Claude Warren created COLLECTIONS-843:
-
Summary: Add LayeredBloomFilter
Key: COLLECTIONS-843
URL: https://issues.apache.org/jira/browse/COLLECTIONS-843
Project: Commons Collections
Issue Type: Improvement
Components: Collection
Affects Versions: 4.5
Reporter: Claude Warren
Add a Layered Bloom filter implementation along the lines described in
{color:#3f5fbf}Zhiwang{color}{color:#3f5fbf},
{color}{color:#3f5fbf}Cen{color}{color:#3f5fbf};
{color}{color:#3f5fbf}Jungang{color}{color:#3f5fbf},
{color}{color:#3f5fbf}Xu{color}{color:#3f5fbf};
{color}{color:#3f5fbf}Jian{color}{color:#3f5fbf}, Sun{color}
{color:#3f5fbf}(2010), "A
{color}{color:#3f5fbf}multi{color}{color:#7f7f9f}-{color}{color:#3f5fbf}layer
Bloom filter for duplicated URL detection",
{color}{color:#3f5fbf}Proc{color}{color:#3f5fbf}. 3rd{color}
{color:#3f5fbf}International Conference on Advanced Computer Theory and
Engineering (ICACTE{color}
{color:#3f5fbf}2010), {color}{color:#3f5fbf}vol{color}{color:#3f5fbf}. 1,
{color}{color:#3f5fbf}pp{color}{color:#3f5fbf}. V1–586–V1–591,
{color}{color:#3f5fbf}doi{color}{color:#3f5fbf}:10.1109/ICACTE.2010.5578947,
ISBN{color}
{color:#3f5fbf}978{color}{color:#7f7f9f}-{color}{color:#3f5fbf}1{color}{color:#7f7f9f}-{color}{color:#3f5fbf}4244{color}{color:#7f7f9f}-{color}{color:#3f5fbf}6539{color}{color:#7f7f9f}-{color}{color:#3f5fbf}2,
S2CID 3108985{color}
{color:#3f5fbf}in support of Kafka KIP-936.
https://cwiki.apache.org/confluence/display/KAFKA/KIP-936%3A+Throttle+number+of+active+PIDs{color}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (COLLECTIONS-841) Open up Bloom filter testing code
Claude Warren created COLLECTIONS-841: - Summary: Open up Bloom filter testing code Key: COLLECTIONS-841 URL: https://issues.apache.org/jira/browse/COLLECTIONS-841 Project: Commons Collections Issue Type: Improvement Components: Collection Affects Versions: 4.5 Reporter: Claude Warren Currently the Bloom filter test code has a number of methods that are final. Some new implementations of Bloom filter (e.g. stable Bloom filter) need to override some of the methods as the stable Bloom filter has different characteristics. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (COLLECTIONS-840) Make EnhancedDoubleHasher.mod() public
[ https://issues.apache.org/jira/browse/COLLECTIONS-840?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17731229#comment-17731229 ] Claude Warren commented on COLLECTIONS-840: --- Pull request to implement change > Make EnhancedDoubleHasher.mod() public > -- > > Key: COLLECTIONS-840 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-840 > Project: Commons Collections > Issue Type: Improvement > Components: Collection >Reporter: Claude Warren >Priority: Minor > > The integer modulus calculation is currently package private but is very > useful outside of the package for further Bloom filter development. This > change is to make the static EnhancedDoubleHasher.mod() method public -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (COLLECTIONS-840) Make EnhancedDoubleHasher.mod() public
[ https://issues.apache.org/jira/browse/COLLECTIONS-840?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17731202#comment-17731202 ] Claude Warren commented on COLLECTIONS-840: --- Actually, I did not think it was a great place either. I figured submitting the change would get a discussion started. BitMap was the only other utility class that came to mind. We could add it as a static method on the Hasher interface but that seems a bit out of character. > Make EnhancedDoubleHasher.mod() public > -- > > Key: COLLECTIONS-840 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-840 > Project: Commons Collections > Issue Type: Improvement > Components: Collection >Affects Versions: 4.5 >Reporter: Claude Warren >Priority: Minor > > The integer modulus calculation is currently package private but is very > useful outside of the package for further Bloom filter development. This > change is to make the static EnhancedDoubleHasher.mod() method public -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (COLLECTIONS-840) Make EnhancedDoubleHasher.mod() public
Claude Warren created COLLECTIONS-840: - Summary: Make EnhancedDoubleHasher.mod() public Key: COLLECTIONS-840 URL: https://issues.apache.org/jira/browse/COLLECTIONS-840 Project: Commons Collections Issue Type: Improvement Components: Collection Affects Versions: 4.5 Reporter: Claude Warren The integer modulus calculation is currently package private but is very useful outside of the package for further Bloom filter development. This change is to make the static EnhancedDoubleHasher.mod() method public -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (LOGGING-184) Logging DOAP file has an error
Claude Warren created LOGGING-184:
-
Summary: Logging DOAP file has an error
Key: LOGGING-184
URL: https://issues.apache.org/jira/browse/LOGGING-184
Project: Commons Logging
Issue Type: Bug
Affects Versions: 1.2
Reporter: Claude Warren
The DOAP file [1] as listed in [2] has the error:
[line: 26, col: 4 ] \{E201} The attributes on this property element, are not
permitted with any content; expecting end element tag.
[1]
https://gitbox.apache.org/repos/asf?p=logging-log4cxx.git;a=blob_plain;f=doap_log4cxx.rdf;hb=HEAD
[2]
https://svn.apache.org/repos/asf/comdev/projects.apache.org/trunk/data/projects.xml
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (COLLECTIONS-816) SimpleBloomFilter: There is no coverage of this branch. It is not possible.
[
https://issues.apache.org/jira/browse/COLLECTIONS-816?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claude Warren closed COLLECTIONS-816.
-
Fix Version/s: 4.5
Resolution: Fixed
Fixed in earlier change to merge
> SimpleBloomFilter: There is no coverage of this branch. It is not possible.
>
>
> Key: COLLECTIONS-816
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-816
> Project: Commons Collections
> Issue Type: Improvement
> Components: Collection
>Affects Versions: 4.5
>Reporter: Claude Warren
>Assignee: Claude Warren
>Priority: Minor
> Labels: bloom-filter
> Fix For: 4.5
>
>
> Copied from Simplify Bloom Filters pull request.
> [https://github.com/apache/commons-collections/pull/258#discussion_r815505285]
>
> [https://github.com/Claudenw/commons-collections/blob/9f2945cc98747893456b73f42ab53f46a866ac37/src/main/java/org/apache/commons/collections4/bloomfilter/SimpleBloomFilter.java#L165-L168]
>
>
> Member
> h3.
> !https://avatars.githubusercontent.com/u/886334?s=48=4|width=24,height=24!
> *[aherbert|https://github.com/aherbert]* [on 27
> Feb|https://github.com/apache/commons-collections/pull/258#discussion_r815505285]
> There is no coverage of this branch. It is not possible. If this were true
> the bitMap[idx[0]] in the main forEach loop would have thrown an array index
> out of bound exception. I think this can be removed. The final check to
> determine if the final upper bitmap does not set incorrect bits is valid.
> Note: Even though the check is made that the upper bits have been set
> correctly, if they have not the exception is raised and the filter now has
> incorrect bits for the rest of its lifetime, i.e. no recovery is made and no
> flag is present in the filter to indicate the bits are bad. So you could then
> merge this into another filter and get the same exception, or record the bits
> to file and have bad bits in the recording, etc.
> The same 'bug' is present in the SparseBloomFilter. It will raise an
> exception after merge if the TreeSet first or last position are outside the
> shape but not correct it.
> I think these filters should attempt to clear any invalid bits before
> throwing exceptions. This makes them act as if they are a plain {{int[]}} of
> size {{nbits}} containing 0 or 1s. It should not be possible to put an index
> outside the range of the shape in the filter.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (COLLECTIONS-768) Flat3MapTest.tesetEntrySet() is flaky
[ https://issues.apache.org/jira/browse/COLLECTIONS-768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claude Warren resolved COLLECTIONS-768. --- Fix Version/s: 4.5 Resolution: Resolved Issue was fixed as per comments in the pull request. > Flat3MapTest.tesetEntrySet() is flaky > - > > Key: COLLECTIONS-768 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-768 > Project: Commons Collections > Issue Type: Bug > Components: Map >Affects Versions: 4.4 >Reporter: XinT >Priority: Minor > Labels: easyfix, pull-request-available > Fix For: 4.5 > > Time Spent: 2h 20m > Remaining Estimate: 0h > > The testEntrySet() function > (org.apache.commons.collections4.map.Flat3MapTest#testEntrySet) is flaky > because it uses a flaky helper function putAndRemove(). The helper function > wrongly assumes that map iterators execute in insertion order, while in fact > it can be any order. > The current test asserts the last element iterated (and subsequently removed) > is the last element inserted. Therefore, the test passes when it so happens > that the last iterated element is the last inserted element, but fails > otherwise. > > The proposed fix is: https://github.com/apache/commons-collections/pull/189 > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (COLLECTIONS-837) Remove HasherCollection from bloomfilter code base
Claude Warren created COLLECTIONS-837: - Summary: Remove HasherCollection from bloomfilter code base Key: COLLECTIONS-837 URL: https://issues.apache.org/jira/browse/COLLECTIONS-837 Project: Commons Collections Issue Type: Bug Affects Versions: 4.5 Reporter: Claude Warren HasherCollection does not match the Hasher interface. It and all associated tests are to be removed. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (COLLECTIONS-837) Remove HasherCollection from bloomfilter code base
[ https://issues.apache.org/jira/browse/COLLECTIONS-837?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claude Warren updated COLLECTIONS-837: -- Assignee: Claude Warren > Remove HasherCollection from bloomfilter code base > -- > > Key: COLLECTIONS-837 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-837 > Project: Commons Collections > Issue Type: Bug >Affects Versions: 4.5 >Reporter: Claude Warren >Assignee: Claude Warren >Priority: Major > > HasherCollection does not match the Hasher interface. It and all associated > tests are to be removed. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (COLLECTIONS-830) Add isEmpty() method to Hasher
[
https://issues.apache.org/jira/browse/COLLECTIONS-830?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claude Warren resolved COLLECTIONS-830.
---
Resolution: Won't Fix
HasherCollection to be removed from code base.
> Add isEmpty() method to Hasher
> --
>
> Key: COLLECTIONS-830
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-830
> Project: Commons Collections
> Issue Type: Improvement
> Components: Collection
>Affects Versions: 4.5
>Reporter: Claude Warren
>Assignee: Claude Warren
>Priority: Minor
> Labels: bloom-filter
> Time Spent: 20m
> Remaining Estimate: 0h
>
> The Hasher interface in the {{bloomfilter}} package does not have a way to
> determine if the hasher is empty. For the {{SimpleHasher}} implementation
> that is not an issue, however, the {{HasherCollection}} can be empty, and
> there is no guarantee that any other implementation of Hasher may have an
> empty state.
> I have a use case where a {{Hasher}} is passed to a search method in a
> multidimensional Bloom filter. If the hasher is empty then we are doing the
> equivalent of a table scan in a database.
> It is possible to determine if the hasher is not empty by something like
> {quote}{{boolean[] notEmpty = boolean[1];}}
> hasher.indices( shape ).forEachIndex( i ->\{notEmpty[0]=true;return false;});
> {quote}
> And then checking notEmpty[0].
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (COLLECTIONS-819) BloomFilter: Remove methods only used in testing from IndexProducer
[ https://issues.apache.org/jira/browse/COLLECTIONS-819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17629439#comment-17629439 ] Claude Warren commented on COLLECTIONS-819: --- [~aherbert] , I think this can be closed as "won't fix" or "works as designed". Or do you still think it should be deleted? > BloomFilter: Remove methods only used in testing from IndexProducer > --- > > Key: COLLECTIONS-819 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-819 > Project: Commons Collections > Issue Type: Improvement > Components: Collection >Affects Versions: 4.5 >Reporter: Claude Warren >Priority: Minor > Labels: bloom-filter > > [https://github.com/Claudenw/commons-collections/blob/9f2945cc98747893456b73f42ab53f46a866ac37/src/main/java/org/apache/commons/collections4/bloomfilter/IndexProducer.java#L50-L68] > > h3. > !https://avatars.githubusercontent.com/u/886334?s=48=4|width=24,height=24! > *[aherbert|https://github.com/aherbert]* [on 27 > Feb|https://github.com/apache/commons-collections/pull/258#discussion_r813449970] > This method is only used in testing. What is the use case? Note that > BloomFilter interface cannot merge an IndexProducer. This functionality is > only provided by the constructors for SimpleBloomFilter and > SparseBloomFitler. The method is trivially implemented if a user did want to > populate a Bloom filter with certain indices. But I do not see why they would > unless deserialising its stored representation. Given that we are not > supporting any such constructors for the ArrayCountingBloomFilter (creating > and populating at the same time) this seems like a partial support in the > library. Either the serialisation and deserialisation is better supported, or > we drop these methods from the public API for now. > > > [https://github.com/Claudenw/commons-collections/blob/9f2945cc98747893456b73f42ab53f46a866ac37/src/main/java/org/apache/commons/collections4/bloomfilter/IndexProducer.java#L104-L119] > > h3. > !https://avatars.githubusercontent.com/u/886334?s=48=4|width=24,height=24! > *[aherbert|https://github.com/aherbert]* [on 27 > Feb|https://github.com/apache/commons-collections/pull/258#discussion_r813449970] > This method is only used in testing. It is not required for any other > functionality in the API. What is the use case? If this is for serialisation > then the method is trivially performed anyway and the decision should be made > to use this or the bitmap long[] representation depending on the saturation > of the filter. It would be simpler to drop this method. > h3. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (COLLECTIONS-834) BitCountProducer operation is not clearly defined.
Claude Warren created COLLECTIONS-834: - Summary: BitCountProducer operation is not clearly defined. Key: COLLECTIONS-834 URL: https://issues.apache.org/jira/browse/COLLECTIONS-834 Project: Commons Collections Issue Type: Bug Components: Collection Affects Versions: 4.5 Reporter: Claude Warren When constructing a BitMapProducer from an IndexProducer the expected outcome when the IndexProducer produces duplicates is not well defined. This change is to document the expected behaviour and verify the expected behaviour through tests. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (COLLECTIONS-833) Intermittent failure in EmptyPropertiesTest
[
https://issues.apache.org/jira/browse/COLLECTIONS-833?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17584312#comment-17584312
]
Claude Warren commented on COLLECTIONS-833:
---
Perhaps a change to remove the lines from both files and if desired compare
them for approximate equivalence.
> Intermittent failure in EmptyPropertiesTest
> ---
>
> Key: COLLECTIONS-833
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-833
> Project: Commons Collections
> Issue Type: Test
> Components: Properties
>Reporter: Claude Warren
>Assignee: Gary D. Gregory
>Priority: Minor
> Fix For: 4.5
>
>
> Intermittent failure:
> {{Error: Failures: }}
> {{Error: EmptyPropertiesTest.testStoreToOutputStream:319 array contents
> differ at index [33], expected: <51> but was: <50>}}
>
> While testing changes in `bloomfilter` package an unmodified test on an
> unmodified class failed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (COLLECTIONS-833) Intermittent failure in EmptyPropertiesTest
Claude Warren created COLLECTIONS-833:
-
Summary: Intermittent failure in EmptyPropertiesTest
Key: COLLECTIONS-833
URL: https://issues.apache.org/jira/browse/COLLECTIONS-833
Project: Commons Collections
Issue Type: Test
Components: Properties
Affects Versions: 4.5
Reporter: Claude Warren
Intermittent failure:
{{Error: Failures: }}
{{Error: EmptyPropertiesTest.testStoreToOutputStream:319 array contents differ
at index [33], expected: <51> but was: <50>}}
While testing changes in `bloomfilter` package an unmodified test on an
unmodified class failed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (COLLECTIONS-763) Remove BloomFilter constructors that create initial entry
[
https://issues.apache.org/jira/browse/COLLECTIONS-763?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claude Warren updated COLLECTIONS-763:
--
Assignee: Claude Warren
> Remove BloomFilter constructors that create initial entry
> -
>
> Key: COLLECTIONS-763
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-763
> Project: Commons Collections
> Issue Type: Improvement
> Components: Collection
>Affects Versions: 4.x
>Reporter: Claude Warren
>Assignee: Claude Warren
>Priority: Minor
>
> Bloom Filters have constructors that both define and create an initial entry.
> Defining both the collection and adding an initial entry in the constructor
> is not standard across the java collections.
> This change is to remove the BloomFilter constructors that produce initial
> entries.
> So the line
> {{BloomFilter filter = new BitSetBloomFIlter( aHasher, aShape );}}
> becomes
> {{BloomFilter filter = new BitSetBloomFIlter( aShape );}}
> {{filter.merge( aHahser );}}
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Work logged] (COLLECTIONS-831) BloomFilter: add clear() method
[ https://issues.apache.org/jira/browse/COLLECTIONS-831?focusedWorklogId=802413=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-802413 ] Claude Warren logged work on COLLECTIONS-831: - Author: Claude Warren Created on: 22/Aug/22 09:43 Start Date: 21/Aug/22 09:42 Worklog Time Spent: 1h Work Description: Implemented Issue Time Tracking --- Worklog Id: (was: 802413) Remaining Estimate: 0h (was: 1h) Time Spent: 1h > BloomFilter: add clear() method > --- > > Key: COLLECTIONS-831 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-831 > Project: Commons Collections > Issue Type: Improvement > Components: Collection >Affects Versions: 4.5 >Reporter: Claude Warren >Assignee: Claude Warren >Priority: Minor > Labels: bloom-filter > Fix For: 4.5 > > Original Estimate: 1h > Time Spent: 1h > Remaining Estimate: 0h > > In cases where a Bloom filter is set and then cleared it is more efficient to > clear the filter rather than dispose of it and create a new one. > Particularly for large filters in environments where GC can be an issue. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (COLLECTIONS-831) BloomFilter: add clear() method
[ https://issues.apache.org/jira/browse/COLLECTIONS-831?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claude Warren resolved COLLECTIONS-831. --- Fix Version/s: 4.5 Resolution: Fixed https://github.com/apache/commons-collections/pull/330 > BloomFilter: add clear() method > --- > > Key: COLLECTIONS-831 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-831 > Project: Commons Collections > Issue Type: Improvement > Components: Collection >Affects Versions: 4.5 >Reporter: Claude Warren >Assignee: Claude Warren >Priority: Minor > Labels: bloom-filter > Fix For: 4.5 > > Original Estimate: 1h > Remaining Estimate: 1h > > In cases where a Bloom filter is set and then cleared it is more efficient to > clear the filter rather than dispose of it and create a new one. > Particularly for large filters in environments where GC can be an issue. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (COLLECTIONS-831) BloomFilter: add clear() method
[ https://issues.apache.org/jira/browse/COLLECTIONS-831?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17582841#comment-17582841 ] Claude Warren commented on COLLECTIONS-831: --- Pull request is: https://github.com/apache/commons-collections/pull/330 > BloomFilter: add clear() method > --- > > Key: COLLECTIONS-831 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-831 > Project: Commons Collections > Issue Type: Improvement > Components: Collection >Affects Versions: 4.5 >Reporter: Claude Warren >Assignee: Claude Warren >Priority: Minor > Labels: bloom-filter > Original Estimate: 1h > Remaining Estimate: 1h > > In cases where a Bloom filter is set and then cleared it is more efficient to > clear the filter rather than dispose of it and create a new one. > Particularly for large filters in environments where GC can be an issue. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (COLLECTIONS-831) BloomFilter: add clear() method
Claude Warren created COLLECTIONS-831: - Summary: BloomFilter: add clear() method Key: COLLECTIONS-831 URL: https://issues.apache.org/jira/browse/COLLECTIONS-831 Project: Commons Collections Issue Type: Improvement Components: Collection Affects Versions: 4.5 Reporter: Claude Warren Assignee: Claude Warren In cases where a Bloom filter is set and then cleared it is more efficient to clear the filter rather than dispose of it and create a new one. Particularly for large filters in environments where GC can be an issue. -- This message was sent by Atlassian Jira (v8.20.10#820010)
