2. What happens when Taverna loads?

Taverna uses a plugin and code manager called Raven. This gives us the ability to include multiple versions of third party dependencies (i.e. Axis 1.3 and Axis 1.4) without version conflicts as well as manage extensions supplied by third parties and provide some level of automatic updates. This comes at a cost however, as the installation and configuration of Taverna is considerably more complex.

When a fresh Taverna 1.7.1 installation is run for the first time after being downloaded from one of our download mirrors the following things happen, performed by the Bootstrap class in the taverna-bootstrap jar file :

  1. Determine the startup location, unless the system property taverna.startup is already defined. This is the location of the taverna-bootstrap jar file. Once determined it is assigned to the taverna.startup.

  2. Determine the application home directory. If the system property taverna.home is set then use this, otherwise use the default value for user.home with an operating system specific suffix added. In effect this means that the default on Windows platforms will be the Documents and Settings/USER/Application Data/Taverna-1.7.1, on OSX USER/Library/Application Support/.taverna-1.7.1 and on linux or other UNIX-like platforms ~USER/.taverna-1.7.1.

    If the application home directory defined above does not exist then create it along with a conf subdirectory.

  3. Intialise the raven.properties. If this file exist in the taverna.home/conf then this is used, otherwise it is used from taverna.startup/conf. These properties are used for various Raven specific settings.

  4. Configure the proxy settings. These are defined in mygrid.properties as http.proxyHost, http.proxyPort, http.proxyUser, and http.proxyPassword and are transferred to being System properties. If the user and password are defined then the authentication mechism is set up.

    As with the raven.properties these are read from taverna.home/conf if they exist, other taverna.startup/conf.

  5. Raven uses the Properties object loaded in the previous stage to search for remote Maven 2 compliant code repositories from which it can download code artifacts. It searches for properties with names of the form raven.repository.NUMBER and interprets the value as a URI to the root of the repository. These are defined in raven.properties, and at the time of writing the repositories in the default properties file are :

    raven.repository.11 = http://www.mygrid.org.uk/maven/repository/
    raven.repository.12 = http://www.mygrid.org.uk/maven/proxy/repository/
    raven.repository.13 = http://moby.ucalgary.ca/moby/moby_maven/
    raven.repository.14 = http://mirrors.sunsite.dk/maven2/
    raven.repository.15 = http://www.ibiblio.org/maven2/
    raven.repository.16 = http://bioinf.ncl.ac.uk/mirror/maven/repository/
    raven.repository.17 = http://mirror.omii.ac.uk/maven/repository/
    raven.repository.18 = http://www.mygrid.org.uk/maven/snapshot-repository/

    The first sites contain the primary Taverna code, the ibiblio.org site contains almost everything else (and is the default Maven 2 mirror used by Maven). There's nothing particularly magic about these URLs, they simply point to the root of a directory structure containing a mix of jar files and metadata files describing dependencies. If you develop with Maven 2 you already know what these look like.

    If a repository is identified by a file:// URI the repository is treated as local and Raven is able to access artifacts in place rather than copy them to taverna.home/repository

    If it exists the location taverna.startup/repository is added as a repository. This is useful for bundling Taverna together with a repository as a complete package.

    In addition to this, a check is made if an old Taverna taverna.home/repository exists and if so adds it, as a local repository, to the start of the list of repositories. The reason for this is that many 3rd party artifacts are common between the two versions, and sharing an existing repository avoids duplication.

  6. Raven determines where to cache jar files and metadata through a property taverna.repository. If this is undefined it uses taverna.home/repository. Note that in the default configuration this results in jar files being downloaded to the user profile - this can easily swamp a large shared installation as there will be at least 30-40mb of files in a typical Taverna build.

    If the specified directory doesn't exist Taverna will create it. If it exists and is a file rather than a directory an error will be reported on the console declaring this.

  7. The bootstrap uses properties from the file located by raven.properties to determine an artifact and classname specification for the version of Raven. In the default implementation this is as follows :

    # Repository artifact containing Raven loader (should not have any dependencies) 
    raven.loader.groupid = uk.org.mygrid.taverna.raven 
    raven.loader.artifactid = raven 
    raven.loader.version = 1.5.2.0 
    # This static method will be called with lots of parameters 
    raven.loader.class = net.sf.taverna.raven.Loader 
    raven.loader.method = doRavenMagic

    These properties do not need to be changed unless you're upgrading Raven itself, something you have no reason to be doing so best to leave them alone! Raven uses these internally to construct a Method object through reflection which can be used to build the real application object, in this case this is defined by the following properties (also in the raven.properties file) :

    # Which target artifact to load and run (can have dependencies) 
    raven.target.groupid = uk.org.mygrid.taverna 
    raven.target.artifactid = taverna-workbench 
    raven.target.version = 1.5.2.0 
    # This static method will be called with no parameters, or 
    # if it accepts String[], commandline args will be passed 
    raven.target.class = org.embl.ebi.escience.scuflui.workbench.Workbench 
    raven.target.method = getInstance

    In this default case the bootstrap is configured to build a Class object for org.embl.ebi.escience.scuflui.workbench.Workbench and use the getInstance method on it to create a new workbench object. I'm not sure why we do this here rather than calling a main(String[...]) method but hey.

  8. The profile to use is determined. The profile is in some ways the 'version' of Taverna in that it defines the set of code artifacts to download, some of these are core components (such as the workflow model) and some are optional (such as the processor types e.g. BioMoby support).

    If the property raven.profile is set, it should define a URI to an absolute profile to use. This profile will be used immediately, and there will be no ability to update or switch between versions. In the presence of taverna.startup/conf/profile.xml then raven.profile is set to this profile automatically.

    If no raven.profile is defined, then the property raven.profilelist is used. This defines a URI pointing to an xml document that describes a list of profiles, which can change over time (prompting an update). Using the list of profiles also provides the ability to switch between versions. On first run, the lowest version profile is used, and stored in the file taverna.home/conf/current-profile-1.7.1.xml. From then on, this is the profile used when Taverna starts up. This current profile is changed either by selecting to do an update, or by switching to a specific versions.

    These properties are usually defined in raven.properties.

  9. Any artifacts in the profile with the attribute system defined and set to true are forcibly added to the bootstrap classpath, this only applies to artifacts which cannot be normally loaded by Raven such as XML parsers. In the default profile this means the following artifacts :

    <!-- system sax parser --> 
    <artifact groupId="xerces" artifactId="xercesImpl" version="2.6.2" system="true"/> 

    <!-- Jaxen XML support --> 
    <artifact groupId="jaxen" artifactId="jaxen" version="1.0-FCS" system="true"/> 
    <artifact groupId="saxpath" artifactId="saxpath" version="1.0-FCS" system="true"/> 
    <artifact groupId="dom4j" artifactId="dom4j" version="1.6" system="true"/> 

    <!-- system log4j for Raven's Log4jLog proxy --> 
    <artifact groupId="log4j" artifactId="log4j" version="1.2.12" system="true"/>

  10. Once this environment is configured correctly the reflection based loader created in (7) is used to instantiate the Workbench class, passing it any arguments from the command line. The splashscreen is shown based on properties within the raven.properties file as follows (the timeout is in seconds and is the duration for which the splash screen will remain, if clicked it goes away immediately) :

    # Show splashscreen? Set to 'false' to disable 
    raven.splashscreen = true 
    raven.splashscreen.timeout = 10

  11. Early in the workbench startup process, plugins are initialised. Default plugins are defined in taverna.startup/plugins/plugins.xml. User installed plugins are defined in taverna.home/plugins/plugins.xml. If the same plugin exists in both location, the settings in taverna.home/plugins/plugins.xml take precedence. A user can disable a default plugin, but cannot uninstall it.