VirtualPlayer no longer implements Listener.

also, the implementation for
mc.alk.virtualplayers.nms.v1_7_R4.VirtualPlayer:getOnlinePlayers() has
changed because Bukkit.getOnlinePlayers() no longer returns an array.
Forwards any calls to the new package/class.

The package structure has changed to a more standarized syntax/notation of
all lowercase, and the project name. The new package structure also
contains versioned packages.

old: mc.alk.virtualPlayer;
new: mc.alk.virtualplayers;

Any static method calls made to mc.alk.virtualPlayer.VirtualPlayers:* is
forwarded to the new class at mc.alk.virtualplayers.VirtualPlayers:*

Originally, when I made the change, I didn't realize that other plugins
were hooking into the VirtualPlayers code base.

I noticed that mc.alk.arena.util.ServerUtil is making such calls. Not sure
if anyone else is hooking into VirtualPlayers. But this mapping of the old
class to the new class will allow plugins to use newer versions of
VirtualPlayers without breaking and without recompiling.
Re-added old methods that forward calls to the nms package.

These methods were originally moved to
mc.alk.virtualplayers.nms.{version}.VirtualPlayer

because they contained version dependent code.

The methods were re-added because mc.alk.arena.util.ServerUtil uses them.

These new methods simply use reflection to call the correct VirtualPlayer
class depending on what Minecraft version the server is running:

mc.alk.virtualplayers.nms.{version}.VirtualPlayer.class

This was not tested, but it should work. A unit test was written for the
invoke(String methodName, Object param) method.

The test simply ensures that the correct type of the Object param can be
obtained by the JVM.

Also, some of these methods contained references to
{version}.VirtualPlayer.

All VirtualPlayer types were changed to Object.

Ultimately, references should be made via some kind of VirtualPlayer
interace. But the problem is that getHeatlh() returns an int for older
Minecraft versions. And getHealth() returns float/double for newer
Minecraft versions.
Added test for invoke()

All these static methods were so difficult to test because it requires a
lot of other objects to be present (like a running server) that I just
copied the code over and verified the output.

public static void invoker(String methodName, Object... params)

Basically, the test just checks that the type of Object params can be
deduced at runtime. This type is used and passed to the reflection API in
order to invoke() methodName from

mc.alk.virtualplayers.nms.{version}.VirtualPlayer.class

invoke() only calls static methods.

All of this reflection and forwarding of calls was never tested, so please
report any bugs by opening a New Issue ticket. Thanks!
Removed duplicate dependency declaration in pom.xml
Added sorting, zero padding, and comments.

Bug fix:
Padding with zeros fixes a rare bug where the server is running (for
example) a plugin with version "1.2.0", and you ask isCompatible("1.2").
In this situation, the compatibility check would fail eventho is
shouldn't.

I thought of this because BombArena version 1.2.0 is about to be released.

Got Permission from DSH105 to use some of his ideas from:
com.dsh105.commodus.Version;

The article that I read on Comparator/Comparable said to return one,
negative one, and zero... But I really like how DSH105 simply returns the
difference: very elegent.

compareTo():
Also, someone in IRC told me that I should compareTo() other Version
objects instead of String objects. Initially, I didn't understand the
use-case-scenario, but then I figured out that it could be used for
sorting. Eventho, I'll probably never use this particular functionality, I
changed it... just in case anyone else wants to use it, (or even me in the
future).

Technically, I don't think the Version object should know about Plugins or
Bukkit Servers, but it is a little convenient for isCompatible() and
isSupported() to check for me if a plugin is even enabled.

So I might change this in the future... along with the factory methods...
Those should probably be in their own class, where the Version object
knows nothing about Plugins or Servers, but the VersionFactory does know
about them and how to use them to conveniently construct a Version object
for the user.

Finally, I have several of these Version.class files in different projects
that need to be moved to it's own util project. That way, I can declare a
dependency on this and other utility classes, and any changes will
propagate to other projects. It's on my To-Do List.
Changed repository

battleplugins-repo is down.

moved everything to the rainbowcraft-repo
Changed repo. Added wagon.

The battleplugins-repo server went down so I moved everything to the
rainbowcraft-repo.

The ssh wagon has the connector that allows deployments to be made to the
repo.

Instructions here:
http://maven.apache.org/guides/mini/guide-encryption.html

Basically, just use maven commands to make an encrypted master password:
mvn --encrypt-master-password
$> *********

Put this encrypted password into
~/.m2/settings-security.xml

<settingsSecurity>
  <master>{jSMOWnoPFgsHVpMvz5VrIt5kRbzGpI8u+9EF1iFQyJQ=}</master>
</settingsSecurity>

Then do
mvn --encrypt-password
$> *******

Put it into your settings.xml on your computer. There's 3 of them:
- one on the remote server reposity (not on your computer)
- a global one inside the maven installation directory /conf/ folder
- a per user one inside HOME/.m2/settings.xml

Put your encrypted password and username into your settings.xml :

<settings>
  <servers>
     <server>
        <id>rainbowcraft-repo</id>
        <username>root</username>
        <password>{COQLCE6DU6GtcS5P=}</password>
     </server>
  </servers>
</settings>

And now, distributionManagement and the ssh wagon will use the information
contained in your settings.xml to connect to the server and deploy your
build to the rainbowcraft-repo
Added getPlayer(UUID id)
Fixed an issue that was causing a Jenkins build error.