Plugins

Most functionality of Jummp is encapsulated in plugins. A plugin cannot be compiled if it uses classes defined in the root Grails application, therefore these classes have to be moved into a separate plugin. Then, to use your plugin in the root application simply list "API-Plugin" as an inline-plugin in grails-app/conf/BuildConfig.groovy.

grails.plugin.location.'jummp-plugin-foo' = "jummp-plugins/jummp-plugin-foo"

This speeds up the development process, especially when working on many plugins. However, in the long run it would be beneficial to package the plugins and push them in a Maven repository for the purpose of reuse and added modularity. The process is summarised below.

Start by running grails package-plugin in your plugin's root directory. This will create a zip of your plugin. Make it available through maven. Alternatively, create a folder - we'll call it pluginlibs - in the root of the main application and move the newly-created zip file there. Then, teach JUMMP about its existence by adding the following to the main application's BuildConfig.groovy

grails.project.dependency.resolution = {
    // other stuff
    repositories {
        // other repositories
        flatDir name: 'jummpPlugins', dirs:"pluginlibs"
    }
    dependencies {
        //your dependencies
    }
    plugins {
        compile(:name_of_your_plugin:0.1)
    }
}

Next, make all plugins aware of the new repository in a similar but not identical fashion. Note the location! The plugins block can also be used when a plugin requires another plugin.

grails.project.dependency.resolution = {
    // other stuff
    repositories {
        // other repositories
        flatDir name: 'jummpPlugins', dirs: "../../pluginlibs"
    }
    dependencies {
        //your dependencies
    }
    plugins {
        compile(:jummp-plugin-foo:0.1)
        compile(:jummp-plugin-bar:0.1)
    }
}

Configuration

A plugin can inject it's own configuration using the plugin descriptor's doWithSpring closure, in which it can access JUMMP's configuration settings through grailsApplication.config.

A word of caution for plugins supporting a new Model format

Jummp can be extended to provide support for additional formats quite easily. Such a plugin provide a service that implements the FileFormatService API provided by the core-api plugin. In addition, it must register that service as handler of the new format. The following template should be used in your plugin descriptor's ##doWithApplicationContext## closure:

try {
    def service = applicationContext.getBean("modelFileFormatService")
    ["", "1.0", "1.1"].each {
        def modelFormat = service.registerModelFormat(<formatIdentifier>, <formatName>, it)
        service.handleModelFormat(modelFormat, <nameOfYourService>, <modelDisplayController>)
    }
} catch(NoSuchBeanDefinitionException e) {
    //cannot register the new format
}

Notice how, in addition to the model formats we support, in this case 1.0 and 1.1, we also register a default empty version of that format as a sort of catch-all safety-net. This is especially useful when you support multiple format versions. The ##modelDisplayController## parameter used when calling ##service.handleModelFormat## to select the controller used to display the model. Jummp expects each format plugin to provide a controller to handle a model display page, implementing an action called "show". For convenience, a layout (modelDisplay.gsp) has been provided for model display that can be used by this controller. For more information on format specific model display, see this page

Available Plugins

Core-API

The Core-API Plugin provides interfaces and classes used by other plugins. These classes are actual part of the core application. Further API parts should also go into this plugin if they need to be used by other plugins.

Security

The Security Plugin provides the domain classes used by Spring Security Core Plugin. These are: * User * Role * UserRole

The main purpose of this plugin is to be used in other plugins which need access to either User or Role.

Configuration

The Configuration plugin provides the UI (Controller and Command objects) and services to manage the runtime configuration. This includes a a first-run configuration (though the required filter is part of the root web-application) and an additional Controller for later runtime configuration only accessible to Admin users. For more information about configuring the web-application see the wiki page on configuration. The plugin depends on the Security plugin as it provides code to create the first user.

Subversion

The Subversion Plugin provides a Version Control System backend based on Subversion. It implements the Vcs and VcsManager interfaces of the Core-API plugin. For interaction with Subversion the High-Level API of SVNKit is used (which is bundled together with Grails). For more information on the Version Control System and it's Subversion backend see the wiki page on Version Control System.

Git

The Git Plugin provides a Version Control System backend based on Git. It implements the Vcs and VcsManager interfaces of the Core-API plugin. For interaction with Git the porcelain API of the JGit library (the required jar file is included in the plugin). For more information on the Version Control System and its Subversion backend see the wiki page on Version Control System.

SBML

The SBML Plugin provides an integration for SBML Model files. It is able to parse Models using JSBML and implements the FileFormatService to allow the ModelFileFormatService to validate the file and extract Model information.

COMBINE archive

This plugin provides support for Models encoded in COMBINE archive format by relying on the capabilities of a dedicated libCombineArchive. Like any other plugin that handles a certain model format, it implements the FileFormatService interface.

PharmML

The PharmML plugin handles Models encoded in PharmML. It consists of the following elements: * PharmMlService - complies with the FileFormatService and IPharmMLService interfaces, * PharmMlController - contains a single method - ##show## - that decides what gets rendered. The ##ModelController## forwards any request to display a model encoded in PharmML to this method. * /model/pharmml/show.gsp the view which, with the help of ##PharmMlTagLib## render the various model elements. * PharmMlDetectorThread - parallelises the quest to discover the file encoded in PharmML. It is used by two methods in PharmMlService that are responsible for detecting the format and for validation respectively.

The following limitations currently plague the plugin: * in order for the PharmML schema definitions to be found by libPharmML, we need to have them in the root folder of the application. This should be revisited when the API can load these definitions from a JAR. * the API does not support external sources and revolves around the PharmML file. Therefore, during the validation process we had to filter out non-PharmML files from being passed to the validator. * Some of the more complex maths elements including equations, function calls and datasets, are not being displayed due to lack of rendering support. This impacts the display of the symbol definitions, the parameter, structural and observation models, as well as the estimation steps. Technical solutions for the display of mathematical elements are being investigated.

Simple-Logging

The Simple-Logging Plugin demonstrates how a plugin can react to JUMMP application events and how to log them.

JMS

The JMS Plugin exports the Core API to JMS. It provides several services and depends on the core-api plugin to retrieve the services defined in the core application. To connect to the API exported by this plugin the JMS-Remote plugin can be used. In order for JMS functionality to be enabled, the environment variable JUMMP_EXPORT must be set to JMS.

JMS-Remote

The JMS-Remote Plugin provides the adapters to use Java Messaging Service from an external application to connect to the core application. It provides an extension to the jmsService of the grailsPlugin to perform synchronous JMS method calls and several adapters which handles passing all method calls to the Core with a useful API hiding the details of JMS. For a user of the service it is not noticeable that JMS is used at all.

DBus

DBus support has been dropped as of c728d21d600f.

Bives

Bives is the framework to provide diffs between two Model revisions.

Remote

The Remote Plugin provides interfaces to be used by the web application to access the core application in a standardized way. The interfaces are implemented by specific classes in JMS-Remote, hence the latter depends on the Remote plugin. The main purpose of this plugin is to define the API which has to be implemented by remote adapters and can be used by the web application.

Web-Application

The Web-Application Plugin provides the User Interface which is not generated by the Content Managment System.

Plugin Dependencies

The Plugin Dependency graph can be found as a dot file in the documentation subdirectory of the project.