geode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bill Burcham <bburc...@pivotal.io>
Subject Re: [Discuss] Transitive dependencies and internal .pom changes
Date Fri, 28 Sep 2018 23:26:25 GMT
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 <prhomberg@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 <rhoughton@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 <bburcham@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?
> > >
> >
>

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