- Create SettingsMigrationService#copyFileFromResource (inspired from CustomSettings)
- Use new method to copy missing files in plugin folder from JAR
- Create YamlFileConfiguration inside NewSetting: FileConfiguration object provided by JavaPlugin#getConfig() sets default values from the JAR's config.yml :(
- Change ConsoleLogger to take logger from plugin (work in progress)
Ideally JavaDoc should provide additional information to the developer
as to the method's purpose and usage. Typically you do not add the
return type of the method and the parameter's types since this can be
seen in the code.
A short description of what the parameter really is (e.g. a String can
hold many types of information) is a lot more beneficial. A JavaDoc
statement simply restating the parameter types and the method name is,
put bluntly, simply noise, since all of these things are already
contained in the code itself.
Similarly, @see references are great for pointing to other, related
methods but aren't very helpful to point to a superclass method (the
implemented or overriden method) since it is implied by @Override. A
developer can navigate easily to the superclass method with any
reasonable IDE.
Note that the new dependencies in the pom have the scope set to test, so
they will not be included into the built artifact. A first test class
illustrates the general way unit tests can be set up with JUnit, Mockito
and Hamcrest matchers.
