eclipse-ocl / org.eclipse.ocl

Eclipse Public License 2.0
0 stars 0 forks source link

[es2as] Not all EReferences get opposites #1759

Closed eclipse-ocl-bot closed 2 hours ago

eclipse-ocl-bot commented 2 hours ago

| --- | --- | | Bugzilla Link | 507557 | | Status | RESOLVED FIXED | | Importance | P3 normal | | Reported | Nov 15, 2016 11:04 EDT | | Modified | Nov 16, 2016 05:01 EDT | | Reporter | Ed Willink |

Description

A fundamental premise of the Pivot is that all Class-typed Property elements have opposite Property elements.

ETypedElement.eGenericType has no opposite.

Only EReferences with http://schema.omg.org/spec/MOF/2.0/emof.xml or http://schema.omg.org/spec/MOF/2.0/emof.xml#Property.oppositeRoleName EAnnotations get opposites explicitly in Ecore2ASReferenceSwitch.caseEReference. Others are handled by PivotMetamodelManager.installPropertyDeclaration where a

// FIXME Are any exclusions justified?

annotates exclusion of transient, !derived volatile.

ETypedElement.eGenericType is a !derived volatile containment.

Are the exclusions justified?

eclipse-ocl-bot commented 2 hours ago

By Ed Willink on Nov 15, 2016 11:43

No. transient, derived, volatile are implementation details. They do not undermine the existence of the property in the model. The Pivot supports uniform navigation, therefore they should not be excluded.

No standalone OCL or QVTd JUnit tests fail.

One plugin OCL completion proposal test fails. Wierd, not obviously related. Repeatable as part of the full test suite. Not repeatable in isolation.

The extra opposites won't improve performance, but do they actually cause a problem?

eclipse-ocl-bot commented 2 hours ago

By Ed Willink on Nov 15, 2016 15:05

(In reply to Ed Willink from comment #1)

Not repeatable in isolation.

Needs most (? all) of OCLinEcoreTutorialExamples and UsageTests to still be reproducible in a smaller test suite. (25 tests).

Actual failure is that the third request for a proposal returns an erroneously empty array of proposals.

Some hints of a timing issue, but the first two worked, and it was the second that has to search the class path. Adding a fourth and the third still fails.

After instrumenting, the problem seems to be that JavaClassScope.doFullScan may be running before Java builds have finished. A clean test always finds 31636 class files, whereas a fail finds perhaps only 30562 and if we're unlucky a missing one was a completion proposal.

The many required preceding tests no doubt ensure a big enough Java build backlog to cause the problem. But why does this only happen once extra opposites are in use?

eclipse-ocl-bot commented 2 hours ago

By Ed Willink on Nov 15, 2016 17:24

(In reply to Ed Willink from comment #2)

But why does this only happen once extra opposites are in use?

It doesn't. It happened before. It's just the plugin tests have not been run much on M3.

(In reply to Ed Willink from comment #1)

One plugin OCL completion proposal test fails. Wierd, not obviously related.

Its a JDT M3 regression. Bug 507571.

eclipse-ocl-bot commented 2 hours ago

By Ed Willink on Nov 16, 2016 05:01

(In reply to Ed Willink from comment #3)

Its a JDT M3 regression. Bug 507571.

Doesn't seem to be a guaranteed fail on Hudson. If necessary Bug 507566 can suspend the test.

(In reply to Ed Willink from comment #1)

No. transient, derived, volatile are implementation details. They do not undermine the existence of the property in the model. The Pivot supports uniform navigation, therefore they should not be excluded.

Pushed to master for M4.