Child pages
  • Migration20

Versions Compared


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


What the migration will do with my code?

Upgrade Persistence


Fix Module Dependencies


Migrate Stub Models


Optimize Imports




Model Checker and manual references resolution




  1. execute tools-> internal -> Add Language Design Devkit To All Languages
  2. execute tools-> internal -> Add General Purpose Devkit to Language Models
  3. execute tools-> internal -> Remove Language Design Devkit from Models
  4. execute tools-> internal -> Remove BootstrapLanguages Devkit from Language Models
  5. execute tools-> internal -> Add Necessary ModuleDeps Everywhere


  1. Tools-> Update Stub Refs-> Update Language Accessories Refs
  2. Tools-> Update Stub Refs-> Re-resolve Stub Refs
  3. right-click on your project -> optimize imports
  4. Most of the references will be fixed at the moment. But a small amount of them can be left unresolved (if threre were illegal model imports which MPS was not able to find in previous versions). So, find all broken references left and fix them manually by adding necessary module dependencies. You can use Model Checker tool to find all broken references (right-click on project -> check models)


: Since MPS 1.5 we've changed the format in which models are stored on disk. Commonly this is a performance-related issue. This action will re-save all models and modules in your project in a new format.

Fix Module Dependencies: In MPS 1.5 we had some unclear dependencies especially in languages and language models. This action will reconsider module imports and change their structure (some devkits will be replaced with others)

Migrate Stub Models: If you tried to use different versions of the same library in older versions of MPS, you may know that MPS didn't handle such situation. References to stub models didn't contain any information about a place from where this model is. Now it also contains the ID of the module containing a model, so that you can use different versions of the same code with the only restriction - they should not be added as stubs to the same module. So, we need to update all the references to stub models from your code. MPS does it the following way: firstly, it tries to resolve the model in scope of current module using the old "partial" id. If it succeeds, the reference is then resolved. If this fails, MPS tries to resolve it globally and if this succeeds, add a corresponding module import and resolve the reference. Also, this action will correct model imports correspondingly.

Optimize Imports: This will remove dependencies on modules that don't exist in MPS anymore (and really unused dependencies, too)

Scripts: When we change language syntax, a common way of migrating the outdated code to the new syntax (where possible) is to provide a refactoring (we call this kind of refactorings "migration scripts" not to mix them with other types of refactorings) which will change old syntax to new one (if it's possible). This action will find all MigrationScript instances in MPS and execute those of them which have a "migration" type (there are also so-called "enhancement scripts", which will not be executed by this action).

Model Checker and manual references resolution: If you have used some internal API, or somewhy MPS couldn't resolve a stub reference or any other reference, you can correct them manually. This tool will help to find all such references.

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
  5. Perform actions from steps 1 and 2 for migrated attributes
  6. For simple attributes (when they are direct subconcepts of BaseConcept) migration script is available
  7. To make virtual packages (folders) visible again 
    1. Tools -> Scripts -> By Language -> jetbrains.mps.lang.core -> Restore Virtual Packages
  8. To convert TabbedEditors and icons in plugin aspects
    1. Tools-> Scripts-> By Language -> jetbrains.mps.lang.plugin -> split tabbed editors
    2. Tools-> Scripts-> By Language -> jetbrains.mps.lang.plugin -> Update Icons
  9. To migrate to the new trace information generation
    1. Tools -> Scripts->By Language->jetbrains.mps.lang.plugin->Upgrade Trace Info Generation
  10. Execute Tools->Scripts->By Language-> jetbrains.mps.baseLanguage.closures-> remove wildcards from unbound params
  11. Execute Tools->Scripts->By Language-> jetbrains.mps.baseLanguage.runConfigurations -> Fix References To Deleted Run Models
  12. Regenerate (!!! use "Rebuild" action, not "Make")
    1. all project languages
    2. all project solutions (!!! after languages)

Migration to 2.0.1

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