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? > > >
