I support a large number of SpringBoot services built with Maven. I recently noticed that one of our transient dependencies has a conflict with another transient dependency, as it has several FQCNs that are identical to ones in the second artifact, but with different content. In most of those services, the first artifact ended up in the classpath after the second artifact, so the "good" version of those classes was obtained from the second artifact.
In a couple of services, the order was reversed, causing fatal startup problems. I thought perhaps that if I moved the "top-level" dependency that references the transient artifact to the bottom of the dependencies list in the pom.xml, it might control where that transient artifact ends up in the classpath. This unfortunately had no effect. It's possible this has an effect on the ordering of the "top-level" dependencies, but it didn't do anything for the transient dependencies. I had thought that perhaps fixing this required changing the SpringBoot "classpath.idx" file that specifies the order that SpringBoot would load dependencies, so I created this issue: https://github.com/spring-projects/spring-boot/issues/37125 However, I think the responder is correct that the ordering in this file really should reflect the "Maven view" of dependency ordering. In the particular case where this came up, I have resolved the problem the only way available to me, which is simply editing the problematic jar, removing the FQCNs that are duplicates, and creating a new artifact that services will use instead of the original jar. This is obviously a hack, and might not be possible in other situations.
