Class PluginYmlReader

java.lang.Object
com.ultikits.ultitools.utils.PluginYmlReader

public final class PluginYmlReader extends Object
Reads a module's own plugin.yml straight from its class's code source, given only a bare Class<?> - before any UltiToolsPlugin instance exists (D-12). This is the third place in the codebase that would otherwise open a JAR to read plugin.yml; extracting it once here is the point.

Every failure path - null code source, a directory code source with no plugin.yml (the common case for test/dev classpaths), a missing JAR entry, an unreadable archive, or malformed YAML - returns PluginYmlReader.PluginYmlInfo.EMPTY rather than throwing, logging at most one WARNING. This class runs once per plugin class during dependency-graph construction, and a single bad archive must not take the whole graph down (T-04-20).

Since:
6.3.0
Author:
wisdomme
  • Field Details

  • Constructor Details

    • PluginYmlReader

      private PluginYmlReader()
  • Method Details

    • read

      public static PluginYmlReader.PluginYmlInfo read(Class<?> pluginClass)
      Reads plugin.yml for the given class's own code source.
      Parameters:
      pluginClass - the class whose containing JAR (or classes directory) should be read; may be null
      Returns:
      the module's declared name and loadAfter list, or PluginYmlReader.PluginYmlInfo.EMPTY on any failure path
      Since:
      6.3.0
    • readFromJarFile

      public static PluginYmlReader.PluginYmlInfo readFromJarFile(File jarFile)
      Reads plugin.yml directly from a module's own jar File, without loading any class from it first.

      read(Class) above needs an already-loaded Class's ProtectionDomain to find the jar -- which is exactly what is not yet available when a module's main class is still being *discovered*. PluginManager's main-class discovery used to load every class entry in the jar, in entry order, until one happened to be assignable to UltiToolsPlugin -- which meant a class that exists only for an optional soft-dependency plugin (e.g. a PlaceholderAPI expansion) was linked, and failed to link, on every server where that optional plugin is absent, well before the real main class was ever reached. Reading the main: key directly out of plugin.yml and loading only that one declared class removes the rest of the jar from the discovery path entirely -- the same shape Bukkit/Paper's own PluginDescriptionFile uses to find a plugin's main class from its main: key, never by scanning the jar for a matching type.

      Parameters:
      jarFile - the module's own jar file; may be null or not a real file
      Returns:
      the module's declared name, main and loadAfter, or PluginYmlReader.PluginYmlInfo.EMPTY on any failure path (missing file, no plugin.yml entry, unreadable archive, malformed YAML)
      Since:
      6.3.0
    • toFile

      private static File toFile(URL location)
    • readFromDirectory

      private static PluginYmlReader.PluginYmlInfo readFromDirectory(File directory)
    • readFromJar

      private static PluginYmlReader.PluginYmlInfo readFromJar(URL jarLocation)
    • parse

      private static PluginYmlReader.PluginYmlInfo parse(InputStream inputStream)