Indeed, both dependencies (geode-logging & geode-serialization) are listed as runtime dependencies.
*> Is SDG creating its dependencies manually?* I am not quite following your thinking on this question. Of course SDG uses transitive dependencies. SDG must declare direct dependencies on geode-core, geode-cq, geode-lucene and geode-wan., as it is using those features API to implement the functionality provided by SDG. Anyway, it because Apache Geode's public API is broken/incomplete (especially from a framework/tooling perspective, but even an application perspective in many cases) that SDG must rely on certain (non-protected) "internal" APIs. It turns out that those "internal" classes have hard (i.e. compile-time) dependencies on geode-logging & geode-serialization to even build a project (application, framework or otherwise) using those classes with Apache Geode. I am currently exploring whether I can alter the use of the "internal" class(es) to avoid forcing a compile-time dependency. -j On Mon, Dec 2, 2019 at 12:42 PM Jacob Barrett <jbarr...@pivotal.io> wrote: > > > > On Dec 1, 2019, at 2:40 PM, John Blum <jb...@pivotal.io> wrote: > > > > After some modifications to Spring Data for Apache Geode (Spring Data > > Geode; SDG), I was finally able to build SDG with Apache Geode 1.11. > > > > While I support the modularization effort, I would make it very clear (in > > documentation) now that both geode-logging and geode-serialization are > > required on the application classpath when using Apache Geode. > > > > Technically, I am not entirely certain about geode-serialization (yet), > but > > geode-logging is strictly required to use Apache Geode. I need to run > some > > more tests. > > Both are properly listed as runtime scope in the geode-core POM. Is SDG > creating its dependencies manually or using the transitive dependencies > from the Geode POMs? > > -Jake > > > > -- -John john.blum10101 (skype)
