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
