So it sounds like (per Robert) we use the gradle-lint-plugin's unused-dependency rule to warn us of unused dependencies. That handles one side of the equation (only list *necessary* dependencies).
I haven't heard anyone mention tool support for the other side of the equation: ensuring that we list the *sufficient* list of dependencies per build.gradle. Patrick, you just mentioned the java-library plugin's ability to distinguish between api and implementation dependencies. Geode doesn't use that plugin yet AFAIK, nor does the PR introduce that plugin right? All this seems of a piece with the march toward modularity, exemplified by Java 9 modules. Patrick, is your vision something like: 1. accept this PR … 2. introduce the java-library plugin and segregate dependencies into api vs. implementation ones … N. define Java modules On Fri, Sep 28, 2018 at 10:39 AM Patrick Rhomberg <prhomb...@apache.org> wrote: > Bill has the heart of it, yes. > > I should have also mentioned that this ties into java-library plugin > configuration, notably that the `compile` configuration is deprecated. > For dependences that we do not wish to leak, we will need to use > `implementation`. For dependencies which we intentionally elect to share > with our consumers, we should use `api`. > > For modularity, it should not break one module's ability to build for > another module to declare a `compile` configuration to be `implementation`, > unless of course that dependency is an active and necessary component part > of that module's consumption. In that case, it should be declared part of > the modules `api`. > In this vein and as Bill pointed out, a module should have an accurate > representation of its own build-time dependencies. > > In time, this will allow a much improved build experience, since > `implementation` and `api` are positioned for better granularity of > incremental building. > > On Fri, Sep 28, 2018 at 10:23 AM, Robert Houghton <rhough...@pivotal.io> > wrote: > > > Hi Bill, > > > > We are using a Gradle plug-in to identify dependencies that are unused, > or > > are declared in the wrong module or scope. > > This is called out by the Gradle documents on improving build [ > > https://guides.gradle.org/performance/#avoid_unnecessary_and_unused_ > > dependencies]. > > The plug-in documentation is here [ > > https://github.com/nebula-plugins/gradle-lint-plugin/ > > wiki/Unused-Dependency-Rule > > ] > > > > Thank you, > > -Robert Houghton > > > > On Fri, Sep 28, 2018 at 10:18 AM Bill Burcham <bburc...@pivotal.io> > wrote: > > > > > From the PR, Anthony, it seems to me that Patrick is proposing that > each > > > build.gradle be explicit about mentioning the "things" it depends on. > For > > > example: > > > > > > [image: image.png] > > > > > > Look at how geode-connectors goes from mentioning a few dependencies to > > > mentioning many more. The value of this is that it ostensibly shows us > > all > > > the things that geode-connectors actually depends on. > > > > > > The challenge I see is two-fold: > > > > > > • as with Java imports and "unused imports", there is the risk of > listing > > > more dependencies than we actually need > > > • there's also the risk that we still don't have a complete list of > > > dependencies > > > > > > Patrick: do you have tool support for this? Is there a tool that can > > > identify or even remove unused dependencies? What process do you use > for > > > finding these heretofore hidden dependencies? Did you run gradle > > > app:dependencies? > > > > > >
