It’s easy! Just follow these quick tips.
While proper documentation and an appealing download page are good indicators, there are a plenty of assessments that can help discern whether a plugin is well-made. Using free tools anyone can use, detecting most common red flags doesn’t require any coding knowledge to comprehend. Here’s an easy-to-follow process for evaluating whether any given plugin has quality parts under the hood.
It is expected that you are already familiar with how to install server plugins. If you need a refresher, please read our article on how to set up a Minecraft server.
Seek the source code
If you’re fluent in Java, many plugins have their source—the code which ultimately makes up the plugin—available on repositories such as Github. A link to source code can often be found on the plugin’s resource page. In most cases where the source code is not provided, the downloaded plugin can simply be inspected with software designed for this purpose. This is the easiest way to check out how the project is structured.
Find a file manager
All plugins for Minecraft: Java Edition are distributed in the form of JAR files. These are simply packages of many files (known as an “archive”) which can be opened as long as you have the proper utility. A file manager or browser allows you to view the overall structure and basic text files inside a plugin. The utility known as WinRAR is a popular choice, but we recommend the 7-Zip software due to its lack of legal ambiguity. It was also tested to be faster than most managers in a number of aspects (source: https://www.tomshardware.com/reviews/winrar-winzip-7-zip-magicrar,3436.html).
Download a decompiler
While a file manager will give you an overview of how a plugin is organized, its compiled code (in this case, the collection of files which do the actual legwork) is not human-readable. This means another utility is needed to attempt to “decompile” the JAR contents into something anyone can understand, provided the author hasn’t applied obfuscation (more on this later). For most projects, we recommend JD-GUI, which offers a nice middle-ground between accuracy and user-friendliness in a simplistic graphic interface. Note that while most decompilers will also give you a look at structure and basic files, a dedicated file manager will typically provide a better experience for such tasks.
Check file and package names
Once you have the necessary tools, there are a number of good practices to watch for in server plugins. First, the package name should be something that immediately identifies what the plugin does and who created it. In a file manager or repository, this is viewed as a file path. For example, “org/browsit/cavegen” is a good package name, whereas “myplugin/mineCraft/QuicKteSt/abc” is a poor choice. Decompilers may use dots or dropdown menus instead of slashes. Besides being identifiable, the package name should be consistent in case (preferably all lowercase) and have an appropriate length, with three parts/folders being ideal.
Within the central package should be a number of files, most of which should be organized within folders. If one of those files starts with “Main” this is an indicator that the developer either followed a poorly-made YouTube tutorial or did not do sufficient research before jumping in, as this naming is readily frowned upon in the Minecraft plugin community. Look for file names to be descriptive and in Pascal case, such as “BukkitMagicPlugin” and not “mYbuKkitMagicpluGin”. The folders containing these files may use any capitalization, so long as it is consistent throughout, but should still represent the types of files within (i.e. a “listeners” folder for an “EntityListener” file).
Look for evidence of build tools
Although not mandatory, use of a build automation tool, like Maven or Gradle, is a good indication that this is not the plugin developer’s first project. These tools simplify the development process and are a great way to encourage others to work on or with the project. If you see any files containing the words “maven” or “gradle” within the JAR, there’s a high chance that an automation tool was used to create the plugin. You can also check the project’s source code for “pom.xml” or “build.gradle” files, which are configurations for Maven and Gradle, respectively.
Glance at the license and README
The developer’s choice of license (or lack thereof) is also an indicator of developer competency. Of the many options available, the MIT and GPL licenses are most desirable, allowing anyone to use and modify the plugin and code with the least restrictions. You can usually find this information in a LICENSE file within the JAR and/or its Github page. In cases where no license has been assigned, the author assumes full copyright. Note that while some plugins include license headers—a comment at the beginning of some or all included files—this is rarely sufficient to satisfy terms of a chosen license.
Another way to check if an experienced developer was involved is whether a well-written README file exists. This text file provides additional information such as why the plugin was made, where it’s available for download, and which license it was released under (but typically not the license agreement itself).
Use the Browsit search function
If you found these steps hard to follow or simply don’t have the time, try finding your plugin on our search page. We follow this process and more when reviewing plugins, so if your search result appears green, a version of that resource has been tested and found to comply with most, if not all, of these guidelines.
This post was last updated June 19, 2024 5:43 pm EDT