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 :
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.
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/
, on OSX
USER
/Application
Data/Taverna-1.7.1
and on linux or other UNIX-like
platforms
USER
/Library/Application
Support/.taverna-1.7.1~
.USER
/.taverna-1.7.1
If the application home directory defined above does not exist
then create it along with a conf
subdirectory.
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.
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.
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.
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.
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.
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
.
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"/>
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
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.