search

eclipse-ocl / org.eclipse.ocl

Eclipse Public License 2.0
0 stars 0 forks source link

[uml] UML 4.0.0/5.0.0 compatibility is an illusion #1552

Open eclipse-ocl-bot opened 2 hours ago

eclipse-ocl-bot commented 2 hours ago

| --- | --- | | Bugzilla Link | 469609 | | Status | NEW | | Importance | P3 normal | | Reported | Jun 08, 2015 06:10 EDT | | Modified | Jun 08, 2015 10:57 EDT | | Depends on | 469608 | | Reporter | Ed Willink |

Description

Attempting to install an RC4 candidate on a Juno modelling EPP as an OCL-only upgrade after already installing OCL for Juno is apparently successful. But starting any editor gives a failure ultimately due to an NPE as the UMLPackage is only in the EPackage registry for 4.0.0 and not 5.0.0.

Bug 469608 identifies why a 5.0.0 reference has been hard compiled into auto-generated EMF code.

In general any reference to UMLPackage.eNS_URI is not backward compatible., (There are 23 such non-test references affecting Classic and Pivot OCL.)

Cannot fix all these today for RC4.

However we must fix the UML failure infecting the non-UML Pivot functionality.

Option 1: adjust the plugin start() order so that the NPE causes a plugin start() failure before 'successfully' registering the UML pivot support. Consequence; a log entry for every start up. AERI will irritate us throughout Mars.

Option 2: raise the UML lowerbound to 5.0.0 so that the optionality of UML support just ignores the problem.

eclipse-ocl-bot commented 2 hours ago

By Ed Willink on Jun 08, 2015 10:57

(In reply to Ed Willink from comment #0)

Option 2: raise the UML lowerbound to 5.0.0 so that the optionality of UML support just ignores the problem.

But it's only optional from the plugin. Would need a separate Pivot UML feature to make the install optional. Changing features at RC4 is a really bad idea.

Option 1: adjust the plugin start() order so that the NPE causes a plugin start() failure before 'successfully' registering the UML pivot support. Consequence; a log entry for every start up. AERI will irritate us throughout Mars.

Maybe not. AERI may be our friend. AERI can provide the 'upgrade to UML 5.0.0' fix to everyone who hits the problem.

pushed to master for RC4.

====

For RC1, we could arrange to (auto-)edit UMLPackage.eNS_URI and TypesPackage.eNS_URI to use eNsURI().