Generated poms have a dependenciesManagement section with bom import [SPR-16893]

[spring-projects-issues]

Stéphane Nicoll opened SPR-16893 and commented

Generated pom from the Gradle build have a dependencyManagement section with bom imports for reactor and netty. Those shouldn't be there at all

For example: http://repo1.maven.org/maven2/org/springframework/spring-websocket/5.0.0.RELEASE/spring-websocket-5.0.0.RELEASE.pom

---

Affects: 5.0 GA

Referenced from: commits afcc430, 417354d

[spring-projects-issues]

Brian Clozel commented

Stéphane Nicoll, it's a mistake on my part. I didn't change the defaults of the dependency-management-plugin. It's including by default the dependency management declaration in the resulting POM. We can change that with an option that disables the POM customization altogether. Doing so removes the dependency management section, so it leaves the dependencies without a version tag.

I guess we'd need to programatically access the managed versions and add that information back in the POM. Andy Wilkinson, is that the preferred way of achieving that?

That being said, this is just one of the issues with our generated POMs:

• we're excluding jcl-over-slf4j from all configurations and this shows up in every dependency
• publishing the optional dependencies brings little value (the version listed is often the last compatible one, no so version range information); I'd be in favor of removing all that from the generated POMs, since they provide little value to developers and end up generating false positives in security tools checking for CVEs in dependencies
• the dependency management is applied locally to each project, I'm wondering if we should apply that as a cross-cutting concern on a reduced list of projects, in the main build file

 

[spring-projects-issues]

Stéphane Nicoll commented

Thanks for the feedback. I am not keen to remove optional dependencies, I'd argue that the POM should reflect exactly what was required to build the project (and knowing that a given module has optional support for xyz is quite important IMO).

[spring-projects-issues]

Andy Wilkinson commented

Yes, with the plugin's current functionality, writing your own pom customisation that programmatically accesses the managed version is the way I'd recommend doing this. We could also consider an enhancement to the plugin that offers this out-of-the-box as an alternative form of pom customisation.