PluginFrameworkEnhancement

Description

In order to get the plugin framework somewhat stable and complete I've started reviewing and expanded it. I'll do this in two steps: first the backend and then the frontend. I've decided to do this by developing some plugins in parallel to get the requirements clear in a practical way. For the the backend plugin I've already started on a caldav provider, I'll decide on the frontend plugin later (thinking off a google maps plugin). While working on the plugin a couple of issues/missing features already popped up together with some infrastructure needs to make development easier. I'll list them here for now.

Enhancements/requirements

Infrastructure needs:

• A maven repository to deploy webical classes to. This enables plugin developers to add webical as a compile time dependency.
• A webdav location (or just web with some other form of upload) to deploy the plugin manifest xsd. This makes it possible to reference the xsd online.
• Nigthly builds that can be deployed to the maven repository (through continuum?).
• An svn restructuring to accommodate the plugins developed in-house. This could be done as a separate project or by dividing trunk in /webical and /plugins.
• (Optional) A location to upload (nigtly) builds for the plugins.

Webical enhancements:

• Extension the pom so that a jar is created with the classes to upload to the maven repository.
• Remove unnecessary dao interface methods (removeAll, etc)
• The possibility to include jar archives in the plugin:
  • Extend the manifest xsd.
  • Extend the plugin classloader.
• Add dependency information in the framework
  • Add a version number in the web.xml or applicationContext.xml (generated by maven)
  • Add a compatible-webical-version in the manifest xsd
  • Extend the Plugin registration system to check for the version numbers and only enable the plugin on a match.
• Refactor the class-references and jar-references
  • Now it's the idea to list all class, resource and jar files explicitly, but that seems a bit overdone. Instead just let developers register class-file and jar-file folders
• Refactor the plugin system initialization
  • atm the plugin framework is initialized after the configuration is done. This is fine but has a couple of bugs

Possible desired enhancements:

• Add a search method to the EventDao? and manager to enable search on the calendars.
• Extract the synchronization logic from the provider specific details so it can be reused by plugins (a google calendar provider for example).
• Plugin framework enhancements:
  • Add additional possibilities to describe the plugin:
    • An version number (required)
    • A description (required)
    • A static html page to display additional information like licenses, developers and that sort of thing)
  • Add configuration options
    • Global settings. Give the opportunity to supply a configuration page. The configurations are stored in the database.
    • User settings. Give the opportunity to supply a per-user configuration page. These configurations are stored in the database as well.
  • Divide the configuration page in steps where the plugin configuration has a separate tab.
  • Add a list of plugins with the state (plus reason why they are not enabled), info and a link to the optional info and configuration page.
    • Debug info can also be added. I'm thinking of a page that shows the registered classes, jars, resource directories, backend providers used/offered extension points, etc.

Technical interpretation

• Extension the pom so that a jar is created with the classes to upload to the maven repository.
  • Add a jar target that gets built by default

• Remove unnecessary dao interface methods
  • removeAll
  • Check the manager methods aswell

• The possibility to include jar archives in the plugin:
  • Extend the manifest xsd.
  • Extend the plugin classloader.
    • Load in the classes from the jar for later reference
    • on findclass first look in the jar map.
    • Add the possibility to use resources in the jar files through the classpath lookup mechanism (and the normal resources while we're at it)
  • Extend the plugin registration.
    • Revise the PluginSystemInitializer. It now takes a Webapplication which goes the wrong way trough the layers.
      • Extract a sensible interface
      • Implement this in the Webapplication and pass it to the PluginSystemInitializer

• Extend the plugin xsd with these elements
  • • A name (required)
    • An version number (required)
    • A description (required)
    • Webical version number (required)
    • A static html page to display additional information like licenses, developers and that sort of thing) (optional)
    • A global configuration class (optional)
    • A user configuration class (optional)
    • A list of developers (optional)

• Refactor the plugin xsd
  • Remove the class-reference(s) and jar-reference(s) entries
  • Add a class-folder(s) and jar-folder(s) element.
  • Refactor the PluginSystemInitializer to reflect these changes

• Refactor the plugin system initialization
  • Somehow make sure that all calls to the calendar are deferred until configuration is complete
  • Differentiate between the admin and calendar calls somehow

• Extend the PluginSystemInitializer to check for the version numbers and only enable the plugin on a match.

• Add a storage option for settings
  • Settings + hibernate mapping
  • SettingsDao
  • SettingsManager

• Refactor the configuration pages
  • Tabbed interface
    • General
    • Plugin System
    • Plugins
  • Initialization button
  • Plugin details -> plugin configuration/information pages
    • GlobalPluginConfigurationPage (Abstract)
      • Constructor takes pluginName
      • saveSettings
      • loadSettings

• Infrastructure enhancements
  • A maven repository to deploy webical classes to. This enables plugin developers to add webical as a compile time dependency. maven repository
  • A webdav location (or just web with some other form of upload) to deploy the plugin manifest xsd. This makes it possible to reference the xsd online. the xsd
  • Nigthly builds that can be deployed to the maven repository (through continuum?).
  • An svn restructuring to accommodate the plugins developed in-house. This could be done as a separate project or by dividing trunk in /webical and /plugins. webical-plugins
  • A location to upload (nigtly) builds for the plugins. see the maven repository

Discussion

-- IvoVanDongen - 22 Sep 2007