Restructure project into multiple Gradle modules

[notjuanortiz]

Problem(s)

The current single module project is large, and cluttered. This creates two problems.

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

   • This is partial due to the issues discussed in Discussion: Cohesive package naming conventions #176.

2. 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:

Most builds consist of more than one project and some of those projects are usually independent of one another. Yet Gradle will only run one task at a time by default, regardless of the project structure.

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.

• luna (root-project)
  • plugins (devs can build content here)
  • benchmarks
  • luna-application (and run the application from here)
  • luna-core
  • luna-network
  • luna-plugin-api
  • luna-plugin-engine
  • services-vote
  • services-high_scores
  • services-web
  • tools-rsa_generator (run this application if you need a new key pair)

[lare96]

We can address this and #176 after I review your PR

[notjuanortiz]

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.

[lare96]

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.

• luna (root-project)
  • luna-cache (Cache I/O)
  • luna-cache-server (Ondemand)
  • luna-network (I/O, codecs, connection filtering)
  • luna-game (World synchronization, entity types, etc.)
  • luna-utility (Everything in io.luna.util)
  • luna-app (Run server)
  • plugin-sdk (Everything in io.luna.game.plugin, Everything in plugins/api)
  • plugins (Content plugins)

Tools should be shipped separately IMO but that's up for debate

[notjuanortiz]

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.

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

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