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.
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
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).
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.