Community
Participate
Working Groups
To get a Model Repository started in Papyrus, the most common use case is expected to be the migration of models that already exist in some other team system (SVN, Git, etc.) into the repository. In such cases, the models exist in some workspace and need to be imported thence. Papyrus models can have dependency relationships: models can import packages from various other models in the workspace, in addition to plugin-deployed library models. The import wizard should account for these dependencies and encourage the user to import, for any Papyrus model that the user intends to import, also * [strongly recommended] models that reference (import) the imported model. If referencing models are not imported into the workspace, then it will be difficult to continue using them because they will still depend on the now obsolete copies of the models in the workspace * [recommended] models that are referenced (imported) by the imported model. If these models are left in the workspace, they can still be maintained and the models in the repository that reference them are OK as long as the user's workspace that is connected to the repository has the referenced models still in the correct projects. But, it is nonetheless recommended to import the entire connected web of models as a closure of dependencies The import wizard will show these dependency relationships and alert the user accordingly when dependent/required models are not being imported. Models are imported in their entirety, including the *.di resource and all of its hangers-on for notation and semantics. The wizard by default maps models in the workspace to resources in the repository with the same paths as the workspace models (where the path is relative to the workspace, including the project. Thus, for example, a model /MyProject/folder1/model.di is by default mapped to a resource /MyProject/folder1/model.di in the repository. This is configurable by the user (which is actually required in the case that such resource already exists in the repository). An option also is to combine all models being imported into a single model in the repository.
I'll take this bug, as I am already working on this feature.
r10117 has the initial implementation of the model import back-end: * import configuration * resource mappings * importer process supporting both one-to-one model mappings (each source model imported separately into the repository) and many-to-one mappings (all source models imported into one combined model in the repository). Validation of the import includes: * (error) destination repository not specified or not connected * (error) mapping not specified for some source model * (error) resource already exists in repository for a mapping * (warning) dependent model of an imported model is not being imported * (info) model referenced by an imported model is not being imported
r10137 has an initial cut of the Model Import Wizard. It comprises three pages: 1. Model Cross-References: shows cross-reference dependencies and dependents of the models selected in the Project Explorer. The user can include/exclude dependencies and dependents here. This sets up the IModelImportConfiguration for the import operation. 2. Repository: lets the user select the repository to import into. If the repository isn't connected, this page connects automatically. 3. Mappings: [optional] lets the user customize the mapping of workspace models to paths in the repository. The default mappings match the workspace-relative paths of the models to be imported. The user may also opt to combine all of the imported models into one model in the repository. This sets up the IModelImportMappings for the import operation.
r10380 This enhancement has been merged to the trunk.
