Open notjuanortiz opened 4 years ago
We can address this and #176 after I review your PR
I could see things getting tricky in the implementation here, specifically when reading resources or classes in other modules. For instance the PluginBootstrap
, while apart of the core module, uses reflection to load all files from the plugins folder.
This is something I want to tackle sooner rather than later. I like your idea and was thinking of this structure for the future (0.5.0 -> 1.0). Plugins are also loaded using ClassLoader
now so it fixes that issue you were worried about.
io.luna.util
)io.luna.game.plugin
, Everything in plugins/api
)Tools should be shipped separately IMO but that's up for debate
The updates you've made to the structure look good. After some further thought, there's two caveats that I'd like to address here.
It's best if module names don't have a luna
prefix as it's assumed to be included in the project. So the resulting module would be cache
instead of luna-cache
.
The inclusion of a utility module is a bit of an anti-pattern. I think we could do with moving those classes closer to their implementations, either as-is within the same package or directly into the classes that are making use of them.
Problem(s)
The current single module project is large, and cluttered. This creates two problems.
If I want to create an extension, plugin, or tool, I have to rummage through the entire repository to find all of the code related to that feature.
If I'm testing a core game feature, I have to compile the entire project (including those pesky kotlin files that have a long compilation time).
Solution
Creating a multi-module Gradle project allows us compile only the required modules, instead of the entire application, when unit testing or manually debugging the server after changes are made. But we can reduce build times even more.
Builds on modules that use sub-modules as dependencies, by default, do so sequentially. We can leverage Gradle to execute builds in parallel, as long as these modules are decoupled, and do not share state.
From Gradle:
The Resulting Project Structure
This is just my opinion of the best project structure at this point. The features listed may or may not exist, but are listed to convey how extensible the project can get. Any and all feedback or improvements are welcome.