Sirius – Provide Custom Migration Participants

Goals

In some cases, a migration of representation files or VSMs between two versions of meta-model is required. The migration process has been rewritten to be performed automatically at resource loading time. This migration is transparent for the end-user.
If you have extended Sirius meta-models, you may need to implement your own migration rules.

To contribute to the Sirius migration process, you need to implement an org.eclipse.sirius.business.api.migration.IMigrationParticipant and provide it through the org.eclipse.sirius.migrationParticipant extension point.

Extension point

The org.eclipse.sirius.migrationParticipant extension point allows to contribute migration participants. Each contribution must provide an implementation of IMigrationParticipant and a “kind” attribute which gives informations about what kind of file is concerned ( REPRESENTATIONSFILE_KIND for Representation files and VSM_KIND for VSMs).

MigrationParticipants implementation

Each methods of an IMigrationParticipant receives the current version of the model to migrate, corresponding to the org.eclipse.sirius bundle version.

Manage the version number

Your migration participant has to return the Sirius version number where your migration is introduced. For example, you have to write a new migration for viewpoint 6.7.0, your migration participant getMigrationVersion() has to return 6.7.0.qualifier, where the qualifier may be the current date.

getMigrationVersion() is used by the migration framework to determine if at least one participant has to be called, in that case the migration mechanism is launched.

Your migration participant is responsible to make sure that it has to perform its migration. Indeed, getMigrationVersion() is only used by the migration framework to determine if at least one migration is needed. You have to make sure that the viewpoint version number of the loaded resource requires a migration.