malliaridis commented on PR #2915: URL: https://github.com/apache/solr/pull/2915#issuecomment-2560092738
> SolrJ depends on "api" module too; so does this mean we unwittingly add dependencies for SolrJ users which they previously didn't have? We have to distinguish between constraints and actual dependencies. This new platform module adds constraints to all modules that depend on it, either directly or via transitive dependencies. And the constraints currently applied are all the dependency versions currently present in the version catalog. So SolrJ only inherits the constraints, "forcing it" to use the same dependency versions as the rest of the project for the dependencies it has. What I am not sure and need to verify is, do we set this way the constraints for any consumer of SolrJ as well, even for dependencies SolrJ does not include? If so, this would probably not be optimal. If that is the case, this could probably be resolved by including a different version catalog for SolrJ, as Gradle allows having multiple version catalogs. It is also worth noting, that the previous solution (if I am correct) was applying the constraints to all module configurations as well, but only if there was any conflict in any of the modules and we had to add explicitly a rule. So SolrJ inherited constraints that were not necessarily part of it anyway. So this solution should not have a large impact, but it is still under investigation. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
