[GitHub] commons-lang pull request #375: JUnit Jupiter migration completion
Github user asfgit closed the pull request at: https://github.com/apache/commons-lang/pull/375 ---
[GitHub] commons-lang issue #375: JUnit Jupiter migration completion
Github user PascalSchumacher commented on the issue: https://github.com/apache/commons-lang/pull/375 Thank you very much for this massive effort! ð ---
[GitHub] commons-lang issue #375: JUnit Jupiter migration completion
Github user coveralls commented on the issue: https://github.com/apache/commons-lang/pull/375 [](https://coveralls.io/builds/19476871) Coverage increased (+0.007%) to 95.253% when pulling **8577320ae8d120eea3c11b44b8a71668f5d555ad on mureinik:junit-jupiter** into **ca2e59c513edc2a8b30ff62595e01f8dff79f0d2 on apache:master**. ---
[GitHub] commons-lang pull request #375: JUnit Jupiter migration completion
GitHub user mureinik opened a pull request: https://github.com/apache/commons-lang/pull/375 JUnit Jupiter migration completion This patch finalizes the upgrade of commons-lang's tests to use JUnit Jupiter and removes the Vintage Engine dependency entirely. While most of these changes are drop-in replacements with no functional benefit, there are some non-obvious changes worth mentioning. Unlike `org.junit.Assert.assertEquals(double, double, double)`, `org.junit.jupiter.api.Assertions.assertEquals(double, double, double)` does not support deltas of zero, only strictly positive deltas. This issue will be addressed in JUnit Jupiter 5.4 (see https://github.com/junit-team/junit5/pull/1613 for details). In the meanwhile, `assertTrue(expected==actual)` was used, and `TODO` comments were placed in the code to refactor it to assertEquals once JUnit 5.4 is available. Unlike `org.junit.Test`, `org.junit.jupiter.api.Test` does not have an `expected` argument. Instead, an explicit call to `org.junit.jupiter.api.Assertions.assertThrows` is used. Unlike `org.junit.Test`, `org.junit.jupiter.api.Test` does not have a `timeout` argument either. Instead, an explicit call to `org.junit.jupiter.api.Assertions.assertTimeoutPreemptively` is used. JUnit Jupiter also no longer has the concept of Rules. Usages of the `SystemDefaultsSwitch` rule and its accompanying annotates were replaced with the `@DefaultLocale` annotation that @britter contributed to JUnit Pioneer, the semi-official JUnit extension project, or simply removed entirely where they had no use (i.e., from `StringUtilsEqulasIndexOfTest`). Following the removal of their usages, the `@SystemDefaults` annotation, the `SystemDefaultsSwitch` rule and the `SystemDefaultsSwitchTest` class that tests them had no more use, and they were removed entirely. It's also worth noting this is a minimal patch for migrating the package's tests to Jupiter. There are several tests that can be made more elegant with Jupiter's new features, but that work is left for subsequent patches. You can merge this pull request into a Git repository by running: $ git pull https://github.com/mureinik/commons-lang junit-jupiter Alternatively you can review and apply these changes as the patch at: https://github.com/apache/commons-lang/pull/375.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #375 commit 57fbe7e96eec45507dcbe030c3d9ea975f33342f Author: Allon Mureinik Date: 2018-10-11T13:21:52Z StringUtilsEqulasIndexOfTest @Rules Commit 0223a4 removed all the usages of @SystemDefaults annotations from this test, but left behind a pointless SystemDefaultsSwitch rule. This patch finishes the job and removes this unused rule. commit 9a3e1d743bc4c8563cf71c521b4d392e302dfbc6 Author: Allon Mureinik Date: 2018-10-02T03:41:37Z Update tests to JUnit Jupiter This patch finalizes the upgrade of commons-lang's tests to use JUnit Jupiter and remove the Vintage Engine dependency entirely. While most of these changes are drop-in replacements with no functional benefit, there are some non-obvious changes worth mentioning. Unlike org.junit.Assert.assertEquals(double, double, double), org.junit.jupiter.api.Assertions.assertEquals(double, double, double) does not support deltas of zero, only strictly positive deltas. This issue will be addressed in JUnit Jupiter 5.4 (see https://github.com/junit-team/junit5/pull/1613 for details). In the meanwhile, assertTrue(expected==actual) was used, and TODO comments were placed in the code to refactor it to assertEquals once JUnit 5.4 is available. Unlike org.junit.Test, org.junit.jupiter.api.Test does not have an "expected" argument. Instead, an explicit call to org.junit.jupiter.api.Assertions.assertThrows is used. Unlike org.junit.Test, org.junit.jupiter.api.Test does not have a "timeout" argument either. Instead, an explicit call to org.junit.jupiter.api.Assertions.assertTimeoutPreemptively is used. JUnit Jupiter also no longer has the concept of Rules. Usages of the SystemDefaultsSwitch rule and its accompanying annotates were replaced with the @DefaultLocale annotation that Benedikt Ritter contributed to JUnit Pioneer, the semi-official JUnit extension project. Following the removal of their usages, the SystemDefaults annotation, the SystemDefaultsSwitch rule and the SystemDefaultsSwitchTest class that tests them had no more use, and they were removed entirely. It's also worth noting this is a minimal patch for migrating the package's tests to Jupiter. There are several tests that can be made more elegant with Jupiter's new features, but that work is left for subsequent patches.
[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=16646934#comment-16646934 ] Thomas P commented on CLI-285: -- In my view the object mane _OptionGroup_ is missleading and I'd rather concider a group of options to depend on each other. But for the time being that's what we have. I suggest to call the new Feature an *OptionList* which can be added to an _OptionGroup._ I'd also volonteer to implement that. > 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 (v7.6.3#76005)
[jira] [Commented] (MATH-1471) BicubicInterpolatingFunction not interpolating correctly for non discrete y value
[ https://issues.apache.org/jira/browse/MATH-1471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16646858#comment-16646858 ] Gilles commented on MATH-1471: -- bq. interpolating function returned returns the same result for variations in the estimated y value. Thanks a lot for the report. Could you please set up a unit test that demonstrates the bug, in the form of a patch (or "pull request") against the development version (i.e. the code in the "master" branch of the repository)? A fix would also be welcome. :) > BicubicInterpolatingFunction not interpolating correctly for non discrete y > value > - > > Key: MATH-1471 > URL: https://issues.apache.org/jira/browse/MATH-1471 > Project: Commons Math > Issue Type: Bug >Affects Versions: 3.6.1 > Environment: JDK 1.8.0_181 >Reporter: Thomas Swinicki >Priority: Major > > Upon performing a bicubic interpolation with two point (x0, y0) and (x1, y1), > the returned bicubic interpolating function returned returns the same result > for variations in the estimated y value. > For example, my inputs are (20, 20) and (25, 25) with f(20, 20) = 64 and > f(25, 25) = 6468. > When I get the bicubic interpolating function for this and vary the estimated > x, it works fine. For (21, 20), the function returns 730.016. When I input > (20, 21), the function returns 64, which is f(20, 20). For any y value in > between 20 and 25, the result is 64. This is the case for any function for > which the y estimate is different from the value on the points. > In other instances, it is varying x values that result in the same result > while varying y estimates seem to work as expected. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MATH-1471) BicubicInterpolatingFunction not interpolating correctly for non discrete y value
[ https://issues.apache.org/jira/browse/MATH-1471?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Swinicki updated MATH-1471: -- Description: Upon performing a bicubic interpolation with two point (x0, y0) and (x1, y1), the returned bicubic interpolating function returned returns the same result for variations in the estimated y value. For example, my inputs are (20, 20) and (25, 25) with f(20, 20) = 64 and f(25, 25) = 6468. When I get the bicubic interpolating function for this and vary the estimated x, it works fine. For (21, 20), the function returns 730.016. When I input (20, 21), the function returns 64, which is f(20, 20). For any y value in between 20 and 25, the result is 64. This is the case for any function for which the y estimate is different from the value on the points. In other instances, it is varying x values that result in the same result while varying y estimates seem to work as expected. was: Upon performing a bicubic interpolation with two point (x0, y0) and (x1, y1), the returned bicubic interpolating function returned returns the same result for variations in the estimated y value. For example, my inputs are (20, 20) and (25, 25) with f(20, 20) = 64 and f(25, 25) = 6468. When I get the bicubic interpolating function for this and vary the estimated x, it works fine. For (21, 20), the function returns 730.016. When I input (20, 21), the function returns 64, which is f(20, 20). For any y value in between 20 and 25, the result is 64. This is the case for any function for which the y estimate is different from the value on the points. > BicubicInterpolatingFunction not interpolating correctly for non discrete y > value > - > > Key: MATH-1471 > URL: https://issues.apache.org/jira/browse/MATH-1471 > Project: Commons Math > Issue Type: Bug >Affects Versions: 3.6.1 > Environment: JDK 1.8.0_181 >Reporter: Thomas Swinicki >Priority: Major > > Upon performing a bicubic interpolation with two point (x0, y0) and (x1, y1), > the returned bicubic interpolating function returned returns the same result > for variations in the estimated y value. > For example, my inputs are (20, 20) and (25, 25) with f(20, 20) = 64 and > f(25, 25) = 6468. > When I get the bicubic interpolating function for this and vary the estimated > x, it works fine. For (21, 20), the function returns 730.016. When I input > (20, 21), the function returns 64, which is f(20, 20). For any y value in > between 20 and 25, the result is 64. This is the case for any function for > which the y estimate is different from the value on the points. > In other instances, it is varying x values that result in the same result > while varying y estimates seem to work as expected. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (MATH-1471) BicubicInterpolatingFunction not interpolating correctly for non discrete y value
Thomas Swinicki created MATH-1471: - Summary: BicubicInterpolatingFunction not interpolating correctly for non discrete y value Key: MATH-1471 URL: https://issues.apache.org/jira/browse/MATH-1471 Project: Commons Math Issue Type: Bug Affects Versions: 3.6.1 Environment: JDK 1.8.0_181 Reporter: Thomas Swinicki Upon performing a bicubic interpolation with two point (x0, y0) and (x1, y1), the returned bicubic interpolating function returned returns the same result for variations in the estimated y value. For example, my inputs are (20, 20) and (25, 25) with f(20, 20) = 64 and f(25, 25) = 6468. When I get the bicubic interpolating function for this and vary the estimated x, it works fine. For (21, 20), the function returns 730.016. When I input (20, 21), the function returns 64, which is f(20, 20). For any y value in between 20 and 25, the result is 64. This is the case for any function for which the y estimate is different from the value on the points. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IO-588) IOUtils.writeLines() should accept an Iterable<>
Laurent Martelli created IO-588: --- Summary: IOUtils.writeLines() should accept an Iterable<> Key: IO-588 URL: https://issues.apache.org/jira/browse/IO-588 Project: Commons IO Issue Type: Improvement Components: Utilities Affects Versions: 2.6 Reporter: Laurent Martelli Attachments: ioutils.diff IOUtils.writeLines() methods should accept an Iterable<> instead of a Collection<>, since it does not use any method of Collection. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (NUMBERS-77) Move utilities from "Commons Geometry"
Gilles created NUMBERS-77: - Summary: Move utilities from "Commons Geometry" Key: NUMBERS-77 URL: https://issues.apache.org/jira/browse/NUMBERS-77 Project: Commons Numbers Issue Type: Task Reporter: Gilles Fix For: 1.0 "Commons Geometry" defines utilities that would be a better fit in this component. Duplication of general-purpose codes should be avoided, in order to benefit from consolidated usage (bug reporting, performance enhancements, ...). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IMAGING-183) Error while reading Canon CR2 (RAW) image metadata: Can't find rows per strip field.
[
https://issues.apache.org/jira/browse/IMAGING-183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16646454#comment-16646454
]
Adalberto Gonzaga commented on IMAGING-183:
---
Hello [~kinow], sorry for taking too long to answer...
There are some files which I shared through [this
link|https://drive.google.com/open?id=17TVesXbXVkn_6oKY1rCnJDa4-BQsZkt6].
Please take a look at the {{.CR2}} file.
> Error while reading Canon CR2 (RAW) image metadata: Can't find rows per strip
> field.
>
>
> Key: IMAGING-183
> URL: https://issues.apache.org/jira/browse/IMAGING-183
> Project: Commons Imaging
> Issue Type: Bug
> Components: Format: TIFF
>Affects Versions: 0.97
>Reporter: Adalberto Gonzaga
>Priority: Minor
>
> When trying to extract some metadata from a Canon CR2 (RAW) image file, it
> thrown an exception when calling the getMetadata() method:
> org.apache.sanselan.ImageReadException: Can't find rows per strip field.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
