Eclipse Community Forums: OCL » Setting non-blank root/package URIs in Papyrus

Home » Modeling » OCL » Setting non-blank root/package URIs in Papyrus(Need workaround for https://bugs.eclipse.org/bugs/show_bug.cgi?id=516285)

Setting non-blank root/package URIs in Papyrus [message #1761125]

Sun, 07 May 2017 12:53

Eclipse User

RE: https://bugs.eclipse.org/bugs/show_bug.cgi?id=516285.

Since the bug is now RESOLVED/FIXED it seems best to ask this question in the forum.
The diagnosis suggests that a workaround is to set a non-blank URI at (at least) the model root.

We're using Papyrus 2.0.2 (details on config and repro are in the bug description).

Explicitly setting a non-blank URI for the root element of the CallCenter model in the repro project does not prevent the UnsupportedOperationException. Short of creating and distributing our own patch based on the git commit, is there an effective workaround we can use until M7?

(The reason the problem does not occur with the CarsAndDrivers model in the repro is that all model elements are immediately under the root element, not in a subordinate package. If we create a package and move the elements into it, we get the same UOE problem.)

I'm setting the URI by selecting the root element in the Papyrus Model Explorer and editing the URI property in the Properties View.

Thank you!

Re: Setting non-blank root/package URIs in Papyrus [message #1761172 is a reply to message #1761125]

Mon, 08 May 2017 10:29

Eclipse User

Hi

The expected policy is that the root Model/Package/Profile has a non-null URI and child Packages have distinct non-null names.

So replacing your null Model by a non-null value, and resetting the blank Package URI to no-URI should get you back to normal.

NB. Form editors can make it hard to distinguish null from blank. Touching the form field changes null to blank; presumably that's how you got a null value. EMF/UML editors have a reset to default icon that can revert. Not sure what Papyrus does. Alternatively delete uri="" in the XMI.

Regards

Ed Willin

Previous Topic:	Generating Java code for OCL constraints
Next Topic:	Evaluation of transformations with OCL

Goto Forum:

-=] Back to Top [=-

Current Time: Fri Jul 04 00:03:47 EDT 2025

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter