Geode's codebase is broken up into a number of gradle subprojects, all called with geode-XXX. These will be referred to as geode modules in this document. These modules all get bundled up as part of the geode distribution by geode-assembly. Each one of these becomes it's own jar file which users generally consume through maven or as part of the code that is running on a geode server when the server is launched through gfsh start server.
The biggest module by far is geode-core, which contains the geode public API. The process for creating a module is different depending on whether the module you are creating should be a required dependency of geode-core, or an potentially optional add on which itself depends on geode-core.
Creating a module that geode-core depends on
This is the process for modules which are required dependencies of geode-core. Let's say your new module is called foo.
- Add a geode-foo directory, parallel with all of the rest of the geode-XXX directories.
- Add a build.gradle file in the geode-foo directory. You will probably want to copy from an existing build.gradle file, for example geode-tcp-server. Remove the dependencies you don't need
- Add geode-foo to geode/settings.gradle
- Add geode-foo as a dependency in geode-core/build.gradle. Generally, you want this to be an implementation dependency, unless the module has *public* API classes that users of geode-core's public API will need to access. Implementation means that it will not be part of the compile time classpath for consumers of geode-core.
implementation(project(':geode-tcp-server')) - Add geode-foo to TomcatInstall's list of jars
- Add geode-foo to to modify_war
- Add your module into the geode-assembly/build.gradle
- After you’ve added all those dependencies you have to run this command to update the expected POMs that will be uploaded to maven central ./gradlew updateExpectedPom
- Make these two tests pass:
GeodeDependencyJarIntegrationTest
AssemblyContentsIntegrationTest