Skip to end of metadata
Go to start of metadata

Contract tone

The aim is for the work outcomes to be useful for myGrid (naturally) and for the work described to be challenging but tractable for David.

We are working out some of the details of the work areas as we go along, with the focus being usefulness and tractablility.

In agile terms we are preferring collaborations over contracts; possible due to the strong trust between the team and David.

Timetable

Contract to start 18th of March 2013 to 31st of July 2013.

M1 - March/April 2013 (build, update system, plugin system)
M2 - May 2013 (results perspective, run management using platform)
M3 - June 2013 (code restructuring, move to github)
M4 - July 2013 (documentation and technical support for myGrid)

Project management

  • JIRA for tasks (all major work areas detailed in this document)
  • Weekly Skype chat
  • David to come in for face to face meetings if need be

Things which will not be part of the Taverna 3 contract

Features in Taverna 2.x which will not make it to Taverna 3 beta

  • Custom perspective i.e. user layout
  • Taverna 1 compatibility; Taverna 3 won’t be able to load Taverna 1 workflows
  • No configurable dispatch stack; provenance did not work in this model as it needed to be able to capture at all layers
  • No BioMoby support (we might need to ask Katy about this)
  • remove extention point for renderers - just use OS

prerequisite myGrid work

These things need addressing before Taverna 3 beta can be delivered (ideally before the work on the Taverna 3 contract starts or early in the contract):

  • Simplify SCUFL2 activity configuration, RDF-like to JSON-like?
  • Data Bundle specification/API
  • Strategy for preservation of old CVS/SVN history when moving to GIT
  • Nested workflow representation in gui
  • David needs to sign contributor license agreement and the company that he is operating from does also
  • Agreed module structure by the team (Alan(leader), Stian, Donal)

Tasks

Source code layout

  • Move to git  - agreed Taverna 3 move to git - team to discuss level of history kept
  • Move to github - agreed
  • Merging of Taverna 2.x changes since 2.4.0

Build

  • Produce maven modules for Taverna Command Line and Taverna Workbench** artefact produced by module is the product
  • New module structure (draft - to be proposed by David W)** Core (engine)** Command Line** Workbench** Platform** Scufl2** Server
  • Enforce coding style guide automatically (myGrid to decide on process)
  • Each module builds separately
  • Semantic versioning, specially of APIs - how OSGi does it (can this be automatically tested?)** Note (Taverna 3 WB bundle is about 30 modules and with dependencies that get loaded it is about 100)
  • Copy and paste detection.

Plugin/Update system

A strong overall aim of this work is to enable a true continuous release mechanisms for Taverna.

  • Documented process/routine for doing an update** How to do a quick patch? (“Service X needs new parameter Y!”, “Snow leoapard graphviz does not work!”)** How to do a bigger update (consistening of a set of updates) - current configuration -> new configuration : analyze to determine osgi bundle changes.** say several APIs have changed in platform and we need new command line options and a new button in the Run dialogue* How to do a new download? ** How can it be picked up by old installations? Do they need to reinstall? (That should be OK as long as they are not left behind)** Effect on plugin developers?
  • System for automated/semiautomated continuous releases, say every 4th week** Integrated with Jenkins automated builds?** Should be independent for each of the main modules
  • Implement new plugin and update system** needs a definition of how to define and locate a plugin
  • Plugins compatibility check against updates
  • Rely on semantic versioning for plugin compatibility (not blind product version numbers)
  • Plugin support (architype, maven plugin, deployment, marketplace...)
  • Make existing modules OSGi aware (service oriented)
  • Remove any remaining impl dependencies (may require new api/impl splits)
  • Porting of existing plugins** Port myExperiment (as is)
  • Update architype for activity (& perspective) code

Tooling support

  • Maven archetype to help make project plugins
  • Maven plugin to build and deploy plugins
  • Maven plugin to build application and update

Misc

  • Make modules more OSGi aware - services transient and not all there at the beginning
  • Implement other service types** need to go through service types with Alan and see what needs to be done in context (e.g. Bean Shell needs to be replaced by the script service)
  • Pickup config and preferences in one way (OSGi config service)
  • Results perspective (can be left visually as is) (give or take what David thinks) - simple text otherwise an open with -
  • Kymbat usability changes, fairly simple low hanging fruit ones (Alan to provide)
  • Java 7 to be the baseline - This excludes Snow Leopard on Mac

Optional

Integration of Dmitry redmitry@list.ru updated WSDL parser

(optional) Error requirements (Alan) and then David to apply to beanshell/script service and the UI

Documentation

  • Coding style guide
  • Testing standards guide
  • Developers guide - (include osgi bundles, dependencies guide and versioning rules)
  • Plugin developers guide
  • Plugin migration guide from 2.x to 3.x

Testing

Integration

Test top 20 workflows on myExperiment (none BioMoby ones)

<Alan to provide specification> of testing (e.g. load, run, provenance) - this is for the beta so not all of the myExperiment workflows which is used for release.

Unit testing

Any new and modified code should be covered by appropriate unit test code coverage.

Report on test coverage to be provided.

MyGrid work (handover and post delivery)

Not an exhaustive list; but indicative of the split of work

  • add interaction service (this should be at the start of M4 as part of handover)
  • port BioCat plugin
  • refactor myExperiment plugin
  • refactor BioCat plugin
  • refactor component plugin (starting from existing 2.x Component plugin)
  • write user guide to Taverna 3
  • Update architype for activity & perspective tutorials (Alex)
  • BioMart 0.8 in the Taverna 3 work (Donal)
  • Verticals
  • Plugin migration guide from 2.x to 3.x (Alex)

Deliverables

    • Results perspective based on Taverna 3 platform
    • OSGi-based config/preferences
  • Taverna 3 beta platform service (OSGi)
  • Taverna 3 beta platform jar for none OSGi environments
  • Taverna 3 beta commandline
  • Taverna 3 beta server with alternative execution environment support (e.g. WB running a workflow on a server instance)
  • Documentation
Labels
  • None