Vladimir Sitnikov

Oh. However, someone (in their enterprise app) might still use Futures (e.g. for their do it yourself concurrency). In that case, BlockHound might spot that the app is using an...

What if keep extensions as is, but add extra `@Option` to the task itself? I guess adjusting `failBuildOnCVSS` on the fly (e.g. for exploratory purposes) is quite a common use...

What if the failure was delayed till the execution time?

The typical Java approach is to have an interface and multiple implementations: junit4, junit5. The problem is that junit4 forces interface to extend junit4-related class, so it forbids the idea...

Does JUnit have a separate API-only jar so TestRule "API" can be used without bringing full JUnit to the classpath and without clients having multiple @Test annotations?

> JUnit4 does not have API jars. That is why it is really sad to suppose that `TestRule` interface is API that every client must implement. There are annotations (e.g....

@kcooney , the fix at junit4 side is trivial (see https://github.com/junit-team/junit4/pull/1721), and the "solutions" of shading junit4 or making extra artifacts would be non-trivial, especially when it comes to licensing...

One of the sad consequences of `TestRule` in the field type is that `TestRule` methods appear in autocomplete for the end-users even though the end-users should never call `TestRule` methods...

```java @Rule TestRule rule = new TestcontainersRule(); ``` ^^ This is sad because uses might try calling methods on `rule` object :)

Technically speaking, you can disable staging behavior via extension property: https://github.com/gradle-nexus/publish-plugin/blob/0aea95597e2eeaf9275a286254894bad29b3d1e1/src/main/kotlin/io/github/gradlenexus/publishplugin/NexusPublishExtension.kt#L33