according to the reference docs groovy-cli-picocli is a managed dependency, however picocli itself is not, as I use picocli without groovy it would be nice if this were managed. Of course if you actually do this, then you might also want to include the official spring-boot-starter-picocli
Comment From: philwebb
I have a feeling we're only picking up groovy-cli-picocli because it's in the groovy-bom. Generally speaking we only provide managed dependencies when we offer auto-configuration for a library. I don't think we actually offer any picocli support directly ourselves.
Flagging for team-attention to see if we think should make an exception for picocli since we're already offering groovy-cli-picocli.
Comment From: snicoll
according to the reference docs groovy-cli-picocli is a managed dependency
The only reason it is managed is because Groovy has a module with that name and we import its bom. Given that we don't have any use of picocli ourselves, I don't think we should manage it.
Of course if you actually do this, then you might also want to include the official spring-boot-starter-picocli
I assume you meant picocli-spring-boot-starter. We can't do that as it would create a cycle between picocli and Spring Boot.
Comment From: wilkinsona
In the past, the only times that we have made an exception is to resolve a dependency convergence problem. Over the years, that's given us a consistent policy to apply and has ensured that the scope of our dependency management hasn't been so large that it has become unmaintainable. If we made an exception for Picocli, it would be inconsistent as there's no dependency convergence problem to solve. The alternative would be to change our policy and to start managing the dependencies of modules that we already manage. This would result in a large increase in the dependency management's scope, beyond the point where it becomes unmaintainable.
For these reasons, I don't think we should add dependency management for Picocli. Thanks anyway for the suggestion.