HeikoKlare
commented
3 years ago I will have a look at it as soon as possible.
Closed jGleitz closed 3 years ago
HeikoKlare
commented
3 years ago I will have a look at it as soon as possible.
jGleitz
commented
3 years ago Thank you!
jGleitz
commented
3 years ago @HeikoKlare If you find the time to reproduce this, you can check out the branch execution-testing in my CBS fork.
If you execute tools.vitruv.applications.cbs.equivalencetests, you’ll see exceptions like the one below in the ‘renaming’ tests:
java.lang.IllegalArgumentException: Unhandled parameter types: [null]jGleitz
commented
3 years ago @HeikoKlare you’ll need to do this against my continue branch, otherwise, the CBS branch won’t compile. The continue branch also contains the changes of this branch.
jGleitz
commented
3 years ago Since I got all my changes in, you should be able to reproduce the problem directly from this branch, no need for the continue branch anymore.
HeikoKlare
commented
3 years ago I have now taken a look into this. The problem seems to be that when changing the URI of a resource, both the remove and insert root changes reference the new resource and contain the new URI. Unresolving the change removes the resource and only the URI remains. This URI is, however, invalid for the old state, which is why the change cannot be resolved in the VirtualModel. It then fails when resolving the change in this line.
HeikoKlare
commented
3 years ago Oh, well, and if you then replace in the PackageCreated reaction of Java2PcmClassifier.reactions the trigger inserted as root with created and inserted as root, you will also avoid to retrigger the reaction after moving a package and avoid the faulty user interaction coming up.
HeikoKlare
commented
3 years ago I've pushed changes that should resolve the URI problem and produce properly resolvable changes. @jGleitz Can you tell me whether the changes are fine for you now?
Please note that despite the improved recording, the way how the Reactions consider root element changes is often rather strange in the current implementations. For example, the Java2PCM transformation does not properly handle root element renamings, because the Reactions for their creation apply to these changes as well (as they do not check for creations). This is because the changes generated by the Java code monitor do not produce create changes right now. This is, of course, an inappropriateness in the Java code monitor. However, Reactions should usually not be run after creating an element anyway, but after setting all relevant properties that are necessary to propagate it (which is, in most cases, at least the element name). Thus, for example, the transformation of a package should not depend on its creation but on the initial setting of its name.
jGleitz
commented
3 years ago It seems that your changes did the trick :+1:
Let’s merge!
:warning: depends on #361 :warning:
Unfortunately, this does not work with change propagation. It breaks because the remove root change’s
EChangeis set tonullduring change propagation, which later yield anIllegalArgumentException. After hours of debugging, I still don’t understand what is going on.@HeikoKlare, can you help?