Jul 11, 2024 10:26:21 AM org.junit.platform.launcher.core.LauncherConfigurationParameters loadClasspathResource
WARNING: Discovered 2 'junit-platform.properties' configuration files in the classpath; only the first will be used.
Jul 11, 2024 10:26:21 AM org.junit.platform.launcher.core.LauncherConfigurationParameters loadClasspathResource
WARNING: Discovered 2 'junit-platform.properties' configuration files in the classpath; only the first will be used.

The files are coming from Apache Kafka:

  • jar:file:/Users/awilkinson/.gradle/caches/modules-2/files-2.1/org.apache.kafka/kafka-server-common/3.7.1/63fd797c55fcefb405bf975b5d764f0c84d19751/kafka-server-common-3.7.1-test.jar!/junit-platform.properties
  • jar:file:/Users/awilkinson/.gradle/caches/modules-2/files-2.1/org.apache.kafka/kafka-clients/3.7.1/f083d8a36936f1f380b87c2ad8f7e2f5b04ea8f0/kafka-clients-3.7.1-test.jar!/junit-platform.properties

The dependencies on test artifacts are coming from spring-kafka-test. The kafka-clients-3.7.1-test dependency is needed at runtime but kafka-server-common-3.7.1-test doesn't appear to be needed for Boot's own Kafka-related tests at least. Perhaps spring-kafka-test can drop its kafka-server-common-3.7.1-test dependency?

Having only the kafka-clients-3.7.1-test test dependency will address the warning but it will leave our unit tests running using the custom properties that kafka-clients-3.7.1-test defines which is not ideal. I've opened KAFKA-17121 to see if this can be addressed at source. In the meantime, we may be able to exclude the kafka-server-common-3.7.1-test in Boot's build and then hopefully remove the exclusion once a change has been made in Kafka (ideally) or in Spring Kafka.

Comment From: 72wildcard

Hey,

Quick question, currently migrating from spring-boot 3.2.6 to 3.4.1. Still experiencing the same behaviour, although this ticket was closed mentioning 3.3.2.

3-junit-platform-properties

Any thoughts?

Comment From: philwebb

@72wildcard It's hard to tell from the logs alone, perhaps you're not using our parent POM? If you'd like us to spend some time investigating, please open a new issue and provide a complete minimal sample (something that we can unzip or git clone, build, and deploy) that reproduces the problem.

Comment From: wilkinsona

Until this is fixed in Kafka, this is a problem that users will either have to live with or address themselves by excluding dependencies. The latter may not be possible, depending on how those dependencies are being used which is why we can't do anything for users in Boot itself.

Comment From: BertKoor

I've put some effort in creating an example project for this issue with some basic docs and an ability to test for it: https://github.com/BertKoor/springboot-kafkatest-demo

While doing that, I noticed that this issue will likely be fixed with SpringBoot 3.5. The ultimate fix is an upgrade of Apache Kafka to version 3.9.0, which had been committed today (see https://github.com/spring-projects/spring-boot/issues/43676 )

Is it possible to include this in a 3.4.x release of SpringBoot, or is that Kafka upgrade a too big leap forward?

@72wildcard : yes, I can confirm this is your issue.

Comment From: 72wildcard

Hi @BertKoor thanks for your work. I just returned from holidays and you saved me some hours. Cheers

Comment From: wilkinsona

Is it possible to include this in a 3.4.x release of SpringBoot, or is that Kafka upgrade a too big leap forward?

The latter. We won't move to a new minor release of Kafka in a maintenance release of Spring Boot.