risdenk commented on PR #1313: URL: https://github.com/apache/solr/pull/1313#issuecomment-1406527276
> (a) the tool isn't smart enough -- we need to add permitUnusedDeclared and similar things Do you have examples of this? I think `spotbugs` is one that might get fixed in later versions and hasn't been cleaned up. The other case being things that are used by reflection that a build tool can't understand. I don't see any egregious usages here. I know during reviews I've pushed back on adding permit* cases since they usually aren't needed. Those dependencies should be runtimeOnly for permitUnusedDeclared or other replacements without permit*. > (b) it doesn't understand the gradle concept of "api" in that it should be though of as inheriting a direct dependency rather than transitive. I'm not sure I understand this case here. Related to this PR, I'm guessing you mean adding `com.github.stephenc.jcip:jcip-annotations` explicitly to build.gradle to both core and solrj. The idea here is to ensure that each Gradle module declares the dependencies that are used directly. This makes it really easy to see what dependencies are used by that module. This prevents breakages if the transitive dependency were to change out from underneath the module. ie: * `moduleA` has an api dependency on `moduleB` * `moduleB` includes api dependency `thingA` * `moduleA` uses classes from dependency `thingA` This works as long as `moduleB` includes dependency `thingA`. If someone comes along and says "o look only `moduleB` uses dependency `thingA` lets replace it with `thingB`", then that would break `moduleA`. Th dependency analyze plugin forces `moduleA` to depend directly on `thingA` so that `moduleB` changes don't break `moduleA`. Yes it looks redundant on the surface, but this only happens for dependencies directly used by a module to prevent this type of breakage. -- 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]
