Hi all - when using the `kotlin-maven-plugin`, is ...

# build-tools

[Rob Elliot]

Hi all - when using the kotlin-maven-plugin, is there a way to exclude a dependency from the test compile classpath?

Context - I’m migrating a project from JUnit 4 to JUnit 5. But it uses testcontainers, which has a transitive dependency on JUnit 4. It’s really easy to accidentally use JUnit 4 annotations, and then find your tests aren’t running… I’d like to exclude JUnit 4 from the test compile classpath so that if you do so you find out fast.

Maven doesn’t distinguish between compile & runtime for test scope (why not?!) so I can’t just drop it down to be a runtime scoped dependency.

I could exclude it as a dependency of testcontainers, but:
a) that would exclude it from the runtime classpath, and testcontainers probably needs it
b) the odds are some other dependency will bring it in, now or later… playing whack-a-mole like that is zero fun

(Yes it would be easy in Gradle. No I’m not up for having that fight now.)

[hho]

Why would testcontainers need it at runtime, if you don't want to run JUnit 4 stuff? I'd try excluding it… 🤷‍♂️

[Rob Elliot]

GenericContainer implements org.junit.rules.TestRule. I’m fairly sure the JVM will fail trying to load a class where some of the supertypes are not on the runtime classpath.

[hho]

OK, if it's so tightly coupled, I guess the problem is testcontainers – not Maven.

[Rob Elliot]

It’s both. If maven allowed distinguishing between the compile & runtime classpath for tests then I could make JUnit 4 runtime scoped, which would stop anyone accidentally compiling against JUnit 4.

[Rob Elliot]

It’s a question about the kotlin-maven-plugin, in the hope that the kotlin-maven-plugin has a way to modify the compile time classpath. In what possible way is that NOT KOTLIN?

[hho]

Maven assembles the classpaths, nothing Kotlin specific here.

[Rob Elliot]

I know that. I was asking about a possible backdoor in the kotlin-maven-plugin to alter the classpath.