Child pages
  • Migration20

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migrated to Confluence 4.0

...

Non-automatic migration

If you want full control on over what MPS will dodoes, you can use this way of performing migration. In the next part we'll consider all the refactorings separately.

...

  1. Main Menu -> Tools -> Migrations 2.0 -> Upgrade Persistence
  2. Main Menu -> Tools -> Migrations 2.0 -> Fix Module Dependencies
  3. Main Menu -> Tools -> Migrations 2.0 -> Migrate Stub Models
  4. Open logical view, right-click project, select "Optimize Imports"
  5. Main Menu -> Tools -> Scripts -> All Scripts..., check all scripts with type "Migration (MPS 2.0)", click "Run Checked"
  6. Go to Main Menu -> File -> Settings. Select Model Checker properties and uncheck all checkboxes except "Check for unresolved references" and press "Ok". Right-click project node in logical view and select "Check Project". The Model Checker tool will show you all the broken references you have. Correct them by hand.
  7. Right-click project, select "Rebuild Project"
  8. (Recommended, but not necessary) Restart MPS.

Advanced cases

There was one change in MPS 2.0 for which we can't provide a common migration, so if you have used this feature, you are to correct your code by hand. But we suppose that nobody has actually used this feature till the moment.
So, the problem appears if you had created your own "attributes" (instances of AnnotationLinkDeclaration) with complex hierarchies (in case when your attributes are direct subconcepts of BaseConcept, the migration script will do everything for you, both in automatic and non-automatic scenario).
Migration for such hierarchical attributes is the following:

  1. Ensure attribute concept described in AnnotationLinkDeclaration (target) is subconcept of one of NodeAttribute, LinkAttribute or PropertyAttribute depending on the attribute stereotype
  2. Define role concept property in attribute concept as attribute role in AnnotationLinkDeclaration
  3. If sourceCardinality was * define multiple concept property in attribute concept
  4. Define attributed concept link from source in AnnotationLinkDeclaration

What the migration will do with my code?

...

Rebuild: After you have migrated your code (MPS models) to match 2.0 version, they should be rebuilt and recompiled to start working in MPS. That's what this step does.

Advanced cases

There was one change in MPS 2.0 for which we can't provide a common migration, so if you have used this feature, you are to correct your code by hand. But we suppose that nobody has actually used this feature till the moment.
So, the problem appears if you had created your own "attributes" (instances of AnnotationLinkDeclaration) with complex hierarchies (in case when your attributes are direct subconcepts of BaseConcept, the migration script will do everything for you, both in automatic and non-automatic scenario).
Migration for such hierarchical attributes is the following:

  1. Ensure attribute concept described in AnnotationLinkDeclaration (target) is subconcept of one of NodeAttribute, LinkAttribute or PropertyAttribute depending on the attribute stereotype
  2. Define role concept property in attribute concept as attribute role in AnnotationLinkDeclaration
  3. If sourceCardinality was * define multiple concept property in attribute concept
  4. Define attributed concept link from source in AnnotationLinkDeclaration

Migration to 2.0.1

1) To fix module dependencies, execute "Add missing imports" action on project