Commit Graph

9 Commits

Author SHA1 Message Date
allinkdev
18951fa120
Port to ClassGraph (#30)
* Port to ClassGraph

* Migrate to Minecrell plugin-yml

This allows us to load libraries at runtime instead of using shading & creating massive JAR files.

* Fix constructor modifiers of cake command

* Fix improper usage of CommandMap
2023-08-21 17:39:50 -05:00
Paul Reilly
305ebae9bf Attempt at fixing command registration
Signed-off-by: Paul Reilly <pawereus@gmail.com>
2023-08-11 15:58:40 -05:00
Paul Reilly
6ef6eacea0 Addressed requested changes
Signed-off-by: Paul Reilly <pawereus@gmail.com>
2023-08-11 15:26:26 -05:00
Paul Reilly
bbaa325ad6 Create Cladis (NetworkManager Hook)
Signed-off-by: Paul Reilly <pawereus@gmail.com>
2023-08-11 14:08:49 -05:00
allinkdev
8e5c52d0e8
Implement configuration system (#12)
* Return primitives in configuration interface where possible

This should save some unnecessary performance and memory overhead caused by the storage of object wrappers of the primitive types and the unboxing of those object wrappers into the wrapped primitive types when we try to do some primitive-exclusive operation.

I doubt that we'll be using the additional sugar methods that these wrappers provide most of the time, and if we need to we can just box the returned primitives.

* Mark returned lists in Configuration interface as Unmodifiable

I can't think of a use-case where we would want to modify the returned list from the Configuration interface we're accessing; however in case those situations do in-fact exist, I've made the decision to mark the return values of those methods as Unmodifiable so that there are no confusions in the future when the returned list throws an UnsupportedOperationException

* Provide class parameter in Configuration#getList

Otherwise, it's impossible to actually check if the on-disk configuration values are actually of the same type as/a subclass of what the plugin is expecting in the implementation.

* State that Configuration#getList will return an empty list if it fails

I don't think it would go particularly well if we were to return a list of Objects when we have a parameterized method. Additionally, how would components of the plugin respond to being given a list of Objects instead of whatever type they were expecting? This should be a better fail-safe solution compared to what we were previously going to do.

* Return an optional in Configuration#get if something went wrong

* Add class parameter to Configuration#get

* Update JavaDoc of Configuration#getList to reflect new parameter

* Remove final modifier from parameter

* Add class parameter to Configuration#getOrDefault

* Fix misspelled JavaDoc tag

* Partially implement a wrapper over FileConfiguration that implements our Configuration

* Fix codestyle violation

* Add copyright header & change package

* Add code for WrappedBukkitConfiguration#getList and WrappedBukkitConfiguration#get
2023-08-11 14:01:19 -05:00
EnZaXD
086e5ca72f
Added copyright notice to all class files (#23)
* Pushed copyright configuration to all classes

* Removed duplicated copyright headers
2023-08-11 19:41:38 +01:00
Eva
3e8c63221d
Overhaul of Patchwork and Registration system, fix-up for all plugin.yml files and removal of .negates(0 and .value() from DefaultNodes in turn for the .expiry() system removing the redundancies. (#21)
Co-authored-by: eva <66324759+evax64@users.noreply.github.com>
2023-08-11 13:15:36 -05:00
Paldiu
9bb7ebb770
Changed phrasing to match latest changes. 2023-08-06 17:07:49 -05:00
Paldiu
21463c50fe
Migrates the entire package nomenclature to be more direct and straightforward. (#17)
Signed-off-by: Paul Reilly <pawereus@gmail.com>
2023-08-01 22:34:18 -05:00