Generate Plugin YML from Jar.

Discussion in 'Resources' started by teej107, Oct 26, 2014.

Thread Status:
Not open for further replies.
  1. Offline

    teej107

    To be honest, writing the plugin.yml is my least favorite part of making a plugin. I would much rather code than have to write a yml file. I started writing an application where you can drag and drop your plugin jar and it will automatically generate a plugin.yml file for you and embed it in the jar.

    Using this application alone produced a plugin.yml file just with the required attributes.
    • name (the jar file name minus extension)
    • main (finds the JavaPlugin class and writes the correct fully qualified name)
    • version (automatically puts 1.0)
    But that wouldn't be that useful. Almost every great plugin has commands and permissions. So I decided to write a class that the application also finds and writes to the yml based on that.
    PluginYML class (open)

    PHP:
    package me.teej107.yml;
     
    public abstract class PluginYML
    {
        public enum Load
        {
            STARTUP, POSTWORLD;
        }
     
        public enum Default
        {
            TRUE, FALSE, OP, NOT_OP;
     
            @Override
            public String toString()
            {
                return name().toLowerCase().replace('_', ' ');
            }
        }
     
        public abstract String name();
     
        public abstract String main();
     
        public abstract String version();
     
        public abstract String description();
     
        public abstract Load load();
     
        public abstract String author();
     
        public abstract String[] authors();
     
        public abstract String website();
     
        public abstract boolean database();
     
        public abstract String[] depend();
     
        public abstract String prefix();
     
        public abstract String[] softdepend();
     
        public abstract String[] loadbefore();
     
        public abstract Class<? extends Command>[] getCommands();
     
        public abstract Class<? extends 
    Permission>[] getPermissions();
     
        public static abstract class 
    Command
        
    {
            public abstract 
    String name();
     
            public abstract 
    String description();
     
            public abstract 
    String[] aliases();
     
            public abstract 
    String permission();
     
            public abstract 
    String permissionMessage();
     
            public abstract 
    String usage();
     
            public abstract Default 
    cDefault();
        }
     
        public static abstract class 
    Permission
        
    {
            public abstract 
    String name();
     
            public abstract 
    String description();
     
            public abstract Default 
    pDefault();
     
            public abstract 
    Child[] children();
        }
     
        public static final class 
    Child
        
    {
            public final Class<? extends 
    Permissionp;
            public final 
    boolean inherit;
     
            public 
    Child(Class<? extends Permissionpboolean inherit)
            {
                
    this.p;
                
    this.inherit inherit;
            }
        }
    }

    Then I concluded that it might after all be easier to just write the yml and then put it through a yml parser. Anyway, I already had finished this application by the time of the conclusion so I thought I might as well as post it and maybe somebody might find it useful. It can reduce mistakes made in writing plugin.yml files.
    Regular plugin jars without a PluginYML extended class will produce the following in the plugin.yml.
    • name (the jar file name minus extension)
    • main (finds the JavaPlugin class and writes the correct fully qualified name)
    • version (automatically puts 1.0)
    As long as you have a PluginYML extended class in somewhere in your plugin jar, it will add the additional attributes to the yml. The method names are similar or the same to the attribute names: http://wiki.bukkit.org/Plugin_YAML.

    If there is an attribute that you don't need or don't want in your plugin.yml, have it return null and the application will ignore it.

    To take advantage of the PluginYML class, add the application jar to your build path.
    To produce the plugin.yml, drag and drop the desired plugin jar in the application window. It will then give you an option to either open the yml, embed it in the jar, or both.

    Download Here
     
  2. Offline

    RawCode

    5 mb application used to generate 20 bytes YML?

    There is completely no reason to wrap bukkit api and random libraries found in internet into application, YML generation can be done without ANY import and without 3rd party code, everything required for work already in JDK.

    I will implement alternative zero dependancy application with similar goal soon.

    small sneak peak:

    Code:
    	static final String CHECK_FOR = "org/bukkit/plugin/java/JavaPlugin";
    	
    	static final byte SIZE_DIMENSION = 2;
    	static final byte PADDING_VALUE  = 6;
    	static final byte ENTRY_OFFSET   = 14;
    	static final int  BYTE_SHIFT     = 0xFF;
    	
    	public static boolean isJavaPluginChild(byte[] RawInput)
    	{
    		int OFFSET_A = RawInput[ENTRY_OFFSET] * BYTE_SHIFT + 
    				RawInput[ENTRY_OFFSET+1] + ENTRY_OFFSET + PADDING_VALUE;
    		
    		int OFFSET_B = RawInput[OFFSET_A] * BYTE_SHIFT + RawInput[OFFSET_A+1];
    		OFFSET_A = OFFSET_A + SIZE_DIMENSION;
    		String classname = new String(Arrays.copyOfRange(RawInput, OFFSET_A, OFFSET_A+OFFSET_B));
    		
    		return classname.equals(CHECK_FOR);
    	}
    
    allows to detect superclass of *.class without loading that class into memory.
    will fail for classes with really long names since string references support not implemented (dont really care about developers who make class names longer then 63 chars)

    EDIT by Moderator: merged posts, please use the edit button instead of double posting.
     
    Last edited by a moderator: Jun 14, 2016
    rbrick likes this.
  3. Offline

    teej107

    Yeah, I didn't like the size of the jar either either. Without depending on anything, this app just produces the required attributes alone but of coarse, that wouldn't be that useful. I'm still thinking of a better way to implement this. Cool code. it would definitely decrease the size of the app since I had to rely on Bukkit to get the JavaPlugin class.
     
Thread Status:
Not open for further replies.

Share This Page