Le mer. 22 juil. 2020 à 17:19, Gary Gregory <garydgreg...@gmail.com> a écrit : > > On Wed, Jul 22, 2020 at 11:02 AM Gilles Sadowski <gillese...@gmail.com> > wrote: > > > Hello. > > > > What's this flood of emails about? > > > > Just read them!
I did a couple, and this is not really helpful: ---CUT--- dependabot[bot] opened a new pull request #11: URL: https://github.com/apache/commons-logging/pull/11 Bumps [junit](https://github.com/junit-team/junit4) from 3.8.1 to 4.13. <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/junit-team/junit4/releases";>junit's releases</a>.</em></p> <blockquote> <h2>JUnit 4.13</h2> <p>Please refer to the <a href="https://github.com/junit-team/junit/blob/HEAD/doc/ReleaseNotes4.13.md";>release notes</a> for details.</p> <h2>JUnit 4.13 RC 2</h2> <p>Please refer to the <a href="https://github.com/junit-team/junit4/wiki/4.13-Release-Notes";>release notes</a> for details.</p> <h2>JUnit 4.13 RC 1</h2> <p>Please refer to the <a href="https://github.com/junit-team/junit4/wiki/4.13-Release-Notes";>release notes</a> for details.</p> <h2>JUnit 4.13 Beta 3</h2> <p>Please refer to the <a href="https://github.com/junit-team/junit4/wiki/4.13-Release-Notes";>release notes</a> for details.</p> <h2>JUnit 4.13 Beta 2</h2> <p>Please refer to the <a href="https://github.com/junit-team/junit4/wiki/4.13-Release-Notes";>release notes</a> for details.</p> <h2>JUnit 4.13 Beta 1</h2> <p>Please refer to the <a href="https://github.com/junit-team/junit4/wiki/4.13-Release-Notes";>release notes</a> for details.</p> <h2>JUnit 4.12</h2> <p>Please refer to the <a href="https://github.com/junit-team/junit/blob/HEAD/doc/ReleaseNotes4.12.md";>release notes</a> for details.</p> <h2>JUnit 4.12 Beta 3</h2> <p>Please refer to the <a href="https://github.com/junit-team/junit/blob/HEAD/doc/ReleaseNotes4.12.md";>release notes</a> for details.</p> <h2>JUnit 4.12 Beta 2</h2> <p>No release notes provided.</p> <h2>JUnit 4.12 Beta 1</h2> <p>No release notes provided.</p> <h2>JUnit 4.11</h2> <p>No release notes provided.</p> </blockquote> </details> <details> <summary>Changelog</summary> <p><em>Sourced from <a href="https://github.com/junit-team/junit4/blob/main/doc/ReleaseNotes4.13.md";>junit's changelog</a>.</em></p> <blockquote> <h2>Summary of changes in version 4.13</h2> <h1>Assertions</h1> <h3>[Pull request <a href="https://github-redirect.dependabot.com/junit-team/junit4/issues/1054";>#1054</a>:](<a href="https://github-redirect.dependabot.com/junit-team/junit/pull/1054";>junit-team/junit#1054</a>) Improved error message for <code>assertArrayEquals</code> when multi-dimensional arrays have different lengths</h3> <p>Previously, JUnit's assertion error message would indicate only that some array lengths <em>x</em> and <em>y</em> were unequal, without indicating whether this pertained to the outer array or some nested array. Now, in case of a length mismatch between two nested arrays, JUnit will tell at which indices they reside.</p> <h3>[Pull request <a href="https://github-redirect.dependabot.com/junit-team/junit4/issues/1154";>#1154</a>](<a href="https://github-redirect.dependabot.com/junit-team/junit/pull/1154";>junit-team/junit#1154</a>) and <a href="https://github-redirect.dependabot.com/junit-team/junit/pull/1504";>#1504</a> Add <code>assertThrows</code></h3> <p>The <code>Assert</code> class now includes methods that can assert that a given function call (specified, for instance, as a lambda expression or method reference) results in a particular type of exception being thrown. In addition it returns the exception that was thrown, so that further assertions can be made (e.g. to verify that the message and cause are correct).</p> <h3>[Pull request <a href="https://github-redirect.dependabot.com/junit-team/junit4/issues/1300";>#1300</a>:](<a href="https://github-redirect.dependabot.com/junit-team/junit/pull/1300";>junit-team/junit#1300</a>) Show contents of actual array when array lengths differ</h3> <p>Previously, when comparing two arrays which differ in length, <code>assertArrayEquals()</code> would only report that they differ in length. Now, it does the usual array comparison even when arrays differ in length, producing a failure message which combines the difference in length and the first difference in content. Where the content is another array, it is described by its type and length.</p> <h3>[Pull request <a href="https://github-redirect.dependabot.com/junit-team/junit4/issues/1315";>#1315</a>:](<a href="https://github-redirect.dependabot.com/junit-team/junit4/pull/1315";>junit-team/junit4#1315</a>) <code>assertArrayEquals</code> shouldn't throw an NPE when test suites are compiled/run across versions of junit</h3> <p>A redundant field, <code>fCause</code>, was removed on v4.12, and was seemingly harmless because <code>Throwable#initCause()</code> could directly initialize <code>cause</code> in the constructor. Unfortunately, this backwards incompatible change got aggravated when a test class, compiled with the latest (4.12+), ran with an older version that depended on fCause when building the assertion message<!-- raw HTML omitted --><a href="https://github.com/junit-team/junit4/blob/main/doc/#1315-f1";>1</a><!-- raw HTML omitted -->.</p> <p>This change adds back <code>fCause</code>, and overrides <code>getCause()</code> to handle forward compatibility<!-- raw HTML omitted --><a href="https://github.com/junit-team/junit4/blob/main/doc/#1315-f2";>2</a><!-- raw HTML omitted -->.</p> <p>To ensure serializability of further changes in <code>ArrayAssertionFailure</code> (until excising these fields by a major rev), a unit test now runs against v4.11, v4.12 failures, asserting around <code>#toString/getCause()</code>.</p> <p><!-- raw HTML omitted -->[1]<!-- raw HTML omitted --> [Issue <a href="https://github-redirect.dependabot.com/junit-team/junit4/issues/1178";>#1178</a>](<a href="https://github-redirect.dependabot.com/junit-team/junit4/issues/1178";>junit-team/junit4#1178</a>) details a particular case where gradle v2.2 is packaged with junit v4.11 and is used on running a test, generating test reports, despite specifying a particular version of junit (users would specify v4.12, or v4.+) in the test compile dependencies).</p> <p><!-- raw HTML omitted -->[2]<!-- raw HTML omitted --> <a href="https://github-redirect.dependabot.com/junit-team/junit4/pull/1315#issuecomment-222905229";>Case</a> if the test class is compiled with <= v4.11, where only <code>fCause</code> is initialized and not <code>Throwable#cause</code>, it can now fallback to the field, <code>fCause</code>, when building the message.</p> <h3>[Pull request <a href="https://github-redirect.dependabot.com/junit-team/junit4/issues/1150";>#1150</a>:](<a href="https://github-redirect.dependabot.com/junit-team/junit4/pull/1150";>junit-team/junit4#1150</a>) Deprecate <code>Assert#assertThat</code></h3> <p>The method <code>assertThat</code> is used for writing assertions with Hamcrest. Hamcrest is an independent assertion library and contains an own <code>assertThat</code> method in the class <code>org.hamcrest.MatcherAssert</code>. It is available both in the old Hamcrest 1.3 release and in the current Hamcrest 2.1. Therefore the JUnit team recommends to use Hamcrest's own <code>assertThat</code> directly.</p> <h1>Test Runners</h1> <h3>[Pull request <a href="https://github-redirect.dependabot.com/junit-team/junit4/issues/1037";>#1037</a>:](<a href="https://github-redirect.dependabot.com/junit-team/junit/pull/1037";>junit-team/junit#1037</a>) <code>BlockJUnit4ClassRunner#createTest</code> now accepts <code>FrameworkMethod</code></h3> <p>Subclasses of <code>BlockJUnit4ClassRunner</code> can now produce a custom test object based on the <code>FrameworkMethod</code> test being executed by implementing the new <code>createTest(FrameworkMethod)</code> method. The default implementation calls the existing <code>createTest()</code> method.</p> <h3>[Pull request <a href="https://github-redirect.dependabot.com/junit-team/junit4/issues/1082";>#1082</a>](<a href="https://github-redirect.dependabot.com/junit-team/junit/pull/1082";>junit-team/junit#1082</a>): Ensure exceptions from <code>BlockJUnit4ClassRunner.methodBlock()</code> don't result in unrooted tests</h3> <p>The introduction of the <code>runLeaf()</code> method in <code>BlockJUnit4ClassRunner</code> in JUnit 4.9 introduced a regression with regard to exception handling. Specifically, in JUnit 4.9 through 4.12 the invocation of <code>methodBlock()</code> is no longer executed within a try-catch block as was the case in previous versions of JUnit. Custom modifications to <code>methodBlock()</code> or the methods it invokes may in fact throw exceptions, and such exceptions cause the current test execution to abort immediately. As a result, the failing test method is unrooted in test reports, and subsequent test methods are never invoked. Furthermore, any <code>RunListener</code> registered with JUnit is not notified.</p> <p>As of JUnit 4.13, the invocation of <code>methodBlock()</code> is once again wrapped within a try-catch block. If an exception is <em>not</em> thrown, the resulting <code>Statement</code> is passed to <code>runLeaf()</code>. If an exception <em>is</em> thrown, it is wrapped in a <code>Fail</code> statement which is passed to <code>runLeaf()</code>.</p> <h3>[Pull request <a href="https://github-redirect.dependabot.com/junit-team/junit4/issues/1286";>#1286</a>](<a href="https://github-redirect.dependabot.com/junit-team/junit/pull/1286";>junit-team/junit#1286</a>): Provide better feedback to the user in case of invalid test classes</h3> <p>Only one exception per invalid test class is now thrown, rather than one per validation error. The message of the exception includes all of the validation errors.</p> <p>Example:</p> <!-- raw HTML omitted --> </blockquote> </details> <details> <summary>Commits</summary> <ul> <li>See full diff in <a href="https://github.com/junit-team/junit4/commits/r4.13";>compare view</a></li> </ul> </details> <br /> [](https://help.github.com/articles/configuring-automated-security-fixes) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- <details> <summary>Dependabot commands and options</summary> <br /> You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) </details> ---CUT--- If this is meant to be read rendered on GitHub, I humbly request that we set up additional mailing lists so that those subscribed to issues@ can be spared the unrendered clutter. Thanks, Gilles > > Gary > > > > > > Gilles > > > > Le mer. 22 juil. 2020 à 16:35, Rob Tompkins <chtom...@gmail.com> a écrit : > > > > > > I’m happy to merge them….will get to them by tomorrow morning ok? > > > > > > -Rob > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
