Community
Participate
Working Groups
Assume a model defined in another tool which uses datatypes, in a different model, also defined in the same other tool (not UML Primatives, but instead UML Datatypes). Now I now import the model defining the datatypes into Papyrus and then import the model using the datatypes into Papyrus. The latter will not use the datatypes of the former. Instead I will have a broken model. To fix the model I must manually replace all the references from the .x -> .uml The same is the case for UML dependencies.
See Bug 418644 It provides a Refactor > Switch package imports menu, which is used to reconnect the right imported models (However, I just noticed that this menu has been broken recently; it's been fixed with commit 31628da on master, so you'll need to update to the nightly build in ~30 minutes)
As a matter of interest is there a use-case where someone would want to run this but not in a Model Import context? I'm wondering if this functionality should be subsumed into the importer. The import process is too complicated right now and this could simplify it.
(In reply to Ronan B from comment #2) > As a matter of interest is there a use-case where someone would want to run > this but not in a Model Import context? I'm wondering if this functionality > should be subsumed into the importer. The import process is too complicated > right now and this could simplify it. I think there is. I can see that you would like to switch from a registered package/library import to a local one during development of the library. However that shouldn't prevent the package switch from being integrated into the model import. I'd like to see the following workflow when importing a foreign model: 1. import the model into Papyrus format 2. repair any broken stereotype applications 3. initiate package switching 4. clean up, e.g dangling old profile applications
Just to clarify this bug is not fixed. The solution in comment #2 suggests using the Refactor > Switch package imports menu. This has no effect on the scenario described in comment #1 as i'm not using a Package Import. There is an implicit dependency between model A and B. The import tool does not fix such dependencies.
> Just to clarify this bug is not fixed. The solution in comment #2 suggests using the Refactor > Switch package imports menu. This has no effect on the scenario described in comment #1 as i'm not using a Package Import. There is an implicit dependency between model A and B. The import tool does not fix such dependencies. This use case at least is now supported (The Switch Package Imports... has been replaced with a Switch Libraries which is not limited to PackageImport elements). But the action still needs to be automated during the model import operation, so the bug is still valid
Commit e2666ce (Maintenance/Luna) and b7877d9 (Master/Mars) attemps to solve the issue, by adding a new post-action when importing a set of EMX/EFX files. This post-actions repairs all the library dependencies between the selected files. Note that the emx -> uml mapping is not retained after the migration is complete. This means that all the models/libraries need to be imported in one step. The main issue with this approach is that it probably won't play well with the parallel import of all selected models (Especially, there is an important risk of saturating the memory). Depending on the feedback, I already have some leads to improve that (But I don't have any big enough model with a lot of libraries to test by myself) In the same commit, there are also a few minor improvements: - The menu has also been improved, it now appears as soon as at least one EMX/EPX file is selected (Even if *.efx or other unrelated files are selected). This makes it easier to import a set of files, since you can now select everything (instead of filtering out every non-emx file) - The progress bar has been improved and is now quite accurate
New set of commits on the Master and Maintenance branches: - The dependencies which can't be automatically migrated (i.e. are not part of the set of imported models) are now displayed during the transformation, with a "Switch Library"-like dialog (Common to all the imported models) The bugs of the Switch Library... action are also present in this one (Especially Bug 445091)
Two new commits on Master and Maintenance: - The Dependency Mapping heuristic has been improved to also explore statically registered libraries (Libraries which have been imported, then deployed in a plug-in) - Added a new parameter to automatically accept all heuristic mappings (In order to avoid a blocking dialog requesting a user confirmation in the middle of the transformation). This option is not active by default This solves the Library Dependency resolution issues (Although further usability improvements can still be implemented)
