Migrating to 2.0 from 1.x

This guide covers migrating MDWorkbench Server 1.x to MDWorkbench Server 2.0.

One of the goals of MDWorkbench Server 2.0 was to move MDWorkbench Server forward while remaining compatible with previous versions to the greatest extent possible. That is, plug-ins written against the MDWorkbench Server 1.x APIs should continue to work in 2.0 in spite of any API changes.

The key kinds of compatibility are API contract compatibility and binary compatibility. API contract compatibility means that valid use of 1.x APIs remains valid for 2.0, so there is no need to revisit working code. Binary compatibility means that the API method signatures, etc. did not change in ways that would cause existing compiled ("binary") code to no longer link and run with the new 2.0 libraries.

While every effort was made to avoid breakage, there are a few areas of incompatibility or new APIs that should be adopted by clients. This document describes those areas and provides instructions for migrating 1.x plug-ins to 2.0.

Incompatibilities between MDWorkbench Server 1.x and 2.0

1. OSGI Platform Introduced

MDWorkbench Server is now delivered as a WAR file which makes use of Eclipse Server-Side Equinox to run servlets in an OSGI platform. The great advantage is to have a consistent platform between development and production time.

The consequence is that the WAR file must contain only Eclipse plug-ins. If you had standalone JAR files deployed in the WEB-INF/lib/ directory, those JAR files needs to be wrapped into a plug-in before being used in the OSGI platform.

Refer to Eclipse Help Contents for more information on how to a plug-in from JAR files:
Plug-in Development Environment Guide > Reference > Wizards and Dialogs > New Project Creation Wizards > Plug-in From Existing JAR Archives

2. Structure Provider Test Page Registration

MDWorkbench Server now longer assumes a structure provider test page URL matches a specific pattern.

Starting with MDWorkbench Server 2.0, a structure provider implementer shall register a custom test web page to test the structure. The specific test page can be referenced in the declared structure provide extension.

Note that registering a test page web page for a structure provider is not mandatory. The test page is unlikely to be used by end-user and developer shall test the structure using a REST client.