For 1.4-5-R1.0 and beyond, CraftBukkit's internals (net.minecraft.server, or NMS, and org.bukkit.craftbukkit, or OBC) have their package version-tagged. This means that your plugins poking into the volatile NMS/OBC internals will need updating each and every Minecraft version. For plugin developers looking for an easy way to handle this code change and support multiple versions (while not putting server admins in harms way), I wrote a very simple abstraction demonstration. You can also view my approach in my plugin TagAPI. The code is available here: https://github.com/mbax/AbstractionExamplePlugin Benefits: Version checking! If you call the version checker/loader in your onEnable, you can handle incompatibility (outdated plugin version) immediately. Backwards compatibility! Minecraft internals do change. This code lets you support multiple versions in one version of your plugin. On release day, you can quickly write the new implementation for the new version and upload and can still label your plugin as compatible with the previous version of minecraft! Maven! Maven is the coolest way to automate building of your plugin. Except perhaps building a robotic army to handle your job. There are several pieces to this setup. 1) The parent pom. The pom.xml at the root of the project is the parent. It doesn't create any project itself, but instead defines the child modules that will be built. The modules defined are the relative paths to the folders where the modules are located. It is possible to (and I do this in my other plugins) put all of the modules inside a folder named "modules" and then reference them as modules/modulename. The order of the modules doesn't matter as the system will determine the order necessary to build, but for sanity I ordered them in the way it will be done. 2) The API In order to call your NMS-interacting methods without specifically referencing a ton of versions in your main code, interfaces and abstract classes are a great solution. In the API module, I have defined an interface that very importantly does not reference ANY other code in the other modules. This module will be built first and thus cannot rely on other modules. In the example, I define a single method that takes a Bukkit object and a String. The pom.xml for this module defines the parent 3) The implementations Now, for any versions we wish to support, let's implement that interface in a package named after that version package (Why that is, is covered in step 4), with the file name the same (I used NMSHandler) for each implementation. This is an easy way to track supported versions. In each of these modules, create a class implementing the interface for that version of minecraft. This is where all the internal calls go. In the pom.xml the parent is again defined, and this time the dependencies are CraftBukkit for that specific implementation version as well as the API. 4) The final project. Lastly, we want to build everything together. The largest module in this example is the Plugin module. This is where the majority of the code goes. Anything that isn't the interfaces and abstract classes for the NMS implementation or the NMS implementation itself goes here. This is the module where you can refer to any other module. As you can observe in the pom.xml, all of the other modules are dependencies. In the main plugin class, I have defined a field "NMSHandler" of type NMS, which is the interface I defined in the API. In onEnable, the code first determines what version is running from the package found, and then attempts to load a class in the expected location. If anything goes wrong in that loading, for instance if the file is not found because the plugin version does not support that version of minecraft, it will disable itself and inform the server admin that it is time to update. In this module's pom.xml there are some additional things. First, this is the only pom.xml where I define a version number, as this is the one that will count. Second, I define the target directory as one level up, so that when the project is built the final JAR result of the plugin will be in the target folder on the same level as the parent pom, which is how non-modulized maven-built plugins work. Lastly, I am using the shade plugin to include the compiled files from all of the dependencies with a compile scope into this jar. This builds the complete plugin! Updating Future updates are simple - Just create a new implementation module (copy an existing implementation pom and rename a few lines!) and new implementation of your interfaces. Add the module to two places. 1) The parent pom, so it builds and 2) The final product pom, so it is shaded into the final jar. Some additional topics: Do I have to use separate packages for the implementations? No, an easy alternative to this would be to put all of your implementation classes in one package and name the classes after the version instead. I opted to use packages to mimic how NMS is labeling with packages. This feels far too complicated to maintain The only challenge in this approach is the initial setup. See the above description on updating. If you have any more questions feel free to ask.