Skip to end of metadata
Go to start of metadata

This is part of the Tutorial - Checking out Taverna source code, compiling, running and debugging

Introduction

After checking out Taverna we'll compile and build from source code using the Apache Maven tools.


We assume you have already configured Maven as explained in the previous steps of this tutorial, and that the checkout has completed.

Build Taverna

You should now have a project maintenance in your Package Explorer:

To rename maintenance to taverna-workbench, right click on maintenance and select Refactor -> Rename....

After renaming, to build Taverna, right click on taverna-workbench and select Run as -> Maven build... An _Edit Configuration_ window should appear.

For the Goals, set clean install:

Before you click OK, first go to the JRE tab to modify the Maven memory settings to be able to do the whole build and unit tests in one go. Under VM Arguments, add:

Click Apply and Run to start the build.

The Console tab should show Maven output:

Console tab missing?

If the Console tab is missing, click Window -> Reset perspective, or Window -> Show View -> Console.

Building Taverna for the first time will take a while to complete as it compiles every module and runs every unit test. 

Once the build has completed, the Console output should say something like:

Starting the developer build

Now you should be able to run the Taverna Workbench developer build from the command line. A minimal Taverna distribution should be under target/taverna-dev-* in the product/net.sf.taverna.t2.taverna-workbench/workbench-distro project.

The Taverna Nightly splashscreen should appear while Taverna is starting up. (On Windows, run taverna-debug.bat instead of taverna.sh).

You will notice that the title bar of Taverna will include the time of the build.

Note that you might have to configure Taverna on where to find the Graphviz dot binary in this developer version. On OS X you should be able to find a copy of dot inside an existing Taverna application bundle, say /Applications/Taverna 2.2.0.app/Contents/MacOS/dot.

Not starting on Windows XP?

If you are running the developer build on Windows XP, or your home directory contains characters which are not valid in a URL, such as spaces, you would need to modify the generated plugins/plugin.xml to escape those characters.

  1. From the target/taverna-dev-2.3-SNAPSHOT-20101111T1424-dev folder, edit the file plugins/plugin.xml
  2. Replace each of the (about 4) lines matching:
    with an escaped version:
  3. Delete the folder C:\Documents and settings\JohnDoe\Application Data\taverna-2.3-SNAPSHOT-20101111T1424 as Taverna has copied plugins.xml there
  4. Restart taverna-debug.bat
  5. To persist these changes for the next build of workbench-distro, modify workbench-distro/pom.xml and replace the <m2Repositories> macro of the developer-win profile to use your hard-coded home directory rather than ${user.home}

Repositories

If you compare the taverna-dev-2.3-SNAPSHOT-20101111T1424-dev directory with a normal Taverna installation, you will see that the repository folder is missing. Taverna will try to download any missing dependencies, but in the official Taverna downloads, all required JARs are included in the repository folder.

For users of the developer build it is likely that you would want to change only particulars module of Taverna while you are developing it, so to avoid having to do a new full build, the plugin definition (which is used even by the main components of Taverna) includes a reference to your local Maven repository.

Inspect taverna-dev-2.3-SNAPSHOT-20101111T1424-dev/plugins/plugins.xml to find:

This means that the .m2/repository folder on your file system will be searched for any POMs and JARs, and as it is a local file: reference, those dependencies will not be copied to $HOME/.taverna-2.3/repository as when installing a plugin.

The advantage of this is that if you as a developer is modifying a particular module of Taverna like the Beanshell activity, you may do a Maven install on just that module (mvn clean install on the command line, or right clicking and doing Run as -> Maven install on that particular folder in Eclipse), and the distribution in workbench-distro should pick up the new version on next restart, without requiring a rebuild of any other bits of Taverna. (assuming APIs are not changed).

Nightly snapshots

Maven will by default check and download new versions of JARs that are in -SNAPSHOT version, in particular if the JARs in .m2/repository is older than 24 hours. For Taverna these will come from http://www.mygrid.org.uk/maven/snapshot-repository/ - where new versions are deployed every night by the automatic build system.

The advantage of this is that you don't need to recompile modules you are not developing, but you would still get the changes committed by others to Subversion. So if you are developing the Beanshell activity, and another user is developing the Biocatalogue perspective, you would get the committed changes to Biocatalogue without re-building the biocatalogue module. However, if the BioCatalogue commit broke the build, the automatic build system would not deploy any snapshots that night.

This means that you could continue working even if the Subversion code is in a bit of flux - the official snapshots will always be from the last known working build.

Forcing new snapshots to be downloaded

If your project is not using the affected module, you might need to run Maven install again on the workbench-distro to get the new snapshots. To force downloading before the 24h limit, either use the -U parameter on the command line, or enable the Update snapshots tickbox in the Maven build dialogue, which you can edit from Run configurations.

If you are editing several modules, but have not committed your changes, and it's been more than 24h since you compiled your modified module, Maven could download a "newer" version from the myGrid snapshot repository, and your changes would no longer be active. To avoid this, you should start the day by recompiling "your" modules, or all of Taverna.

Distributable builds

The disadvantage of the developer build is that it can't be shared with anyone else, as they would not have the code from your /home/johndoe/.m2/repository. If you gave them the installation folder, Taverna would probably still work, but it would take quite a while to start up, as it would download everything from the listed Maven repositories, including nightly built snapshots of Taverna modules - which might not include your changes.

To build a snapshot distribution from Eclipse, expand products/net.sf.taverna.t2.taverna-workbench/workbench-distro and select Run as -> Maven build...

Again use the Goals clean install, but also set the Profiles to nightly:

Click Apply and Run. This time the build of workbench-distro will take a while longer, as Maven is constructing the repository folder with all the required libraries, and producing a distribution zip file.

The "release" profile

There's a third profile called release which are used by the myGrid team when building the release. The difference from the nightly version is generally that the timestamp is missing and that the splashscreen is different. You are recommended to use the nightly profile, which ensures that each build has its own Taverna home directory, like /home/stain/.taverna-2.3-snapshot-20101111t1424/.

Once the build is successful, the Console should say something like:

The distribution in target/taverna-nightly-2.3-SNAPSHOT-20101111-bin.zip should now be equivalent to the nightly build we started with, with all required JARs in its repository folder. You may share this build with other users to test your particular build.

Is every dependency included?

If the external dependencies of Taverna has changed, the Maven plugin that is populating the repository folder might not include the correct version of all JARs. You can spot this if when running the nightly snapshot, Taverna (tries to) download external JARs, and store them in /home/johndoe/.taverna-2.3-SNAPSHOT-20101111/repository. This folder should ideally be empty after starting Taverna.

Due to the way the Raven plugin system works, the bundled repository folder needs to include the POM and JAR in the exact same version as declared in the POMs dependencies. To
update the POM file of workbench-distro to include any duplicate libraries, edit the workbench-distro/pom.xml and look for generateArtifactItems.py for further details.

Now that we know we are able to compile and run Taverna, we can import Taverna modules into Eclipse so that we can play with the source code.

Labels