|
| Re: Problem with Papyrus Compare and an embedded profile? [message #1816927 is a reply to message #1816909] |
Tue, 12 November 2019 09:31   |
 Oliver Gardiner
Messages: 50
Registered: May 2014
Location: Oxford, UK |
Member |
|
|
Having gone back to earlier commits with an earlier version of the profile - but with all branches descendants of the same commit, it works as expected, i.e. not an issue with the Profile being embedded. My next guess is that this is caused by updating the profile on each branch independently after branching, e.g.:
Start point:
master uses Profile version 1.0.2
branch-a created as a new branch of master
Step 1:
Team member does some work on branch-a and commits.
At this point, branch-a and master can be compared using Papyrus Compare
Step 2:
Profile updated to 1.0.3
New profile definition applied to master when prompted.
master branch with Profile 1.0.3 committed back to repo
Step 3:
In order to merge, branch-a needs new Profile applied
branch-a with Profile 1.0.3 committed back to repo
While the models have the same Profile applied and should be comparable, comparison fails with the complaint "The definition of the Profile applied on <Model> branch-a has changed.".
My presumption is that this is caused by the fact that the new <profileApplication> declarations in each branch will be (e.g. different xmi:id values) as they have been updated independently - having said that, I have tried correcting this by hand without success!
If this analysis is correct then I guess we can have a work-around of forcing everyone to re-branch from the master as a large exercise every time we want to iterate the Profile but it would clearly be preferable to be able to just update the Profile on each branch without it breaking.
Any thoughts/correction much appreciated.
Thanks,
Oliver
|
|
|
| Re: Problem with Papyrus Compare and an embedded profile? [message #1816929 is a reply to message #1816909] |
Tue, 12 November 2019 10:30 |
|
Hi Oliver,
Papyrus Compare has only partial support for profile migration during the comparison (see bug 495259).
This support is mainly provided in the so-called ProfileMigrationHook, which will run through your models before the comparison and tries to migrate stereotype applications of stereotypes for which no definition can be resolved.
Profile definitions are searched based on the URI of the missing stereotypes package URI. See also class ProfileMigrationHook.
Note that this only works for static UML profiles that are registered -- it doesn't work for profiles that live in the workspace.
Anyway, diff/merge with evolving profiles is a tricky thing because you essentially change the metamodel when changing the UML profile, so within one comparison, you have to account for the change of possible attribute and reference values according to the metamodel. Sure, there are easy cases which can be supported (e.g. only additions), but it quickly becomes complex if you want to provide "full" support for that.
To be on the safe side, I would recommend to handle that issue, if possible, in a separate "organizational" process as you suggested (rebase open branches after each profile change or merge them before the profile migration).
Hope this helps!
Philip
--
Philip Langer
Get professional Eclipse developer support:
http://eclipsesource.com/en/services/developer-support/
|
|
|
Powered by
FUDForum. Page generated in 0.03774 seconds
] 
Search
Help
Register
Login
Home
