Upstream/Plan
1
0
Fork 0
mirror of https://github.com/plan-player-analytics/Plan.git synced 2024-11-25 03:55:37 +01:00
Code Issues Projects Releases Wiki Activity

Updated Project Architecture (markdown)

Aurora Lahtela 2022-07-10 15:28:16 +03:00
parent dd8815dc29
commit 727ee5471f
1 changed files with 6 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

12
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.