risdenk commented on PR #1313: URL: https://github.com/apache/solr/pull/1313#issuecomment-1407136130
> Thus I think it's needlessly verbose for solr:hadoop-auth's build (or any other things that depend on solr-core) to specify any of solr-core's "api" dependencies. These dependencies are on the surface, not buried below (like Guava say). So as far as I'm aware - for the dependency to need to be declared - classes must be used explicitly in the module in question. I would not be surprised if hadoop-auth is using classes directly from solrj-zookeeper so it needs to be defined in hadoop-auth. This protects against solr:core from removing the api dependency on solrj-zookeeper and breaking hadoop-auth module. It sounds obvious to a human that we would never remove solrj-zookeeper as an api dependency from core, but the computer doesn't know that. so we need to be explicit there on the hadoop-auth module. I think the more interesting part is the ability to remove dependencies when they are no longer referenced - the negative to your example. Say guava or commons-io was removed from module classes (ie: replaced with JDK classes) in theory the dependency analysis would say "hey you have too many dependencies declared and they can now be removed" - this would also go for the case if hadoop-auth removed whatever was referring to solrj-zookeeper. I understand the example you are giving, but we don't have to declare EVERY dependency form solr:core in hadoop-auth - only the ones that hadoop-auth is actually using in its classes. -- 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]
