Community
Participate
Working Groups
Hi, I consider a model which has a static profile applied on it (named P) In MDT Papyrus for Control operation we reapply the profile P on a subpackage using the method Package.applyProfile(p); In org.eclipse.uml2.uml.internal.operations.PackageOperations the method getTarget calls the getNamedElement methods to get the corresponding definition to the UML element. In our case as the profile is static, the definition of the profile is not linked to an eannotation child of the eclassifier. This implies a NPE, the stack strace is available bellow. We suggest to add an if expression to return the eclass in parameter if getNamedElement returns null do you agree with this behavior ? @Override protected EClass getTarget(EClass eClass) { // OLD VERSION // return (EClass) profile.getDefinition(getNamedElement(eClass)); // NEW VERSION NamedElement namedElement = getNamedElement(eClass) ; if (namedElement != null) { return (EClass) profile.getDefinition(namedElement); } else { return eClass ; } } This bug is blocking Control Feature of MDT Papyrus so I evaluate this bug as "Major" The stack trace : Caused by: java.lang.NullPointerException at org.eclipse.emf.ecore.util.EcoreUtil.create(EcoreUtil.java:3270) at org.eclipse.uml2.uml.util.UMLUtil$StereotypeApplicationHelper.applyStereotype(UMLUtil.java:196) at org.eclipse.uml2.uml.util.UMLUtil.applyStereotype(UMLUtil.java:9045) at org.eclipse.uml2.uml.internal.operations.PackageOperations.access$0(PackageOperations.java:1) at org.eclipse.uml2.uml.internal.operations.PackageOperations$StereotypeApplicationCopier.createCopy(PackageOperations.java:120) at org.eclipse.emf.ecore.util.EcoreUtil$Copier.copy(EcoreUtil.java:472) at org.eclipse.uml2.uml.internal.operations.PackageOperations.applyProfile(PackageOperations.java:581) at org.eclipse.uml2.uml.internal.impl.PackageImpl.applyProfile(PackageImpl.java:1059) at org.eclipse.papyrus.controlmode.umlprofiles.helpers.ProfileApplicationHelper.duplicateProfileApplication(ProfileApplicationHelper.java:48) at org.eclipse.papyrus.controlmode.umlprofiles.commands.UMLProfileControlCommand.duplicateAppliedProfiles(UMLProfileControlCommand.java:71) at org.eclipse.papyrus.controlmode.umlprofiles.commands.UMLProfileControlCommand.access$0(UMLProfileControlCommand.java:68) at org.eclipse.papyrus.controlmode.umlprofiles.commands.UMLProfileControlCommand$1.run(UMLProfileControlCommand.java:47) at org.eclipse.uml2.common.edit.command.ChangeCommand.doExecute(ChangeCommand.java:65) at org.eclipse.emf.edit.command.ChangeCommand.execute(ChangeCommand.java:136) at org.eclipse.emf.common.command.CompoundCommand.execute(CompoundCommand.java:267) at org.eclipse.papyrus.controlmode.commands.ControlCommand.doRedo(ControlCommand.java:171) at org.eclipse.papyrus.controlmode.commands.ControlCommand.doExecuteWithResult(ControlCommand.java:120)
In the case where there is no annotation linking the Ecore class to its defining UML class (i.e., for static profiles), the getNamedElement(ENamedElement) is supposed to look up the definition by name after retrieving the profile from the (UML2) generated package registry: org.eclipse.uml2.uml.Package package_ = (org.eclipse.uml2.uml.Package) getNamedElement( ((EClassifier) definition).getEPackage(), context); if (package_ != null) { String name = definition.getName(); for (Type ownedType : package_.getOwnedTypes()) { if (safeEquals(getValidJavaIdentifier(ownedType.getName()), name)) { return ownedType; } } } Is this not happening in your case?
it is not the case it has been a surprised for me too, org.eclipse.uml2.uml.Package package_ = (org.eclipse.uml2.uml.Package) getNamedElement( ((EClassifier) definition).getEPackage(), context); This method returns null as the call to getProfile is made with context equals to null the execution order : org.eclipse.uml2.uml.internal.operations.createCopy(EObject eObject) --> org.eclipse.uml2.uml.internal.operations.getTarget(EClass eClass) --> org.eclipse.uml2.uml.util.getNamedElement(ENamedElement definition) --> org.eclipse.uml2.uml.util.getNamedElement(ENamedElement definition, EObject context) (context == null) --> org.eclipse.uml2.uml.util.getProfile(EPackage definition, EObject context) Regards
I see. Unfortunately, it's too late to fix this for Indigo, but we can do it in a maintenance release shortly thereafter. I don't think the proposed fix is correct; instead, I think a proper context needs to be passed to the getNamedElement(ENamedElement, EObject) method from the copier.
The fix has been committed to CVS.
The fix is available in 3.2.1 maintenance build M201108110857.
This fix appears to have been applied during the CVS to GIT transition. It appears in the read-only CVS but not in GIT for which the 3.2 maintenance stream is missing. It is not clear whether this fix has been applied to the master stream.
Did you notice behavior in UML2 4.0 that suggested this problem still exists? All of the changes that were made on the maintenance branch (in CVS) were made on the master branch (in git). I'll pursue the issue with the missing git branch in response to bug 372315.
I haven't noticed anything other than a newsgroup message that deserved an answer. It would be good if you could monitor at least the UML group for which the traffic is quite light (perhaps Papyrus too). I try to be helpful but my MDT/UML2 knowledge is fairly limited.
Thanks for the feedback, I'll try to do a better job of monitoring the newsgroup.
