Developer Guide

Overview

Vic has been designed to make use of the Eclipse 4 RCP modularity. This allows new functionality and features to be developed in separate plugins without having to change the core Vic code.

Prerequisites

Java JDK 1.6 or above

Download and install Eclipse Juno 4.2.2 for RCP and RAP Development http://www.eclipse.org/downloads/. (NOTE: currently does not compile on 4.3 Kepler)

Setting up Eclipse

Install Eclipse 4 tooling to help development:

Within Eclipse go to Help -> Install New Software, click the Add... button and enter the URL:

http://download.eclipse.org/e4/updates/0.12

Expand 'E4 Tools' then select and install 'Eclipse e4 Tools (Incubation)'.

If you are new to Eclipse 4 RCP, it is recommended, that you read the following tutorial http://www.vogella.com/articles/EclipseRCP/article.html

Get the Vic source

Checkout all the Vic projects from sourceforge into Eclipse.

Currently the Eclipse 4 API is marked as Provisional, so you will see a lot of 'Discouraged access' warnings. To remove these warnings go to:

Windows -> Preferences -> Java -> Compiler -> Errors/Warnings -> Deprecated and restricted API

Change the 'Discouraged reference (access rule)' setting from 'Warning' to 'Ignore'.

Contributing to the Application Model (the GUI)

Fragments and Processors can be used by new plugins to add or take away from the application model. This allows developers to manipulate the application in such ways as adding new menu items or adding/removing panels without having to worry about updating the core code.

Hooking into lifecycle events

Extension Points are used to allow new plugins to hook into certain parts of the Vic runtime lifecycle, such as before the application has fully loaded and before it shuts down. This allows plugins to perform any setup and cleanup.

Core Services

Core services for Copy/Move/Create/Delete/Update have been created to handle common tasks. These can current handle document/folders of types: CMIS (repository documents and folder), File (java.io.File, local document and folder) and Messages (emails).

If you are interested in developing a new plugin which deals with a new object type not listed above, then simply define the functionality you need such as copy, delete e.t.c and this will be automatically picked up by the core services.

The benefit of using the core services in this way are:
a) They wrap the tasks up to be run as a background process to avoid locking the application.
b) Provide feedback to the user by way of a progress bar.
c) The services post before, on and after events which can be subscribed to by plugins to react accordingly. e.g. to refresh screen once copy is complete.

You can look at existing plugins 'Vic CMIS' and 'Vic Mounted Drive' as examples of how to create a new plugin.

Service Events

As mentioned above, the core services use the Eclipse Event System (IEventBroker) to publish events which can then be subscribed to. Your plugins can subscribe to these events and react as necessary.

Creating a Bridge

If you were to create a new plugin which for example connected to a Google Drive account, you would create the new plugin and provide the functionality to copy/cut/delete files e.t.c within the bounds of Google Drive. This plugin would know nothing about CMIS or Mounted Drive e.t.c., just Google Drive.

If you then wanted to add functionality to copy/move documents into the CMIS repository or a mounted drive, then you produce a new 'Bridge' plugin.

The Bridge plugin will provide the code to transform a Google Drive document for example into a CMIS document and vice versa. A separate bridge plugin can also be created to provide the code to transform a Google Drive document into a mounted drive document.

You can look at existing bridge plugin 'Vic Bridge IMAP to CMIS' and 'Vic Bridge Mounted Drive to CMIS' as examples.

Setting Preconfigured Defaults

The Vic configuration file is located in the Vic Common project under /resources/properties/vic-config.properties

host - This is the URL which is used to connect to the content repository. This configuration is used as a default but can updated by the user at runtime.
user.home - The content repository folder within which the individual user home folders are held. It is assumed that the user home folders match the usernames e.g. in Alfresco /User Homes/jbloggs1
vic.config.remote.location - The content repository location within which Vic specific files are stored. Although not required, Vic uses xml files within this folder or sub-folders to read and display metadata (properties) associated with content.
cmis.binding.type - Options are 'webservices' or 'atompub'. Default is webservices. NOTE: the host URL will need to be in the correct format to match the binding type.
help.url - A web link to the Help pages.