[UML] Validation fails for Association end constraint

[eclipse-ocl-bot]

| --- | --- | | Bugzilla Link | 513773 | | Status | RESOLVED FIXED | | Importance | P3 normal | | Reported | Mar 16, 2017 12:30 EDT | | Modified | Mar 16, 2017 15:45 EDT | | Version | 5.0.0 | | Reporter | Klaas Gadeyne |

Description

Created attachment 267298\ For reproducing

Consider the Papryus UML model in attachment:\ When validating, two validation errors occur

Severity Description Element Parent Type\ Error "Parsing error for RootElement::Structure::Class1::Constraint1::self.Attribute1 = self.Attribute2:\ Failed to load 'platform:/resource/Sandbox/umlOCLTest.uml.oclas' : null" self.Attribute1 = self.Attribute2 RootElement::Structure::Class1::Constraint1 EMF Problem\ Error No pivot for RootElement::Structure::Class1::Attribute2::Attribute1 Attribute1 ... RootElement::Structure::Class1::Attribute2 EMF Problem

When removing the association A_class1_activity1, both validation errors disappear, so it seems to be the association which is causing the trouble.

Tooling versions: Eclipse Neon.2, Papyrus nightly.

OCL Classic SDK: Ecore/UML Parsers,Evaluator,Edit 5.2.0.v20160523-1914 org.eclipse.ocl.all.sdk.feature.group Eclipse Modeling Project\ OCL Classic SDK: Ecore/UML Parsers,Evaluator 5.2.0.v20160523-1914 org.eclipse.ocl.core.sdk.feature.group Eclipse Modeling Project\ OCL Classic: Ecore/UML Parse,Evaluate,Edit 5.0.200.v20150611-1921 org.eclipse.ocl.edit.feature.group Eclipse Modeling Project\ OCL Documentation 3.6.0.v20160523-1150 org.eclipse.ocl.doc.feature.group Eclipse Modeling Project\ OCL User Interface 2.1.0.v20160521-2033 org.eclipse.ocl.ui.feature.group Eclipse Modeling Project\ Source for OCL Classic: Ecore/UML Parse,Evaluate,Edit 5.0.200.v20150611-1921 org.eclipse.ocl.edit.source.feature.group Eclipse Modeling Project\ Source for OCL Documentation 3.6.0.v20160523-1150 org.eclipse.ocl.doc.source.feature.group Eclipse Modeling Project\ Source for OCL User Interface 2.1.0.v20160521-2033 org.eclipse.ocl.ui.source.feature.group Eclipse Modeling Project

:compression: oclActivityAssociation.zip

[eclipse-ocl-bot]

By Ed Willink on Mar 16, 2017 13:32

When I wrap the example up as a JUnit test, a slightly better diagnostic appears:

junit.framework.AssertionFailedError: \ Unexpected errors\ "Parsing error for Bug513773::Structure::Class1::Constraint1::self.Attribute1 = self.Attribute2:\ Failed to load 'file:/E:/GIT/org.eclipse.ocl/tests/org.eclipse.ocl.examples.xtext.tests/bin/org/eclipse/ocl/examples/pivot/tests/models/Bug513773.uml.oclas' : org.eclipse.ocl.pivot.uml.internal.es2as.UML2ASDeclarationSwitch cannot be cast to org.eclipse.ocl.pivot.Element"\ No pivot for Bug513773::Structure::Class1::Attribute2::Attribute1 \ at junit.framework.Assert.fail(Assert.java:57)\ \ I think the improvement is post-Neon.

Anyway, the problem is that UML2ASDeclarationSwitch returns this to terminate the EcoreSwitch case hierarchy traaversal and eventually something casts to Element => CCE.

[eclipse-ocl-bot]

By Ed Willink on Mar 16, 2017 14:21

(In reply to Ed Willink from comment #1)

eventually something casts to Element => CCE.

The @SuppressWarnings("unchecked") in UML2ASDeclarationSwitch.doSwitchAll was unsound. Adding a != this test to handle the terminate EcoreSWitch search idiom and all is ok.

There are no other @SuppressWarnings("unchecked") in UML2ASDeclarationSwitch.

UML2ASReferenceSwitch uses the same idiom and has a similar unsound test. Fix it too.

Pushed to master for M7.

(This is a trivial local fix that could easily be backported if we do another Neon release.)

[eclipse-ocl-bot]

By Ed Willink on Mar 16, 2017 14:52

Fix available at

http://www.eclipse.org/modeling/download.php?file=/modeling/mdt/ocl/downloads/drops/6.3.0/N201703161424/mdt-ocl-Update-N201703161424.zip

[eclipse-ocl-bot]

By Klaas Gadeyne on Mar 16, 2017 15:34

(In reply to Ed Willink from comment #3)

Fix available at

http://www.eclipse.org/modeling/download.php?file=/modeling/mdt/ocl/ downloads/drops/6.3.0/N201703161424/mdt-ocl-Update-N201703161424.zip

Thx for the quick fix! I suppose this oxygen snapshot is not really meant for being used in Neon?

Is there still a SR3 release planned for Neon? Even a nightly build would be very convenient for me.

[eclipse-ocl-bot]

By Ed Willink on Mar 16, 2017 15:45

Neon.3 is done, no OCL changes at that point. No SR3 planned.

OCL 6.3 for Oxygen is a minor version change; changes are mostly supporting extensibility for QVTd. Oxygen builds should be fine on Neon, Mars or Luna, provided you are using Xtext >= 2.9.

https://wiki.eclipse.org/OCL/FAQ#Does_Eclipse_OCL_work_with_J2SE_1.4.3F