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.
Instead of clearing the inventory of players and storing it's contents in a file, we now prevent
the server from sending the inventory packet if the player is not logged in. The player will
see a empty inventory, but has still his items stored on the server. Therefore we don't
need to modify the player's inventory and we won't make any inventory corrupted.
FixesXephi/AuthMeReloaded#203,
FixesXephi/AuthMeReloaded#193,
FixesXephi/AuthMeReloaded#191,
FixesXephi/AuthMeReloaded#148
Remove dead code + Fix empty inventory on the unregister command
Fix NPE if ProtocolLib isn't enabled or installed
