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 dependencies that are no long needed, if possible. On Thu, Sep 27, 2018 at 10:07 PM, Anthony Baker <aba...@pivotal.io> wrote: > 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 > separation, but that’s different. > > Anthony > > > > On Sep 27, 2018, at 7:04 PM, Patrick Rhomberg <prhomb...@apache.org> > wrote: > > > > 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 transitive dependencies. Dependencies required > > by the top-level project should remain unchanged. Please review these > > changes [1] and discuss possible impact. > > > > > > # Verbosely: > > > > As part of general build improvements, becoming Gradle 5 ready, and > > positioning the build to be more modular, Robert Houghton and I have been > > investigating reducing our (internal) reliance on transitive > dependencies, > > explicitly declaring those dependencies a given module has, and removing > > dependencies that are no longer consumed by a given module. > > > > Leaking dependencies has the potential to effect user experience. For > > instance, if a user would like to use a different implementation of > logging > > than we use internally, doing so should not ruin the classpath. Leaking > > our own implementations are dangerous in these sorts of situation, and > this > > has been a pain-point of interaction between Geode and Spring in the > past. > > For instance, GEODE-5001 found at its crux exactly this logging version > > mismatch as its issue. Conversely, a great deal of preparation for this > PR > > was spent tracking down which plugins were leaking conflicting versions > > JGit. Let's do better by the consumers of Geode! > > > > Much of our investigation has been driven by the Nebula dependency linter > > plugin, which I would additionally propose to be a valuable addition in > > verifying and maintaining the quality of our build. > > > > Note all dependency and POM changes effect only each module. The > > dependences for the product as a whole should and will remain unchanged > by > > this. The core driving force will be to allow for better modularity for > > Geode and extension developers interacting with individual pieces of > Geode. > > > > See pull request 2532 [1] for comparison in explicit dependency > declaration > > and potential changes to existing POMs. > > > > Regards. > > > > Imagination is Change. > > ~Patrick Rhomberg > > > > [1] https://github.com/apache/geode/pull/2532 > > -- -John john.blum10101 (skype)
