Upgrade mockito now that the minimum Java is 11 on CI#247
Upgrade mockito now that the minimum Java is 11 on CI#247TWiStErRob wants to merge 1 commit intogradle-nexus:masterfrom
Conversation
| testImplementation("ru.lanwen.wiremock:wiremock-junit5:1.3.1") | ||
| testImplementation("org.assertj:assertj-core:3.24.2") | ||
| // This cannot be updated to 5.x as it requires Java 11, | ||
| // but we are running CI on Java 8 in .github/workflows/java-versions.yml. |
There was a problem hiding this comment.
(btw, shouldn't Java 8 CI still exist considering the target bytecode is 8?)
There was a problem hiding this comment.
We've dropped the Java 8 CI builds to speed up the process after #171 is applied. Java <11 is unsupported for building 2.0.0+ (and with that MR merged it will effectively be enforced), so I'm not sure, if we need it. We probably could have some "smoke tests" trying to execute Gradle build with Java 8 for the artifacts build and "released" with JDK 17, but it is also not supported, so we might wait for people to complaint about any runtime regression in their projects. WDYT?
There was a problem hiding this comment.
I think it would make sense to build using 17, and and target bytecode 8. Best of both worlds and the effort should be really low. Tests can still run on 11 or 17. I just queued up a similar PR in Mockito: TWiStErRob/mockito#1
There was a problem hiding this comment.
Anyway, for now since 8 is in a "dropped" state, I think this PR can go ahead. It should only affect unit tests. I guess compatTests don't use mocks?
|
As discussed with @TWiStErRob, it would be beneficial to have a possibility to build the project with JDK 17 and run functional tests with JDK 8 on CI server. However, it could be done in a separate PR. We could also think, if - to prevent some |
2 participants
Uh oh!
There was an error while loading. Please reload this page.