From 727ee5471fd7ec5202fff7168f705a2dccdc6046 Mon Sep 17 00:00:00 2001 From: Aurora Lahtela <24460436+AuroraLS3@users.noreply.github.com> Date: Sun, 10 Jul 2022 15:28:16 +0300 Subject: [PATCH] Updated Project Architecture (markdown) --- Project-Architecture.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/Project-Architecture.md b/Project-Architecture.md index f9164dc..f0df68e 100644 --- a/Project-Architecture.md +++ b/Project-Architecture.md @@ -52,7 +52,7 @@ From the build order, the dependencies between the modules should be apparent. ### Structure outline of `common`-module -Below are *packages* that are in package `common/src/java/com.djrapitops.plan` +Below are *packages* that are in package `common/src/java/com.djrapitops.plan` New modules use `net.playeranalytics.plan` package, old package name is used for backwards compatibility and clarity in older modules. Package | Role -- | -- @@ -120,28 +120,28 @@ public class Bar { ``` This is the main mechanism used for instantiating different system level objects, more about those below. -#### Lifetime +#### Lifecycle The process begins in a platform specific module by creating a new Dagger `Component` that resolves all dependencies for `PlanSystem`. - When the plugin is enabled by the platform it is running on `PlanSystem#enable` is called, which will lead to all subsystems getting started in a specific order. This order is determined by dependencies between the subsystems. When parts of these subsystems are injected in any constructor, I've tried to keep the same order as they are enabled. -- When the platform is shutting down and the plugin is disabled `PlanSystem#disable` is called, which stops all extra threads and closes resources the plugin is using. Platform specific shutdown such as cancelling runnables happens in the plugin class of the platform. - When the plugin is reloaded with `plan reload` command by user, first the plugin is disabled and then enabled. A new Dagger component is created in the process, so `PlanSystem` instance is new each time the process enables. +- When the platform is shutting down and the plugin is disabled `PlanSystem#disable` is called, which stops all extra threads and closes resources the plugin is using. Platform specific shutdown such as cancelling runnables happens in the plugin class of the platform. ### Abstraction layer for platforms -Different server platforms offer more or less the same sort of functionality, but with a different API. This is why in Plan some of it is abstracted away with [Abstract Plugin Framework](https://github.com/AuroraLS3/Abstract-Plugin-Framework). +Different server platforms offer more or less the same sort of functionality, but with a different API. This is why in Plan some of it is abstracted away with [Platform abstraction layer](https://github.com/plan-player-analytics/Platform-abstraction-layer). This is mostly limited to Task scheduling and logging. - `RunnableFactory` can be injected to create and schedule tasks (remember to schedule after creation). - `PluginLogger` can be injected to log stuff to the console. -Other abstraction is achieved by using `PlanSystem` and Dagger to avoid the platform specific plugins doing too much work. +Other abstraction is achieved by using `PlanSystem` and Dagger to inject interface implementations from other modules. ### Platform Modules -Platform modules include only the implementation for the specific platform so code from Bukkit is not available in `sponge` module and so on. +Platform modules include only the implementation for the specific platform. Code from Bukkit is not available in `sponge` module and so on. In the platform modules you can find implementations for Listeners and some tasks that require platform specific function calls. Note that proxy implementations (Bungee, Velocity) have different gathering behaviors and deliver different pages - this is done with the listeners and the different execution paths are done in the `common` module by using `ServerInfo#isProxy` method.