dsmiley commented on code in PR #4048: URL: https://github.com/apache/solr/pull/4048#discussion_r2692607885
########## dev-docs/gradle-help/dependencies.txt: ########## @@ -255,3 +255,28 @@ file as a URL under a <license> tag if there is no reference to a repository in Maven Central, or in the artifact downloaded by maven when the library is added as a dependency (in IntelliJ IDEA the libraries can be found in the project view under External Libraries at the bottom). + +Gradle analyzeDependencies and analyzeTestDependencies +----------------------------------------- + +We use the "cutterslade.analyze" build plugin to help maintain good dependency hygiene. +It tries to identify when a dependency is needlessly declared, and then fail the build to complain. +Unfortunately, it also requires us to add declarations that Gradle would otherwise deem unnecessary, Review Comment: @risdenk I saw a notification about a comment that I can't find in GitHub. You said: > I don't think this statement is true? > The plugin is requiring that dependencies used in a module are actually declared. The api spec has nothing to do with it. It makes each module self sufficient. It means that even if an api dependency removes a dependency (say commons-io) that the module doesn't break if it uses commons-io. it just makes the usage of dependency explicit. This is only for compile time dependencies where its a compile time dependency to actually build the module in question. How does an "api dependency" *remove* a dependency? RE "api": An illustrative example would be `:solrj-jetty` having `api libs.eclipse.jetty.http2.client` (Jetty's HttpClient). The use of "api" is a convenience to a user of a solrj-jetty to spare them from adding an additional implementation scoped dependencies _that they are likely to use in conjunction with the lib_. But thanks to cutterslade, within Solr, that distinction is defeated. Do you agree and/or am I missing something? There's a spectrum of developer prerogative from conservative to liberal, in terms of use of "api". I say "likely to use in conjunction with" but another person's definition might simply be the mere existence of a public signature that includes the target lib. I've increasingly preferred to use it conservatively. At work it's used liberally in a mono-repo and the extensive dependency web that doing so creates is out of control. -- 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]
