An alternative approach could be to remove the randomness from the test by
using a predefined random seed and test the overloaded variants that accept
a second java.util.Random argument. This will superficially reduce the
test's coverage, but it does have a reliability advantage, IMHO (as seen in
O
Thanks, Stian!
Gilles
On Wed, 28 Feb 2018 00:03:00 + (UTC), Stian Soiland-Reyes (JIRA)
wrote:
Stian Soiland-Reyes created COMMONSSITE-103:
---
Summary: GSOC: Apache Commons bug bounty
Key: COMMONSSITE-103
Commons folks,
I've added a general GSOC catch-all bug-hunt idea
at https://issues.apache.org/jira/browse/COMMONSSITE-103
(Hope it's OK that Alice used Commons Crypto as example!)
but feel free to add more specific ideas in Jira using gsoc2018 label
and link it to that issue.
Note that we stil
Of course... but how would test then? Shuffle N times and accept a % of
non-shuffles?
Gary
On Tue, Feb 27, 2018, 13:18 Allon Mureinik wrote:
> There will still be a chance, however infinitesimal, of a failure. :-)
>
>
> On Tue, Feb 27, 2018 at 9:02 PM, Gary Gregory
> wrote:
>
> > Why not make
On 2018-02-27, Stefan Bodewig wrote:
> On 2018-02-27, Allison, Timothy B. wrote:
>>On TIKA-2591[0], a user reports that a specific type of TIFF is
>>being identified as a TAR file. Is this something we should try to
>>fix at the Tika level, or is this something that would be better
>
On 2018-02-27, Allison, Timothy B. wrote:
>On TIKA-2591[0], a user reports that a specific type of TIFF is
>being identified as a TAR file. Is this something we should try to
>fix at the Tika level, or is this something that would be better
>fixed in COMPRESS?
TAR auto-detection
There will still be a chance, however infinitesimal, of a failure. :-)
On Tue, Feb 27, 2018 at 9:02 PM, Gary Gregory
wrote:
> Why not make the array 1000 items long?
>
> Gary
>
> On Tue, Feb 27, 2018 at 10:31 AM, Allon Mureinik
> wrote:
>
> > All the ArrayUtilsTest#testShuffleXYZ tests take an
Why not make the array 1000 items long?
Gary
On Tue, Feb 27, 2018 at 10:31 AM, Allon Mureinik wrote:
> All the ArrayUtilsTest#testShuffleXYZ tests take an array, shuffle it, and
> assert that the result isn't equal to the original array.
> This is usually true, but there's a small chance that t
COMPRESS colleagues,
On TIKA-2591[0], a user reports that a specific type of TIFF is being
identified as a TAR file. Is this something we should try to fix at the Tika
level, or is this something that would be better fixed in COMPRESS?
Thank you!
Best,
Tim
[0]
All the ArrayUtilsTest#testShuffleXYZ tests take an array, shuffle it, and
assert that the result isn't equal to the original array.
This is usually true, but there's a small chance that the shuffled array
will be equal to the original array, and thus the test will fail. This
chance is higher for t
Note, this does pass in my personal travis:
https://travis-ci.org/ottobackwards/commons-lang/builds/346806991
On February 27, 2018 at 11:58:24, Otto Fowler (ottobackwa...@gmail.com)
wrote:
My PR is currently failing for java 9 on this test. Anyone have any idea
why?
[INFO] Running org.apache.c
My PR is currently failing for java 9 on this test. Anyone have any idea
why?
[INFO] Running org.apache.commons.lang3.ArrayUtilsTest
[ERROR] Tests run: 307, Failures: 1, Errors: 0, Skipped: 0, Time
elapsed: 0.114 s <<< FAILURE! - in
org.apache.commons.lang3.ArrayUtilsTest
[ERROR] testShuffleBoole
Thank you for the update Rob!
Gary
On Tue, Feb 27, 2018, 05:42 Rob Tompkins wrote:
> Hello all:
>
> Just to check in I’m still debugging the mechanics to get things working
> generally across multi-module builds as well as having the plugin not
> effect any breaking changes in the release proce
Hello all:
Just to check in I’m still debugging the mechanics to get things working
generally across multi-module builds as well as having the plugin not effect
any breaking changes in the release process upon up versioning into a parent
containing it. Just wanted to let folks know.
Cheers,
-R
14 matches
Mail list logo
