Вангую, что Junit5 и containter как-то связан с testcontainters

вот точно нет)

The ExecutionCondition extension API in JUnit Jupiter allows developers to either enable or disable a container or test based on certain conditions programmatically. The simplest example of such a condition is the built-in DisabledCondition which supports the @Disabled annotation (see Disabling Tests). In addition to @Disabled, JUnit Jupiter also supports several other annotation-based conditions in the org.junit.jupiter.api.condition package that allow developers to enable or disable containers and tests declaratively. When multiple ExecutionCondition extensions are registered, a container or test is disabled as soon as one of the conditions returns disabled.

Не похоже, чтобы дока нормально раскрывала это понятие

контейнер это же по сути test class (как одна из разновидностей), параметризованный тест

где вот эти 8%, которые могут объяснить?)

в гредле с ними уже давно вроде бы все норм

Емнип jupiter позволяет делать произвольную вложенность этих контейнеров вплоть до их динамического определения. Из обычных способов -- test class, nested test class

В моём понимании "всё норм" - это когда надо прописывать зависимость в одном месте, а не в build.gradle и module-info.java. Это так?

там же фишка не только в зависимостях но еще и то, что ты можешь декларировать, что можно из твоего модуля свободно юзать, а что нет

Ну да, но импорты-то тоже надо прописывать

ну не сказал бы что это прям проблема

тоже самое что и с осги было

когда работаешь с джава модулями, к гредлу надо относится как к "выкачивальщику" зависимостей из внешнего мира

и складываюни их так что бы можно было бы собрать уже норм артефакт

выкачивальщик зависимостей это mvn, а использовать gradle это как забивать гвозди кувалдой, имхо

все-таки функционал там в разы шире

даже для такой простой задачи, мавен выглядет вырвиглазно )

так что сам юзай )