Updated Project Architecture (markdown)

Risto Lahtela 2021-02-07 09:35:55 +02:00
parent 4344fade5b
commit bf7c825f42
1 changed files with 30 additions and 16 deletions

@ -6,7 +6,7 @@ This page attempts to help new developers start contributing to Plan.
It does not go over the build tool & commands for building as those are detailed in [[Project Setup]].
Page version: **5.0 build 263** [Commit](https://github.com/plan-player-analytics/Plan/commit/f061d4007990be811f2bf622abe23da815d3a1fb)
Page version: **5.1 build 904** [Commit](https://github.com/plan-player-analytics/Plan/commit/f061d4007990be811f2bf622abe23da815d3a1fb)
### Table of contents
@ -14,7 +14,7 @@ Page version: **5.0 build 263** [Commit](https://github.com/plan-player-analytic
- Modules & Dependencies between modules
- Dagger & Dependency injection
- Structure outline of `common`-module
- About Platform APIs
- Abstraction layer for platforms
- Web dev
- Technology stack
- Template-like html
@ -27,14 +27,14 @@ Module | Role
`api` | Contains code for [public API](https://github.com/plan-player-analytics/Plan/wiki/APIv5) interface classes
`extensions` | Contains built-in extensions that use DataExtension API (in public API)
`common` | Main package for everything
`bukkit`, `bungee`, `sponge`, `velocity` | Platform specific modules
`bukkit`, `bungee`, `sponge`, `velocity`, `nukkit` | Platform specific modules
`plugin` | Creates a single jar out of the modules
Most of the time work is done in `common` module as platforms are abstracted away.
## Build order
`api` -> `extensions` -> `common` -> `bukkit`, `bungee`, `sponge`, `velocity` -> `plugin`
`api` -> `extensions` -> `common` -> `bukkit`, `bungee`, `sponge`, `velocity`, `nukkit` -> `plugin`
From the build order, the dependencies between the modules should be apparent.
@ -47,6 +47,8 @@ It was used as a remedy to reduce static usage. (*See decisions here [Refactor p
`@Inject` annotations are used in Constructors to tell Dagger to resolve the dependencies for constructing a new instance of this class.
Most of the plugin uses Inject annotations, but some dagger related things can be found from `modules` package
Note that the Inject constructors allow Injecting an instance of the class the constructor is in to another object:
```
public class Foo {
@ -67,27 +69,28 @@ This is the main mechanism used for instantiating different system level objects
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.
- 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.
- 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.
## Package structure
> Packages were restructured during 5.0 update and some classes might still be in *odd* locations (`TaskSystem` for example).
Below are *packages* that are in package `common/src/java/com.djrapitops.plan`
Package | Role
-- | --
`api` | Plan API v4. Deprecated.
`api` | Deprecated. Plan API v4.
`capability` | Capability Service implementation (APIv5)
`commands` | Implementation for commands (`plan`, `planbungee`/`planvelocity`)
`data` | Contains deprecated APIv4 data classes.
`commands` | Implementation for commands (`plan`, `planproxy`/`planbungee`/`planvelocity`)
`commands.use` | Abstraction layer & framework for commands
`commands.subcommands` | Execution code for different commands
`data` | Deprecated. Contains APIv4 data classes.
`delivery` | Output related packages
`delivery.domain` | Data objects related to delivering web content & doing analysis
`delivery.export` | Export System and its utilities, for exporting html and json files
`delivery.formatting` | Formatting utilities (some use settings)
`delivery.formatting` | Date, time & data formatting utilities
`delivery.rendering` | Utilities for writing html and json
`delivery.web` | PageExtension API implementation (APIv5)
`delivery.webserver` | WebServer implementation & Request resolving
`exceptions` | Exceptions used around the plugin
`extension` | Implementation for DataExtension API (APIv5)
@ -106,16 +109,26 @@ Package | Role
`storage` | Database & resource (file/jar) management
`storage.database.queries | SQL queries for the database
`storage.database.transactions` | Transactions for the database
`utilities` | Bunch of random utilities
`utilities` | Utilities used in the plugin
`utilities.analysis` | Mathematical utilities
`utilities.chat` | In-game chat-box space formatting utility
`utilities.comparators` | Sorting utilities
`utilities.html.icon` | Deprecated. APIv4 html utilities
`utilities.java` | Java language extending utilities
`utilities.logging` | Error logging code
`version` | System that checks for new version
# About Platform APIs
# 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/Rsl1122/Abstract-Plugin-Framework).
This includes Commands and Task scheduling.
This is mostly limited to Task scheduling and logging.
Most likely you will not need to know more than that `RunnableFactory` (for creating Tasks) can be Injected like all other Plan classes, and that `Plan`, `PlanSponge`, `PlanBungee` & `PlanVelocity` implement similar interface from APF.
- `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.
## Platform Modules
@ -135,6 +148,7 @@ Plan uses the following stack to deliver the web content:
- Google GSON for serving data as JSON.
- XMLHTTPRequest for loading the JSON
- jQuery for placing the data on the pages
- Note: jQuery is slowly being removed from the plugin by replacing jQuery calls with modern javascript.
Web in general is moving away from using jQuery as the Javascript ecosystem has matured to a point where its functionality can be found in every browser. The decision to use it was made based on it being used by Bootstrap and jQuery data-tables.