Release Notes for Older Version of Sirius

  1. Release Notes for Older Version of Sirius
    1. Changes in Sirius 1.0.0 (from Sirius 1.0.0M7)
      1. User-Visible Changes
      2. Specifier-Visible Changes
      3. API Changes
    2. Changes in Sirius 1.0.0M7 (from Sirius 1.0M6)
      1. Specifier-Visible Changes
      2. API Changes
    3. Changes in Sirius 1.0.0M6 (from Sirius 1.0M5)
      1. API Changes
    4. Changes in Sirius 1.0.0M5 (from Sirius 1.0M4)
      1. User-Visible Changes
      2. API Changes
    5. Changes in Sirius 1.0.0M4 (from Sirius 0.9)
      1. User-Visible Changes
      2. API Changes
    6. Changes in Sirius 0.9.0
      1. Migrating from Obeo Designer or Viewpoint to Sirius
      2. Plug-ins version numbers.
      3. Major namespace changes
      4. Nature ID
      5. Other API Changes
      6. Specifier-Visible Changes
      7. User-Visible Changes

This document contains the release notes for older versions of of Sirius.

Changes in Sirius 1.0.0 (from Sirius 1.0.0M7)

User-Visible Changes

Specifier-Visible Changes

API Changes

Changes in org.eclipse.sirius

Changes in org.eclipse.sirius.diagram.ui

Changes in org.eclipse.sirius.diagram.ui

Changes in Sirius 1.0.0M7 (from Sirius 1.0M6)

Specifier-Visible Changes

API Changes

Move diagram.ecore in its own plugin

This milestone (Sirius 1.0M7) includes the third, and final, step towards a full separation of the diagram-specific stuff out of the core of Sirius (see Step1 and Step2 for more details).

All classes related to diagrams in org.eclipse.sirius have been moved to org.eclipse.sirius.diagram.
All classes related to diagrams in org.eclipse.sirius.ui have been moved to org.eclipse.sirius.diagram.ui.
All classes related to diagrams in org.eclipse.sirius.editor have been moved to org.eclipse.sirius.editor.diagram.
In the same way, all classes related to UI in org.eclipse.diagram have been moved to org.eclipse.sirius.diagram.ui. To simplify this step almost all classes of org.eclipse.diagram have been moved in org.eclipse.sirius.diagram.ui (and probably not only UI classes). These classes have been moved in src-diag source folder to facilitate future work about moving some of these classes in org.eclipse.diagram again.

Unlike, the Step1, a simple «Organize Imports» operation is not enough. First, you will probably need to add dependencies to org.eclipse.sirius.diagram, org.eclipse.sirius.diagram.ui or org.eclipse.sirius.editor.diagram in the MANIFEST.MF of your projects that depend on Sirius diagram classes. The dependencies to add depend on what you really use.

Moved extension points

Several extension points have been moved:

Changes in org.eclipse.sirius.common

Changes in org.eclipse.sirius

Changes in org.eclipse.sirius.diagram

Changes in org.eclipse.sirius.diagram.sequence

Changes in org.eclipse.sirius.ui

Changes in org.eclipse.sirius.ecore.extender

Changes in org.eclipse.sirius.ext.base

Changes in org.eclipse.sirius.synchronizer

Changes in org.eclipse.sirius.tests.support

Changes in Sirius 1.0.0M6 (from Sirius 1.0M5)

API Changes

High-level API for Automated Tests Using JUnit and SWTBot

Starting from version 1.0.0M6, Sirius includes high-level APIs to help creating automated tests using JUnit and/or SWTBot. These can be used either to test Sirius itself or to test Sirius-based modelers. These APIs are provided by two plug-ins:

Both plug-ins are only available if you install the new org.eclipse.sirius.tests feature.

Move diagram-specific EPackages into their own diagram.ecore model

This milestone (Sirius 1.0M6) includes the second step towards a full separation of the diagram-specific stuff out of the core of Sirius (see Step1 for more details).

This step is less impactful on your code than the first step. Nevertheless, some missed classes during first step have moved during this step:

The existing VSM ( *.odesign) and representations file ( *.aird) are automatically migrated.

Warning: If you have some code based on the root EPackage of an EClass, it may be necessary to adapt it. Example:

EPackage rootPackage = (EPackage) EcoreUtil.getRootContainer(element.eClass());
if (rootPackage != null && rootPackage.getNsURI().equals(ViewpointPackage.eINSTANCE.getNsURI())) {

should be adapted in

EPackage rootPackage = (EPackage) EcoreUtil.getRootContainer(element.eClass());
if (rootPackage != null && rootPackage.getNsURI().equals(DiagramPackage.eINSTANCE.getNsURI())) {

if element is a Diagram concept.

Changes in org.eclipse.sirius

Changes in org.eclipse.sirius.ui

Changes in org.eclipse.sirius.diagram

Changes in org.eclipse.sirius.table

Changes in org.eclipse.sirius.tree

Changes in Sirius 1.0.0M5 (from Sirius 1.0M4)

User-Visible Changes

API Changes

Library Extensions

This milestone (Sirius 1.0M5) introduces several new plug-ins, collectively called «library extensions». They are all named org.eclipse.sirius.ext.LIB, where LIB is the name of a library or component Sirius depends on. These plug-ins are used to isolate generic code which extends existing libraries with features and helpers needed for Sirius, but which do not depend on Sirius themselves. A relatively large part of the code in Sirius is of this kind: things that could/should be in EMF, GMF, Eclipse itself, etc. and which are not Sirius-specific but which make it easier to build Sirius itself. Sirius 1.0M5 introduces several of these library extensions and starts to fill them with existing classes which were «hidden» inside Sirius and are now exposed in library extensions. Most of the time, existing code which used the Sirius API will only need to:

  1. Add the necessary Import-Package (recommended) or Require-Bundle to depend on the library extension(s) where the code they use now lives;
  2. Perform a simple «Organize Imports» operation, which should find the classes and interfaces in their new locations.

Move diagram-specific EClasses into a separate EPackage

For historical reasons, the core Sirius metamodels defined in viewpoint.ecore contain both generic (dialect-independant like Viewpoint, RepresentationDescription, DAnalysis...) concepts and diagram-specific ones (e.g. DNode, EdgeStyle, ContainerCreationDescription...). The table and tree metamodels are more cleanly separated.
This milestone (Sirius 1.0M5) includes the first step towards a full separation of the diagram-specific stuff out of the core of Sirius. So many EClasses have been moved.

Most of the time, existing code which used these Sirius EClasses will only need to perform a simple «Organize Imports» operation, which should find the classes and interfaces in their new locations.
The «Organize imports» is not sufficient in case of imported classes existing several time in different packages ( EFactory classes for example with DescriptionFactory, or EPackage classes for example with DescriptionPackage). And in some cases ViewpointFactory (and ViewpointPackage) will have to be replaced by DiagramFactory (and DiagramPackage).

The Switch classes if overridden also require a particular attention.

The existing VSM ( *.odesign) and representations file ( *.aird) are automatically migrated.
Warning: Nevertheless, if you reference these Sirius concepts with the EPackage qualifier in your VSM ( *.odesign), in interpreted expressions for example, you must change viewpoint in diagram. For example viewpoint::DDiagramElement becomes diagram::DDiagramElement.

The impacted EPackages are :

Changes in org.eclipse.sirius

Changes in org.eclipse.sirius.common.ui

Changes in org.eclipse.sirius.table

Changes in org.eclipse.sirius.table.ui

Changes in org.eclipse.sirius.ui

Changes in Sirius 1.0.0M4 (from Sirius 0.9)

User-Visible Changes

API Changes

Sirius 1.0.0M4 includes a lots of API-breaking changes, as part of a global effort to improve the quality of the Sirius internals. In this milestone in particular, most of the APIs which were marked as deprecated in previous versions of Sirius (and before that of Viewpoint) have been either removed (if a replacement exists) or marked as non-deprecated (if no replacement exists yet).

Changes in org.eclipse.sirius.common

Changes in org.eclipse.sirius

Changes in org.eclipse.sirius.diagram

Changes in org.eclipse.sirius.ecore.extender

Changes in org.eclipse.sirius.ui

Changes in org.eclipse.sirius.table

Changes in org.eclipse.sirius.tree

Changes in Sirius 0.9.0

Version 0.9.0 is the first release under the Sirius name and under the Eclipse Foundation umbrella. Except for the few cases mentioned below (in the «Other API Changes», «Specifier-Visible Changes» and «User-Visible Changes» sections), Sirius 0.9.0 is functionally equivalent to the latest version of Viewpoint (version 6.10), which was the name of the project before it was open sourced at Eclipse. See the rest of the documentation for the complete list of feature of the Sirius platform.

Migrating from Obeo Designer or Viewpoint to Sirius

If you have existing projects which used this technology before it became Eclipse Sirius and want to migrate to Sirius, you must:

  1. first migrate your projects and models to the latest pre-Sirius version of Viewpoint or Obeo Designer available to you (Viewpoint is the previous name of Sirius);
  2. then migrate those to Sirius 0.9.

The latest version of Viewpoint which was available in an Obeo Designer release is Viewpoint 6.8, released in Obeo Designer 6.2. Sirius 0.9 is based on Viewpoint 6.10, which was not released publicly.

If you were using Obeo Designer, you must thus first migrate your projects and models to Obeo Designer 6.2, and then consult the release notes for Viewpoint 6.9 and 6.10, which lists the API changes from Viewpoint 6.8 to 6.10.

Once your projects are compatible with the latest Viewpoint available to you, you can migrate to Sirius, first by updating your Viewpoint Specification Projects and plug-ins which use the Viewpoint APIs, then by updating any Modeling Project and representation files ( *.aird).

Migrating Viewpoint Specification Projects

Note that if you used Obeo Designer, you may have used the legacy Acceleo 2.x language for the computed expressions inside the *.odesign files (if your expressions are of the form <%something%> then you used the legacy language). That language is not supported anymore in Sirius 0.9, so you must migrate your expressions to use Acceleo 3 and/or the specialized interpreters ( var:, feature: and service:, see the documentation).

Migrating Modeling Projects and Representation Files

Plug-ins version numbers.

As of Sirius 0.9, and probably at least until Sirius 1.0 when the APIs will be more stable, all the bundles share the same version, which is also the version for the feature. If you used versioned dependencies to the old Viewpoint code (e.g. dependencies towards Viewpoint 6.8), you need to adjust the versions in your MANIFEST.MF files in addition to the namespaces.

Major namespace changes

In the context of the move as an official Eclipse project named Sirius, all the namespaces used in the code have changed.

Plug-in and features identifiers

All identifiers have changed to start with the org.eclipse.sirius namespace prefix. The tables below give the mapping between the Viewpoint plug-in and features identifiers and their Sirius equivalent.

Viewpoint 6.x plug-in Sirius 0.9 plug-in
fr.obeo.dsl.common org.eclipse.sirius.common
fr.obeo.dsl.common.acceleo.mtl org.eclipse.sirius.common.acceleo.mtl
fr.obeo.dsl.common.acceleo.mtl.ide org.eclipse.sirius.common.acceleo.mtl.ide
fr.obeo.dsl.common.ocl org.eclipse.sirius.common.ocl
fr.obeo.dsl.common.ui org.eclipse.sirius.common.ui
fr.obeo.dsl.common.xtext org.eclipse.sirius.common.xtext
fr.obeo.dsl.viewpoint org.eclipse.sirius
fr.obeo.dsl.viewpoint.diagram org.eclipse.sirius.diagram
fr.obeo.dsl.viewpoint.diagram.layoutdata org.eclipse.sirius.layoutdata
fr.obeo.dsl.viewpoint.diagram.sequence org.eclipse.sirius.sequence
fr.obeo.dsl.viewpoint.diagram.sequence.edit org.eclipse.sirius.sequence.edit
fr.obeo.dsl.viewpoint.diagram.sequence.ui org.eclipse.sirius.sequence.edit.ui
fr.obeo.dsl.viewpoint.doc org.eclipse.sirius.doc
fr.obeo.dsl.viewpoint.editor org.eclipse.sirius.editor
fr.obeo.dsl.viewpoint.editor.sequence org.eclipse.sirius.editor.sequence
fr.obeo.dsl.viewpoint.editor.table org.eclipse.sirius.editor.table
fr.obeo.dsl.viewpoint.editor.tree org.eclipse.sirius.editor.tree
fr.obeo.dsl.viewpoint.eef.adapters org.eclipse.sirius.eef.adapters
fr.obeo.dsl.viewpoint.interpreter org.eclipse.sirius.interpreter
fr.obeo.dsl.viewpoint.table org.eclipse.sirius.table
fr.obeo.dsl.viewpoint.table.ui org.eclipse.sirius.table.ui
fr.obeo.dsl.viewpoint.tree org.eclipse.sirius.tree
fr.obeo.dsl.viewpoint.tree.ui org.eclipse.sirius.tree.ui
fr.obeo.dsl.viewpoint.ui org.eclipse.sirius.ui
fr.obeo.mda.ecore.extender org.eclipse.sirius.ecore.extender
fr.obeo.mda.pim.ecore.design org.eclipse.sirius.sample.ecore.design
org.eclipselab.emf.synchronizer org.eclipse.sirius.synchronizer
Viewpoint 6.x feature Sirius 0.9 feature
fr.obeo.dsl.viewpoint.runtime org.eclipse.sirius.runtime
fr.obeo.dsl.viewpoint.runtime.acceleo org.eclipse.sirius.runtime.acceleo
fr.obeo.dsl.viewpoint.runtime.ide.eef org.eclipse.sirius.runtime.ide.eef
fr.obeo.dsl.viewpoint.runtime.ide.ui org.eclipse.sirius.runtime.ide.ui
fr.obeo.dsl.viewpoint.runtime.ide.ui.acceleo org.eclipse.sirius.runtime.ide.ui.acceleo
fr.obeo.dsl.viewpoint.runtime.ide.xtext org.eclipse.sirius.runtime.ide.xtext
fr.obeo.dsl.viewpoint.runtime.ocl org.eclipse.sirius.runtime.ocl
fr.obeo.dsl.viewpoint.specifier.ide.ui org.eclipse.sirius.specifier.ide.ui
fr.obeo.dsl.viewpoint.specifier.ide.ui.acceleo org.eclipse.sirius.specifier.ide.ui.acceleo
fr.obeo.dsl.viewpoint.doc.feature org.eclipse.sirius.doc.feature

Java Packages and Classes Names

The Java package names have changed to start with the identifier of the plug-in they are defined in (which has changed). A simple «Source > Organize Imports» on your source folders should find most classes you used in their new namespace.

The Viewpoint code base and APIs used the term «Viewpoint» both for the name of the product and for the name of the concept. When it refered to the name of the product, the names where changed to use «Sirius» instead (for example, ViewpointControlCommand is now SiriusControlCommand).

Models namespace URIs

All namespace URIs have also been changed from «http://www.obeo.fr/dsl/viewpoint*» to «http://www.eclipse.org/sirius/».

If you have created VSM file (.odesign) or representations file (.aird) with Viewpoint, the changes of the namespace URIs will be automatically migrated during the loading of your VSM or your representations file. These new nsURIs will be stored physically in the file during the first save. If the file is not saved, the automatic migration will be replayed at the next opening.

Nature ID

The modeling project has a specific nature ( org.eclipse.sirius.nature.modelingproject).
If you have modeling project created with Viewpoint, you must launch the action «Configure/Convert to Modeling Project» to replace old nature id ( fr.obeo.dsl.viewpoint.nature.modelingproject) by the new one.
If you have many modeling projects to «migrate», you can easily make a script to replace fr.obeo.dsl.viewpoint.nature.modelingproject by org.eclipse.sirius.nature.modelingproject in all .project file of each modeling projects.

Other API Changes

This section only lists API changes in Sirius 0.9.0 compared to the latest version of Viewpoint it is based on, i.e. Viewpoint 6.10.

API Added

API Removal

void open();
void addSemanticResource(Resource newResource, boolean addCrossReferencedResources);
void addSemanticResource(URI semanticModelURI, boolean addCrossReferencedResources);
void addSemanticResource(URI semanticModelURI, boolean addCrossReferencedResources, IProgressMonitor monitor);
void removeSemanticResource(Resource resource, boolean removeCrossReferencedResources);
void removeSemanticResource(Resource semanticResource);
void save();
void close();
Collection<Viewpoint> getSelectedViewpoints();
void createView(Viewpoint viewpoint, Collection<EObject> semantics);
void createView(Viewpoint viewpoint, Collection<EObject> semantics, boolean createNewRepresentations);
void addSelectedView(DView view) throws IllegalArgumentException;
void removeSelectedView(DView view);

Specifier-Visible Changes

New variables are available for sizeComputationExpression to compute the size of edges on EdgeStyleDescription and BracketEdgeStyleDescription:

User-Visible Changes