This message was deleted.

I have asked my self the same thing for

api

and in a small test I did, it seemed to work: the platform was also used for dependency resolution of dependencies added to

api

But I didn't find any documentation about it either.

Hi, check https://docs.gradle.org/current/userguide/java_plugin.html#sec:java_plugin_and_dependency_management (Fig. 3) and https://docs.gradle.org/current/userguide/java_library_plugin.html#sec:java_library_configurations_graph for a view of the hierarchy of configurations. Afaik a platform added to a configuration is inherited to the configurations extending from it. So in this case a platform applied to

implementation

also applies to

testImplementation

But this wouldn't explain why a platform applied to

implementation

also applies to

api

, so I think there might be a bit more happening

api

itself might not be resolved itself at runtime, but rather

compileClasspath

/`runtimeClasspath` - which would see the platform from

implementation

. But I might be wrong about that...

btw, is there any reason to use

io.spring.dependency-management

if using

enforcedPlatform

? It seems they have same purpose.

Have a look here for potential reasons to keep using the dependency-management plugin

We recently switched from

io.spring.dependency-management

to using platforms, no looking back. I wouldn't mix both...

While the Spring folks' point in the issue about convenience of simple version override for the dependency groups still stands (even if we found it not a serious issue for us) performance degradation on resolving somewhat a hundred detached configurations in a simple project is a strong point against using the plugin.