+ <p>This document contains the release notes for all releases of Sirius.</p>

+ <h2 id="sirius0.9">Changes in Sirius 0.9.0</h2>

+ <p>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 &#171;Other API Changes&#187;, &#171;Specifier-Visible Changes&#187; and &#171;User-Visible Changes&#187; 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.</p>

+ <h3 id="MigratingfromObeoDesignerorViewpointtoSirius">Migrating from Obeo Designer or Viewpoint to Sirius</h3>

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

+ <ol>

+ <li>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);</li>

+ <li>then migrate those to Sirius 0.9.</li>

+ </ol>

+ <p>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.</p>

+ <p>If you were using Obeo Designer, you must thus first migrate your projects and models to Obeo Designer 6.2, and then consult the

+ <a href="release_notes_vp.html">release notes for Viewpoint 6.9 and 6.10</a>, which lists the API changes from Viewpoint 6.8 to 6.10.

+ </p>

+ <p>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 (

+ <li>Any plug-in dependencies towards Viewpoint plug-ins must be updated to the corresponding Sirius plug-in and version number. See the correspondence table below for the plug-in names to use.</li>

+ <li>If your plug-ins used any of the extension points defined in Viewpoint, you will need to update your

+ <code>plugin.xml</code> files to reference the correct extension points identifiers. In particular, all Viewpoint Specification Projects created using Viewpoint use the

+ <code>fr.obeo.dsl.viewpoint.componentization</code> in their

+ <code>plugin.xml</code> to register the VSMs they define. This should be changed to use the equivalent

+ <code>org.eclipse.sirius.componentization</code> extension point id. The identifier changes for the other extension points follow the same rules as the name changes of the plug-ins they are defined in.

+ </li>

+ <li>The migration of your VSMs (

+ <code>*.odesign</code> files) is automatic: simply open your files once in the VSM editor, perform some no-op change to make the editor &#171;dirty&#187; and save it. The saved version will have been migrated to Sirius.

+ </li>

+ <li>If you had Java code which used the Viewpoint APIs, you will need to update it to use the Sirius APIs. A simple &#171;Source &gt; Organize Imports&#187; on your source folders should find most classes you used in their new namespace. The Viewpoint code base and APIs used the term &#171;Viewpoint&#187; 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 &#171;Sirius&#187; instead, so you may need to adjust some names in your code beyond just updating the imports (for example,

+ <code>ViewpointControlCommand</code> is now

+ <code>SiriusControlCommand</code>).

+ </li>

+ </ul>

+ <p>Note that if you used Obeo Designer, you may have used the legacy Acceleo 2.x language for the computed expressions inside the

+ <code>*.odesign</code> files (if your expressions are of the form

+ <code>&lt;%something%&gt;</code> 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 (

+ <li>Modeling projects created using Viewpoint will not be recognized directly by Sirius, because the nature identfier has changed. You must use the &#171;Configure/Convert to Modeling Project&#187; action in the project&#8217;s context menu to make it a Sirius-compatible modeling project (see the section below for the technical details of the change).</li>

+ <li>The migration of you representation files (

+ <code>*.aird</code>) is performed automatically when they are loaded in memory. It will become permanent the first time you save it (you can force this by opening a representation, making some arbitrary change and saving the session).

+ </li>

+ </ul>

<h3 id="Pluginsversionnumbers.">Plug-ins version numbers.</h3>

<p>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

+ <p>The Java package names have changed to start with the identifier of the plug-in they are defined in (which has changed). A simple &#171;Source &gt; Organize Imports&#187; on your source folders should find most classes you used in their new namespace.</p>

+ <p>The Viewpoint code base and APIs used the term &#171;Viewpoint&#187; 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 &#171;Sirius&#187; instead (for example,

+ <code>ViewpointControlCommand</code> is now

+ <code>SiriusControlCommand</code>).

+ </p>

<h4 id="ModelsnamespaceURIs">Models namespace URIs</h4>

<p>All namespace URIs have also been changed from &#171;http://www.obeo.fr/dsl/viewpoint*&#187; to &#171;http://www.eclipse.org/sirius/&#187;.</p>

<p>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.</p>

@@ -205,6 +256,7 @@

<code>.project</code> file of each modeling projects.

</p>

<h3 id="OtherAPIChanges">Other API Changes</h3>

+ <p>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.</p>

-This document contains the release notes for all major releases of Sirius.

+This document contains the release notes for all releases of Sirius.

-h2. Changes from Viewpoint 6.9 to Sirius 0.9

+h2(#sirius0.9). 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.

+

+h3. 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:

+# 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);

+# 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":release_notes_vp.html, 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@).

+

+h4. Migrating Viewpoint Specification Projects

+

+* Any plug-in dependencies towards Viewpoint plug-ins must be updated to the corresponding Sirius plug-in and version number. See the correspondence table below for the plug-in names to use.

+* If your plug-ins used any of the extension points defined in Viewpoint, you will need to update your @plugin.xml@ files to reference the correct extension points identifiers. In particular, all Viewpoint Specification Projects created using Viewpoint use the @fr.obeo.dsl.viewpoint.componentization@ in their @plugin.xml@ to register the VSMs they define. This should be changed to use the equivalent @org.eclipse.sirius.componentization@ extension point id. The identifier changes for the other extension points follow the same rules as the name changes of the plug-ins they are defined in.

+* The migration of your VSMs (@*.odesign@ files) is automatic: simply open your files once in the VSM editor, perform some no-op change to make the editor "dirty" and save it. The saved version will have been migrated to Sirius.

+* If you had Java code which used the Viewpoint APIs, you will need to update it to use the Sirius APIs. 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, so you may need to adjust some names in your code beyond just updating the imports (for example, @ViewpointControlCommand@ is now @SiriusControlCommand@).

+

+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).

+

+h4. Migrating Modeling Projects and Representation Files

+

+* First migrate any modeler definitions used by your modeling projects and representation files (see the section above).

+* Modeling projects created using Viewpoint will not be recognized directly by Sirius, because the nature identfier has changed. You must use the "Configure/Convert to Modeling Project" action in the project's context menu to make it a Sirius-compatible modeling project (see the section below for the technical details of the change).

+* The migration of you representation files (@*.aird@) is performed automatically when they are loaded in memory. It will become permanent the first time you save it (you can force this by opening a representation, making some arbitrary change and saving the session).

h3. Plug-ins version numbers.

@@ -59,7 +88,11 @@ All identifiers have changed to start with the @org.eclipse.sirius@ namespace pr

+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@).

h4. Models namespace URIs

@@ -75,6 +108,8 @@ If you have many modeling projects to "migrate", you can easily make a script to

h3. 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.

+

h4. API Added

* Add @IMigrationParticipant.getPackage()@ to return the EPackage to use for the given namespace. This change concerns our internal migration framework. This is useful to handle our namespace changes (from Viewpoint to Sirius).

@@ -111,4 +146,4 @@ New variables are available for @sizeComputationExpression@ to compute the size

h3. User-Visible Changes

* The ability to print table representations has been disabled for the 0.9 release due to an external dependency issue (see "bug #422223":https://bugs.eclipse.org/bugs/show_bug.cgi?id=422223 for the details). It should be re-introduced in 1.0.

+ <li>New notion for layers: Additional layers (formerly Optional layer) cannot be disabled by end-user if the specifier unchecked the &#171;optional&#187; option. In this case, the layers become mandatory. The end-user do not see the mandatory layers in the layer activation menu.</li>

+ <li>A new graphical wrapper have been provided to group huge hierarchy children in tree items. Several preferences allow to customize this feature in the viewpoint preference page.

+ <ul>

+ <li>We find this wrapper on the model explorer tree viewer and on viewpoint selection wizards that use a tree viewer.</li>

+ <li>On viewpoint selection wizards

+ <ul>

+ <li>if the wrapper is disabled, we expand all children like in previous releases of viewpoint.</li>

+ <li>if the wrapper is enabled and root items are not grouping items, we expand only the first level of children.</li>

+ <li>if the wrapper is enabled and root items are grouping items, we not expand children.</li>

+ </ul>

+ </li>

+ <li>For more graphical details about this feature, please refer to the

+ <li>Until Viewpoint 6.2, the endÂ­-user had access to the Connections preference page (Viewpoint/Viewpoint Diagram/Connections). This page is provided by default by GMF but was unsuitable for Viewpoint use. Indeed, in Viewpoint the default routing style is defined in VSM. This preference page is available again. It has been adapted to Viewpoint (see

+ <code>fr.obeo.dsl.common.tools.api.constant.CommonPreferencesConstants</code> to say if the grouping strategy uses the containing feature instead of the basic hierarchy.

+ </li>

+ <li>This preference cannot be directly edited by the final user. A developer can override this default value, for example in its own AbstractUIPlugin implementation, in the start() method : ViewPointTransPlugin.getPlugin().getPreferenceStore().setValue(CommonPreferencesConstants.PREF_GROUP_BY_CONTAINING_FEATURE, true)</li>

+ </ul>

+ </li>

+ <li>

+ <code>PREF_GROUP_TRIGGER</code>:Integer (default=10000)

+ <ul>

+ <li>has been added in

+ <code>fr.obeo.dsl.common.tools.api.constant.CommonPreferencesConstants</code> to define the size of children that triggers the group in sub block.

+ </li>

+ </ul>

+ </li>

+ <li>

+ <code>PREF_GROUP_SIZE</code>:Integer (default=100)

+ <ul>

+ <li>has been added in

+ <code>fr.obeo.dsl.common.tools.api.constant.CommonPreferencesConstants</code> to define the size of elements contained in a group.

+ </li>

+ </ul>

+ </li>

+ </ol>

+ </li>

+ <li>

+ <code>fr.obeo.dsl.common.ui.tools.api.navigator.GroupingContentProvider</code> a new content provider wrapper that delegates everything to the replaced content provider excepted if groups are expected.

+ </li>

+ <li>

+ <code>fr.obeo.dsl.common.ui.tools.api.navigator.GroupingItem</code> a dedicated group tree item to provide an new ui render.

+ <code>Session.getSemanticCrossReferencer()</code>) to retrieve the GMF edge corresponding to the DDiagramElement.

+ </li>

+ <li>

+ <code>fr.obeo.dsl.viewpoint.tools.api.preferences.ViewpointDiagramCorePreferences</code> has been added. This interface declares constants corresponding to default routing styles. These constants are set via the UI preference page of

+ <code>fr.obeo.dsl.viewpoint.ui.tools.api.dialogs.AbstractExportRepresentationsAsImagesDialog.FILE_SEPARATOR_ALTERNATIVE</code> constant has been added. It defines the alternative character in

+ <em>export diagram as image dialog</em> when file separators are found in the representation name.

+ </li>

+ <li>

+ <code>fr.obeo.dsl.viewpoint.business.api.migration.IMigrationParticipant.getNewFragment(String)</code> returns the new fragment if the corresponding reference has changed. This method is added in the migration framework to handle the rename of a reference. The abstract implementation,

+ <code>fr.obeo.dsl.viewpoint.business.api.migration.AbstractMigrationParticipant</code>, has also been changed.

+* New notion for layers: Additional layers (formerly Optional layer) cannot be disabled by end-user if the specifier unchecked the "optional" option. In this case, the layers become mandatory. The end-user do not see the mandatory layers in the layer activation menu.

+* A new graphical wrapper have been provided to group huge hierarchy children in tree items. Several preferences allow to customize this feature in the viewpoint preference page.

+** We find this wrapper on the model explorer tree viewer and on viewpoint selection wizards that use a tree viewer.

+** On viewpoint selection wizards

+*** if the wrapper is disabled, we expand all children like in previous releases of viewpoint.

+*** if the wrapper is enabled and root items are not grouping items, we expand only the first level of children.

+*** if the wrapper is enabled and root items are grouping items, we not expand children.

+** For more graphical details about this feature, please refer to the "Modeling Project section":user/general/Modeling%20Project.html#ModelExplorer in the user documentation.

+* Until Viewpoint 6.2, the endÂ­-user had access to the Connections preference page (Viewpoint/Viewpoint Diagram/Connections). This page is provided by default by GMF but was unsuitable for Viewpoint use. Indeed, in Viewpoint the default routing style is defined in VSM. This preference page is available again. It has been adapted to Viewpoint (see "_Viewpoint User Manual/Diagrams/Features Overview/Style customizations/Customize edge routing style from preferences_":user/diagrams/Diagrams.html#routingStylePref for further details).

+

+h3. Changes Visible to Specifiers

+

+* Optional Layer has been renamed to Additional Layer.

+* A new attribute "Optional" is available to specified whether the additional layer can be disabled or not by end-user.

+* A new checkbox about @fr.obeo.dsl.viewpoint.description.EStructuralFeatureCustomization.applyOnAll@ under the @fr.obeo.dsl.viewpoint.description.EStructuralFeatureCustomization.appliedOn@ property section has been added. When this checkbox will be checked the @fr.obeo.dsl.viewpoint.description.EStructuralFeatureCustomization.appliedOn@ section will turn gray and disabled.

+* The fields ViewpointURI and representationName on Diagram Extension Description can be a regular expression as well.

+

+

+h3. Changes Visible to Developers

+

+* Changed APIs:

+** @fr.obeo.dsl.viewpoint.description.OptionalLayer@ type has been renamed to @fr.obeo.dsl.viewpoint.description.AdditionalLayer@

+** @fr.obeo.dsl.viewpoint.description.DiagramDescription.optionalLayers@ meta-model reference has been renamed to @fr.obeo.dsl.viewpoint.description.DiagramDescription.additionalLayers@

+** @fr.obeo.dsl.viewpoint.ui.tools.api.views.common.item.CommonItem.getSession()@ is now refactored in @fr.obeo.dsl.viewpoint.ui.tools.api.views.common.item.CommonSessionItem@.

+** @fr.obeo.dsl.viewpoint.ui.tools.api.views.common.item.CommonItem@ is now moved in @fr.obeo.dsl.common.ui.tools.api.view.common.item.CommonItem@.

+** Four new preferences to customize the new tree item group wrapper.

+**# @PREF_GROUP_ENABLE@:Boolean (default=true)

+**** has been added in @fr.obeo.dsl.common.tools.api.constant.CommonPreferencesConstants@ to say the tree item group wrapper is enable.

+**# @PREF_GROUP_BY_CONTAINING_FEATURE@:Boolean (default=false)

+**** has been added in @fr.obeo.dsl.common.tools.api.constant.CommonPreferencesConstants@ to say if the grouping strategy uses the containing feature instead of the basic hierarchy.

+**** This preference cannot be directly edited by the final user. A developer can override this default value, for example in its own AbstractUIPlugin implementation, in the start() method : ViewPointTransPlugin.getPlugin().getPreferenceStore().setValue(CommonPreferencesConstants.PREF_GROUP_BY_CONTAINING_FEATURE, true)

+**# @PREF_GROUP_TRIGGER@:Integer (default=10000)

+**** has been added in @fr.obeo.dsl.common.tools.api.constant.CommonPreferencesConstants@ to define the size of children that triggers the group in sub block.

+**# @PREF_GROUP_SIZE@:Integer (default=100)

+**** has been added in @fr.obeo.dsl.common.tools.api.constant.CommonPreferencesConstants@ to define the size of elements contained in a group.

+** @fr.obeo.dsl.common.ui.tools.api.navigator.GroupingContentProvider@ a new content provider wrapper that delegates everything to the replaced content provider excepted if groups are expected.

+** @fr.obeo.dsl.common.ui.tools.api.navigator.GroupingItem@ a dedicated group tree item to provide an new ui render.

+** @fr.obeo.dsl.viewpoint.diagram.business.api.view.ViewpointGMFHelper.getGmfEdge(DDiagramElement, ECrossReferenceAdapter)@ has been added in complementary of @getGmfEdge(DDiagramElement, Session)@. This method uses directly the parameter @ECrossReferenceAdapter@ (instead of @Session.getSemanticCrossReferencer()@) to retrieve the GMF edge corresponding to the DDiagramElement.

+** @fr.obeo.dsl.viewpoint.tools.api.preferences.ViewpointDiagramCorePreferences@ has been added. This interface declares constants corresponding to default routing styles. These constants are set via the UI preference page of @fr.obeo.dsl.viewpoint.diagram@ but declared here to allow access outside UI plug-in.

+** @fr.obeo.dsl.viewpoint.ui.tools.api.dialogs.AbstractExportRepresentationsAsImagesDialog.FILE_SEPARATOR_ALTERNATIVE@ constant has been added. It defines the alternative character in _export diagram as image dialog_ when file separators are found in the representation name.

+** @fr.obeo.dsl.viewpoint.business.api.migration.IMigrationParticipant.getNewFragment(String)@ returns the new fragment if the corresponding reference has changed. This method is added in the migration framework to handle the rename of a reference. The abstract implementation, @fr.obeo.dsl.viewpoint.business.api.migration.AbstractMigrationParticipant@, has also been changed.
\ No newline at end of file