3. Plugin System

You are viewing an old version (v. 3) of this page.
The latest version is v. 23, last edited on Jan 17, 2010 (view differences | )
<< View previous version | view page history | view next version >>
  • Plugin Main Class

    Each plugin has a main class (Refer to [Write a Simple Plugin] for steps of how to create plugin main class) which should be extended from the AbstractPlugin. Plugin extensions and settings are defined by overriding proper methods of the AbstractPlugin class.

  • Plugin Dependency

    Each plugin will depend on the framewor, ie. the bundle with ID com.pmease.quickbuild, and they can depend on other plugins if you want to extend extension point (see below) defined in those plugins. Refer to [Write a Simple Plugin] for how to declare plugin dependencies.

  • Extension Point and Extension

    Extension point is the point of extension in QuickBuild, and it is defined in the form of interface or abstract class. The framework defined a set of extension points existing in package com.pmease.quickbuild.extensionpoint. Plugin itself can define their own extension points if it wants other plugins to extend its ability. Extension is an implementation of certain extension point, and is defined in a plugin. A plugin can have one or more extensions. Taking the artifact plugin (this plugin extends the system with the ability to publish and display artifacts) for example, the extensions are defined as below:

    public class MyPlugin extends AbstractPlugin {
        ...
        public Object[] getExtensions() {
            return new Object[] {
    	    new PublishStepTypeProvider() {
    
                    public Class<? extends PublishStep> getPublishStepTypeClass() {
    		    return ArtifactPublishStep.class;
                    }
    
                }, 
                new BuildTab() {
    
                    public String getTitle() {
                        return "Artifacts";
                    }
    
                    public boolean isApplicable(Build build) {
                        return new File(build.getDir(), ARTIFACTS_DIR).exists();
                    }
    				
                    public BuildPanel getPanel(String panelId, Build build) {
                        return new ArtifactPanel(panelId, build);
                    }
                }
    
        }
        ...
    }
    

    Here we defined two extensions: one extends the extension point PublishStepTypeProvider and the other extends the extension point BuildTab.
    For those plugins who define their own extension point, the code used to get all extensions for a particular extension point is as below:

    Quickbuild.getInstance(PluginManager.class).getExtensions(<extension point class>)
    

    The returned extension collection might be contributed from multiple plugins.

  • Plugin Setting

    Plugin might have settings, for example, Ant plugin has a setting defining path to Ant executable. There are four type of plugin setting, respectively global plugin setting, user level plugin setting, group level plugin setting and configuration level plugin setting:

  1. Global plugin setting
    Gobal plugin setting can be specified by overriding method getPluginSettingClass in the plugin class as below:
    public class MyPlugin extends AbstractPlugin {
        ...
        Class<?> getPluginSettingClass() {
            return MyPluginSetting.class;
        }
        ...
    }
    

    Here the class MyPluginSetting should be provided by plugin developer, for example:

    public class MyPluginSetting {
        private String property1;
        private String property2;
    
        @Editable(order=100)
        public String getProperty1 {
            return property1;
        }
        public void setProperty1(String property1) {
            this.property1 = property1;
        }
    
        @Editable(order=200)
        public String getProperty2 {
            return property2;
        }
        public void setProperty2(String property2) {
            this.property2 = property2;
        }
    }
    

    With property annotations, QuickBuild will generate the user interface to edit and save this plugin setting. Refer to Bean Editor for details of how to use annotation to tune the edit interface.
    The defined plugin setting object can latterly be retrieved using below code:

    MyPluginSetting myPluginSetting = (MyPluginSetting)PluginSettingHelper.getPluginSetting(MyPlugin.class);
    
  2. User level plugin setting
    User level plugin setting can be specified by overriding method getPluginUserSettingClass in the plugin class. Taking the MSN notifier plugin for example:
    public class MsnPlugin extends AbstractPlugin {
        ...
        Class<?> getPluginUserSettingClass() { 
            Return MsnUserSetting.class;
        }
        ...
    }
    

    And the MsnUserSetting class is like below:

    public class MsnUserSetting {
        private String msnAccount;
    
        @Editable(order=100)
        @Email
        @NotEmpty
        public String getMsnAccount() {
            return msnAccount;
        }
    
        public void setMsnAccount(String msnAccount) {
            this.msnAccount = msnAccount;
        }
    }
    

    This setting adds an attribute "msnAccount" to each user when the user is edited and displayed:

    For a particular user, this attribute can be retrieved later like below:

    UserSetting userSetting = (UserSetting)PluginSettingHelper.getPluginSetting(MsnPlugin.class, user);
    String msnAccount = userSetting.getMsnAccount();
    
  3. group level plugin setting
    Group level plugin setting is very similar to user level plugin setting, except that:
    • This setting is attached to each group and will be displayed and edited if view or edit particular group.
    • The setting class is specified by overriding method getPluginGroupSettingClass
    • The setting object can be retrieved latterly by calling PluginSettingHelper.getPluginSetting(<Plugin Main Class>, <group instance>)
  4. Configuration level plugin setting
    Configuration level plugin setting is very similar to user level plugin setting, except that:
    • This setting is attached to each configuration and will be displayed and edited if view or edit particular configuration
    • The setting class is specified by overriding method getPluginConfigurationSettingClass
    • The setting object can be retrieved latterly by calling PluginSettingHelper.getPluginSetting(<Plugin Main Class>, <configuration instance>)
  5. plugin setting migration
    Refer to [Bean Migrator] for how to migrate plugin settings between different plugin versions.
  • Plugin Data Storage

    Besides plugin setting, plugins might need to generate and save data on the fly when the plugin runs, and use them lately. There are two types of plugin data storages: build storage, and configuration storage.

  1. build storage
    Build storage is used by plugin to store data related to specific build, it is simply a sub directory under the build directory of server node (refer to glossary chapter of user guide for build directory definition). If the build is deleted, its companion build storages will also be deleted. Plugin developer should choose the sub directory name carefully to avoid conflict with other plugins.
    A typical usage of build storage is the artifact plugin: when publish artifacts for a particular build, the artifact plugin create a directory named artifacts under that build at server node, and copy specified files into this directory. It will also add a tab to this build, and display these artifacts for download using files resides in the arifacts directory previously copied.
  2. configuration storage
    Configuration storage is used by plugin to store data related to specific configuration, it is simply a sub directory under the configuration directory of server node (refer to glossary chapter of user guide for configuration directory definition). If the configuration is deleted, its companion configuration storage will also be deleted. Plugin developer should choose the sub directory name carefully to avoid conflict with other plugins.
    A typical usage of configuration storage is the build statistics plugin: when a build is finished, the statistics plugin collect build metrics, process them and save the processed result into a sub directory named build-stats under the corresponding configuration directory at server node. It will also add a tab to the configuration statistics page, and display the build statistics charts using the pre-processed data in the build-stats directory saved previously.
    Please be noted that it is also possible that a single plugin use build and configuration storage at the same time. For example, the junit report plugin generate two types of reports: the junit report for specific build, and the junit statistics report for a particular configuration. Data corresponding to build related report are put in the build storage, and data corresponding to configuration related reports are put in the configuration storage.
  3. plugin data migration
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.