[CODEC-285] Upgrade JUnit to 5.6.0

[nhojpatrick]

Handles https://issues.apache.org/jira/browse/CODEC-285

Also based upon https://issues.apache.org/jira/browse/CODEC-284 branch so pr #38

[coveralls]

Coverage remained the same at 93.976% when pulling 7012212 on nhojpatrick:CODEC-285 into e87ac43 on apache:master.

[aherbert]

When including multiple JUnit dependencies I would use the JUnit BOM in the dependency management to ensure they are kept in sync:

<dependency>
  <groupId>org.junit</groupId>
  <artifactId>junit-bom</artifactId>
  <version>X.Y.Z</version>
  <scope>import</scope>
  <type>pom</type>
</dependency>

I'd like to highlight that codec targets JDK 7. These changes to the build tools would prevent building on JDK 7. I'm fine with forcing JDK 8+ for the toolchain but Java 7 still has support until July 2022 and someone may care about this.

[garydgregory]

My preference would be for Codec to update to Java 8.

[nhojpatrick]

My preference would be for Codec to update to Java 8.

await another Jira/PR, I'm finding that for assertThrows i need lambdas and it would make it easier

[nhojpatrick]

When including multiple JUnit dependencies I would use the JUnit BOM in the dependency management to ensure they are kept in sync:

<dependency>
  <groupId>org.junit</groupId>
  <artifactId>junit-bom</artifactId>
  <version>X.Y.Z</version>
  <scope>import</scope>
  <type>pom</type>
</dependency>

I'd like to highlight that codec targets JDK 7. These changes to the build tools would prevent building on JDK 7. I'm fine with forcing JDK 8+ for the toolchain but Java 7 still has support until July 2022 and someone may care about this.

if i can upgrade all the tests quick enough, junit-vintage-engine will be going asap, so i would prefer to keep both separately defined so i can start moving tests from vintage to jupiter, then another future to drop junit-vintage-engine. i agree long term it would be better to define to keep in sync but depending how long the discussions are, depends how long you have duplicate definitions.

[garydgregory]

Git master is now on Java 8. It's confusing to have both JUnit 4 AND 5 on the classpath. It should be one or the other, and yes, it would be nice to update the whole component to JUnit 5.

[nhojpatrick]

@garydgregory It can be useful as your migrating from JUnit v4 to JUnit v5, otherwise is a bing bang. Take advantage of assertAll and assertThrows as that would work in JUnit v4 code.
Eventually all the JUnit v4 tests would be updated and you can remove that dependency.