To be able to install the plugin to Taverna, Taverna needs to be able to find the artifacts required. This is possible using Maven repositories. A maven repository is simply a http based file server such as Apache. If you with to be able to share your plugins with other Taverna users you will need to set up this server so it is publicly accessible on the Internet.
Full details of how you deploy your artifact can be found by reading the Maven documentation, but here is a brief summary of deploying via ftp, the most likely scenario.
First you will need to define within the pom.xml for your plugin project the location the artifact is going to be deployed to.
<project> ... <distributionManagement> <repository> <id>my-ftp-repository</id> <name>My Ftp Repository</name> <url>ftp://webserver/var/www/html/maven/repository/</url> </repository> </distributionManagement> ... <build> <extensions> <extension> <groupId>org.apache.maven.wagon</groupId> <artifactId>wagon-ftp</artifactId> <version>1.0-alpha-6</version> </extension> </extensions> </build> ... </project>
where webserver is the name of the server you are deploying to, and /var/www/html/ is the Apache server document root. /maven/repository/ is a sensible place to put your repository on you server, but you can of course choose your own. The declaration of wagon-ftp is also required for Maven to be able to find the extension to support ftp.
Since Maven will need to know the user name and password for the transfer, and you obviously don't want to declare these within your project file, these are defined within your Maven settings.xml as follows:
<settings> ... <servers> <server> <id>my-ftp-repository</id> <username>user</username> <password>pass</password> </server> </servers> ... </settings>
The settings.xml file can be found within $HOME/.m2/settings.xml when using Linux or the Mac, or "Documents and Settings\<user>\.m2\settings.xml" when using Windows.
Maven also supports deployment using ssh.
Once this has been set up then the plugin is deployed using the maven command 'mvn deploy'.
If your plugin has additional dependencies that are not available through the myGrid or Maven Central repositories, you will need to publish those within your repository also. You can do this by using the mvn deploy:deploy-file command to deploy individual jar files. If you find the artifact is available in another repository your can use that but will need to include that repository in the list of repositories when describing your plugin in the next section.
Once the artifact is deployed, it is necessary to describe the plugin before it can be installed into Taverna. This comprises of two simple xml files. The first file provides details about your plugin and contains the following content, using the myGrid Feta plugin as an example:
<plugin> <name>Feta</name> <description>Service discovery</description> <identifier>uk.org.mygrid.taverna.plugins.feta</identifier> <version>1.1.1</version> <provider>mygrid.org.uk</provider> <repositories> <repository>http://www.mygrid.org.uk/maven/repository/</repository> </repositories> <profile> <artifact groupId="uk.org.mygrid.feta" artifactId="feta-client" version="1.1.1"/> </profile> <taverna> <version>1.5.1</version> </taverna> </plugin>
Although many are self explanatory, here is a description of all the elements:
Table 2.2. Plugin description elements.
|name||The name of the Plugin|
|description||The description of the plugin that is displayed in Taverna's Plugin Manager|
|identifier||An additional identifier for your plugin that helps distinguish it from other plugins with the same name, though obviously you should try to avoid a name clash if possible.|
|version||The published version of your plugin. This doesn't necessarily match the version of your plugin artifact, but in most cases will.|
|provider||An identier for your plugin site, to help identifying the origin of a plugin.|
|repositories/repository||A list of one or more repository locations that the plugin artifact can be found as well as dependencies. This will at least include the repository you created when deploying your plugin in the previous section. Its not necessary to declare the central maven repository or the mygrid repository here as Taverna already knows about these. If you plugin repository mirrored you will want to include your mirror sites here.|
|profile/artifact||The profile lists the artifact for your plugin that you created and deployed previously. This can contain one or more artifacts, though in the majority of cases there will just be one. The artifact element should include the groupId, artifactId and version that relate directly to the project pom.xml of your plugin.|
|taverna/version||A list of the versions of Taverna your plugin is compatible with. When checking for compatibility these values are compared as a string comparison with the start of the running Taverna version. So a version of 1.5.1 declared here would state this plugin is compatible with all 1.5.1.x versions of Taverna, or in an extreme case a 1 here would state the plugin is compatible with all 1.x.x.x versions of Taverna (though this scenerio is practically impossible!).|
This information is stored in an xml file named of your chosing, though a name that reflects the plugin and version is clearly advisable.
The next xml file is a list of the plugins avaliable at your site, and has to be named pluginlist.xml. This contains a simple list of the files just produced, which can either be declared as relative or absolute locations. E.g.
<plugins> <plugin>feta-plugin-1.1.1.xml</plugin> <plugin>http://www.somefaroffplace.org/another-plugin.xml</plugin> </plugins>
In Taverna 1.5.0 this file was called plugins.xml, and did not contain the <taverna><version/></taverna> elements. This was renamed to pluginlist.xml to avoid the possibility of installing incompatible plugins into Taverna 1.5.0. If you omit these elements, Taverna will assume it is only compatible with Taverna 1.5.0.
The final step in publishing your plugin is to place these files on a http server where they can be accessed from Taverna, once again somewhere publically accessible if you wish to share your plugin with Taverna users. The http server that hosts your repository, but within a seperate directory not within the repository, would be a natural location.
The live myGrid plugin declarations may provide some additional useful examples.
Now all thats required is to install your plugin into Taverna. This is done through the Plugin Manager -> Find Plugins -> Add Plugin Site.
The URL should point to the root directory that the pluginlist.xml was published, not directly to the pluginlist.xml file itself. If all has gone well, once adding this your plugin should appear in the list of available plugins for installation.
However, what is probably more interesting here is what happens once the plugin site has been defined and the plugin installed.
When the site is added an entry is added to a pluginsites.xml file in $taverna.home/plugins/ which is created if it didn't already exist. This file looks like:
<pluginSites> <pluginSite> <name>My Plugin Site</name> <url>http://mypluginserver.org/plugins/</url> </pluginSite> </pluginSites>
Once the plugin itself is actually installed, it is added to a file plugins.xml in the same location. Taverna inserts the information from the plugins xml definintion into this file. So for using our Feta example this would look like
<plugins> ... <plugin> <name>Feta</name> <description>Service discovery</description> <identifier>uk.org.mygrid.taverna.plugins.feta</identifier> <version>1.1.1</version> <provider>mygrid.org.uk</provider> <enabled>true</enabled> <repositories> <repository>http://www.mygrid.org.uk/maven/repository/</repository> </repositories> <profile> <artifact groupId="uk.org.mygrid.feta" artifactId="feta-client" version="1.1.1" /> </profile> <taverna> <version>1.5.1</version> </taverna> </plugin> ... </plugins>
Whilst testing your plugin you can bypass the publishing stage by directly manipulating the $taverna.home/plugins.xml file.
You can also bypass the deployment stage by using file URL's to point directly at your local maven repository, for example <repository>file:/home/elvis/.m2/repository/</repository>