New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
spring-issuemaster opened this Issue Jun 2, 2018 · 3 comments

Comments

Projects
None yet
2 participants
@spring-issuemaster
Copy link
Collaborator

spring-issuemaster commented Jun 2, 2018

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-issuemaster

This comment has been minimized.

Copy link
Collaborator

spring-issuemaster commented Jun 4, 2018

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-issuemaster

This comment has been minimized.

Copy link
Collaborator

spring-issuemaster commented Jun 5, 2018

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-issuemaster

This comment has been minimized.

Copy link
Collaborator

spring-issuemaster commented Jun 8, 2018

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment