Containers deletion in Refinement mode [message #1870995] |
Thu, 12 September 2024 10:14  |
Eclipse User |
|
|
|
I try to delete some packages (together with their content) from an UML model using an in-place transformation.
The point is that I got error messages that seem be raised by the deletion of their content. Basically I use a helper named "isInScope()" that returns a boolean: true if the element shall be kept, false if it shall be removed.
Not that any element that is not a root package inherits its "scope assessment" from its container, while there is a list of root packages that I want to keep in order to know what to do with them.
The deletion rule is the following:
rule removes {
from src: UML!Element (not src.isInScope())
}
Here is the kind of error I get:
org.eclipse.m2m.atl.emftvm.util.VMException: Error deleting Administration:UML!Package.ownedComment from 464fb35e:UML!Comment: Cannot invoke "org.eclipse.emf.ecore.resource.Resource.getContents()" because the return value of "org.eclipse.emf.ecore.EObject.eResource()" is null
The package named "Administration" referenced by this message shall actually be deleted together with its content. The text of this message is not that clear and I would tend to read this sentence in the other way (i.e. the comment cannot be removed for ownedComment) but maybe I missed the point...
How should I proceed to make it work?
|
|
|
|
|
|
|
|
|
|
|
|
Re: Containers deletion in Refinement mode [message #1871538 is a reply to message #1871361] |
Sun, 29 September 2024 16:28   |
Eclipse User |
|
|
|
Yves BERNARD wrote on Mon, 23 September 2024 11:34Dennis,
According to the console trace I can produce from the execution of the transformation based on that nightly built, it looks like all the classifiers are removed first, then all the properties, then all the packages. Is it intended? I would have expected removing the elements in the inverse order of their containment - whatever the nature of the element, since packages can have sub-packages, classes nested classifiers, etc...
Couldn't it have something to do with the issue?
The deletion process is a bit more complex than that. Model elements that are deleted by transformation rules are queued for deletion after all rules are executed. The deletion queue is then processed in two phases:
1. All incoming references to the to-be-deleted element are removed, for each to-be-deleted element.
2. All to-be-deleted elements are removed from their model (or Resource).
That means model elements are deleted in the order that you delete them in your transformation code, but deletion is delayed until rule execution has finished. This delay allows any code that tries to access deleted elements to still work, while the deleted elements will be removed afterwards.
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.52956 seconds