Home » Modeling » Papyrus » Upgrading of model to use new version of UML Profile
| Upgrading of model to use new version of UML Profile [message #1704007] |
Thu, 06 August 2015 15:22  |
 Andreas Jakobik
Messages: 12
Registered: November 2011 |
Junior Member |
|
|
Hi,
I'm using Eclipse Luna SR2 and Papyrus 1.0.2.v201504030953.
My question/problem concerns how to upgrade a model that has a UML profile X version 1.0.0 applied to use a later version, say 1.0.1 of the same UML profile.
We provide the profiles as plugins and use pathmaps to address them. Opening the old model in an eclipse with profile X v 1.0.1 seems to be fine, since the profile version displayed is 1.0.1. However, selecting a model element that should have an new stereotype property (that was introduced in latest profile), then an exception is thrown, as shown below (property1 is the new property in the new profile version):
java.lang.IllegalArgumentException: property1
at org.eclipse.uml2.uml.internal.operations.ElementOperations.getValue(ElementOperations.java:565)
at org.eclipse.uml2.uml.internal.impl.ElementImpl.getValue(ElementImpl.java:297)
at org.eclipse.papyrus.uml.profile.tree.objects.AppliedStereotypePropertyTreeObject.getValue(AppliedStereotypePropertyTreeObject.java:125)
at org.eclipse.papyrus.uml.profile.tree.objects.AppliedStereotypePropertyTreeObject.createChildren(AppliedStereotypePropertyTreeObject.java:93)
at org.eclipse.papyrus.uml.profile.tree.objects.ParentTreeObject.getChildren(ParentTreeObject.java:114)
at org.eclipse.papyrus.uml.profile.tree.ProfileElementContentProvider.hasChildren(ProfileElementContentProvider.java:121)
at org.eclipse.jface.viewers.AbstractTreeViewer.isExpandable(AbstractTreeViewer.java:2141)
at org.eclipse.jface.viewers.TreeViewer.isExpandable(TreeViewer.java:553)
at org.eclipse.jface.viewers.AbstractTreeViewer.isExpandable(AbstractTreeViewer.java:2171)
at org.eclipse.jface.viewers.AbstractTreeViewer.updatePlus(AbstractTreeViewer.java:2863)
at org.eclipse.jface.viewers.TreeViewer.updatePlus(TreeViewer.java:804)
at org.eclipse.jface.viewers.AbstractTreeViewer.createTreeItem(AbstractTreeViewer.java:844)
at org.eclipse.jface.viewers.AbstractTreeViewer$1.run(AbstractTreeViewer.java:818)
at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:70)
at org.eclipse.jface.viewers.AbstractTreeViewer.createChildren(AbstractTreeViewer.java:791)
at org.eclipse.jface.viewers.TreeViewer.createChildren(TreeViewer.java:611)
at org.eclipse.jface.viewers.AbstractTreeViewer.createChildren(AbstractTreeViewer.java:762)
at org.eclipse.jface.viewers.AbstractTreeViewer.handleTreeExpand(AbstractTreeViewer.java:1495)
at org.eclipse.jface.viewers.TreeViewer.handleTreeExpand(TreeViewer.java:903)
at org.eclipse.jface.viewers.AbstractTreeViewer$4.treeExpanded(AbstractTreeViewer.java:1507)
at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:132)
at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
at org.eclipse.swt.widgets.Display.sendEvent(Display.java:4353)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1061)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1085)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1070)
at org.eclipse.swt.widgets.Tree.wmNotifyChild(Tree.java:7633)
at org.eclipse.swt.widgets.Control.wmNotify(Control.java:5618)
at org.eclipse.swt.widgets.Composite.wmNotify(Composite.java:1935)
at org.eclipse.swt.widgets.Control.WM_NOTIFY(Control.java:5169)
at org.eclipse.swt.widgets.Control.windowProc(Control.java:4666)
at org.eclipse.swt.widgets.Display.windowProc(Display.java:5023)
at org.eclipse.swt.internal.win32.OS.CallWindowProcW(Native Method)
at org.eclipse.swt.internal.win32.OS.CallWindowProc(OS.java:2443)
at org.eclipse.swt.widgets.Tree.callWindowProc(Tree.java:1553)
at org.eclipse.swt.widgets.Tree.WM_LBUTTONDOWN(Tree.java:6501)
at org.eclipse.swt.widgets.Control.windowProc(Control.java:4646)
at org.eclipse.swt.widgets.Tree.windowProc(Tree.java:6024)
at org.eclipse.swt.widgets.Display.windowProc(Display.java:5023)
at org.eclipse.swt.internal.win32.OS.DispatchMessageW(Native Method)
at org.eclipse.swt.internal.win32.OS.DispatchMessage(OS.java:2549)
at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3759)
at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$9.run(PartRenderingEngine.java:1151)
at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:1032)
at org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:148)
at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:636)
at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:579)
at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:150)
at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:135)
at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:134)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:104)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:380)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:235)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:648)
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:603)
at org.eclipse.equinox.launcher.Main.run(Main.java:1465)
at org.eclipse.equinox.launcher.Main.main(Main.java:1438)
If I manually remove the profile shown in the Profile tab when the model element is selected, and then add it again, everything is fine. The model has the new profile applied. However, this procedure is useless since all stereotypes also have to be reapplied, and their properties must be reentered.
Surely a smother upgrade must be supported?
Thanks alot!
/Andreas
|
|
|
| Re: Upgrading of model to use new version of UML Profile [message #1704900 is a reply to message #1704007] |
Mon, 10 August 2015 14:07  |
|
Hi, Andreas,
See some responses in-line, below.
HTH,
Christian
On 2015-08-06 15:22:31 +0000, Andreas Jakobik said:
> Hi,
>
> I'm using Eclipse Luna SR2 and Papyrus 1.0.2.v201504030953.
>
> My question/problem concerns how to upgrade a model that has a UML
> profile X version 1.0.0 applied to use a later version, say 1.0.1 of
> the same UML profile.
> We provide the profiles as plugins and use pathmaps to address them.
> Opening the old model in an eclipse with profile X v 1.0.1 seems to be
> fine, since the profile version displayed is 1.0.1.
Do you mean an old model with the 1.0.0 version of X applied? If the
1.0.1 version is applied, then there's nothing to migrate and the UI
should not run into exceptions.
> However, selecting a model element that should have an new stereotype
> property (that was introduced in latest profile), then an exception is
> thrown, as shown below (property1 is the new property in the new
> profile version):
This sounds like a bug: https://bugs.eclipse.org/bugs/show_bug.cgi?id=474610
> java.lang.IllegalArgumentException: property1
> at
> org.eclipse.uml2.uml.internal.operations.ElementOperations.getValue(ElementOperations.java:565)
>
> at
> org.eclipse.uml2.uml.internal.impl.ElementImpl.getValue(ElementImpl.java:297)
>
> at
> org.eclipse.papyrus.uml.profile.tree.objects.AppliedStereotypePropertyTreeObject.getValue(AppliedStereotypePropertyTreeObject.java:125)
>
> at
> org.eclipse.papyrus.uml.profile.tree.objects.AppliedStereotypePropertyTreeObject.createChildren(AppliedStereotypePropertyTreeObject.java:93)
>
> at
-------- 8< --------
>
> If I manually remove the profile shown in the Profile tab when the
> model element is selected, and then add it again, everything is fine.
> The model has the new profile applied. However, this procedure is
> useless since all stereotypes also have to be reapplied, and their
> properties must be reentered.
> Surely a smother upgrade must be supported?
Absolutely. Papyrus is supposed to prompt automatically when opening a
model, if any profiles are out-of-date, to migrate them. A dialog lets
you select which profile applications to migrate to the current
version. If you skip that step, you should later be able to migrate a
profile application to the latest version by hitting the little button
with the two yellow arrows in a circle formation. This migration
process preserves data in stereotype attributes that are still
compatible (having the same name as before, and a compatible data type
and range/enumeration).
As described in the bug report referenced above, it appears that the
handling of profile migration is completely broken now in Papyrus.
Because Papyrus thinks the latest version of the profile is applied,
the migration button is disabled. For now, you will have to open the
*.uml resource in the UML2 example editor and re-apply the profile in
that editor. Then save and re-open the *.di resource in the Papyrus
editor.
> Thanks alot!
> /Andreas
|
|
| |
| Re: Upgrading of model to use new version of UML Profile [message #1705069 is a reply to message #1704982] |
Tue, 11 August 2015 19:10 |
|
Hi, Andreas,
I don't know: as far as I recall of the Luna (1.0.x) release, this
function worked fine. It also worked at various stages of Mars (1.1)
development. It is only now, in investigating your scenario, that I
observed the problem in Mars.
Practically speaking, the Luna development stream is now closed, since
Mars has released (and, in fact, Papyrus even has its first service
release after Mars). Perhaps some accommodation can be made with the
Papyrus project or somebody for continuing support of Luna, but I
couldn't tell you what options there are or how they work.
The UML2 editor work-around is not equivalent to unapplying and
applying the profile again. That would lose all of your stereotype
data. The correct procedure in the UML editor is simply to apply the
same profile again that is already applied, without first unapplying
it. In this case, instead of creating a new profile application, UML2
updates the existing profile application and all stereotype
applications managed by it to the latest version of the profile (if the
profile application isn't already at the latest version). This
preserves all of your stereotype data that is still compatible with the
latest profile definition.
Cheers,
Christian
On 2015-08-11 09:08:03 +0000, Andreas Jakobik said:
> Hi Christian,
>
> Thank you for your reply. The bug report identifies Papyrus Core
> version 1.1.1, however the problem was already then in version 1.0.2.
> Will fix be back ported? If not we need to push for it. We need a
> working profile migration in Luna edition of Papyrus.
> The workaround using UML2 example editor amounts to the same thing as
> in using the Properties->Profile view and remove/add the profile,
> right? That is not an option, I'm afraid. Is there any other way we can
> handle profile migration programmatically? However, then we would
> basically have to code what the broken profile migration is supposed
> to do...?
>
> Thanks,
> Andreas
|
|
| |
| Re: Upgrading of model to use new version of UML Profile [message #1705151 is a reply to message #1705121] |
Wed, 12 August 2015 13:19 |
|
Hi, Andreas,
See some replies in-line, below.
HTH,
Christian
On 2015-08-12 09:26:44 +0000, Andreas Jakobik said:
> Hello Christian,
> Thanks for the clarifications.
> The workaround using the UML2 example editor should be good enough, but
> how do I open this editor? The closest match I find is the "UML Model
> Editor" which allows me to
Yes, that's the one. I call it the "example editor" because,
technically, it is only an example: it is not supported for production
use on the same level as the UML API, which is the UML2 project's
primary output.
> create a new child Profile Application, but I don't see how to reapply
> an existing one.
One never explicitly creates a Profile Application element (as far as I
am concerned, it shouldn't appear in the "New Child" context menu).
Instead, select a package and invoke the "Package -> Apply Profile..."
action in the "UML Editor" menu in the main menu bar. This lets you
re-apply a profile that is already applied to the selected package.
> (Please bear with me...)
>
> Moving to Mars may be an option, need to investigate some more first though.
>
> We definintely experence the profile migration issue on Luna, so it is
> stange you claim it was broken in Mars.
Well, I'm not looking at Luna any more because that's now out of
service, so I started by reviewing the problem in the Mars context and
was not pleased to find it there! I don't dispute that it may occur in
Luna, also. Note that it may be dependent on factors as yet
uncharacterized (it may work in some cases; I don't know).
> Thanks,
> Andreas
|
|
| | |
Goto Forum:
Current Time: Fri Apr 19 21:13:33 GMT 2024
Powered by FUDForum. Page generated in 0.03812 seconds |
] 
Search
Help
Register
Login
Home
