I think it would be easier to review and discuss these changes with smaller,
more focused PR’s. Is there a way to split up these changes? That would help
me a lot and I would be less concerned about introducing a problem with our
POM’s / dependencies.
Thanks,
Anthony
> On Oct 1, 2018, at
If what we are doing is just making sure that each geode module is
explicitly declaring all of its first order dependencies (things that
directly show up in import statements) in its build.gradle, then this seems
good to me.
I don't think we want to stop using gradle's ability to pull in all of
> 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?
That is correct, we do not yet make use of the `java-library` plugin (which
has the
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
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
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
>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
Agreed, plus many times you can declare that a dependency is either
(appropriately) "test" scope (for test dependencies only), "optional", or
(in certain cases) "provided", which will (should) have no impact to end
users, e.g. like conflicting dependencies.
However, I am in favor of reducing
I don’t follow why we should get rid of transitive dependencies. Can you help
me understand? How does this help with decoupling modules?
The whole java ecosystem is based on declaring and consuming transitive
dependencies via maven pom’s. I get the api/implementation dependency
Hello all!
# As a one paragraph elevator pitch:
A module should declare its own dependencies and not expose those
dependencies to a consumer unless explicitly intending to do so. As part
of working towards better decoupling between Geode's modules, we should
eliminate our reliance on
10 matches
Mail list logo
