geode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Patrick Rhomberg <>
Subject Re: [Discuss] Transitive dependencies and internal .pom changes
Date Fri, 28 Sep 2018 17:39:34 GMT
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 <>

> 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 [
> dependencies].
> The plug-in documentation is here [
> wiki/Unused-Dependency-Rule
> ]
> Thank you,
> -Robert Houghton
> On Fri, Sep 28, 2018 at 10:18 AM Bill Burcham <> 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?
> >

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message