[Pivot] Incompatible API change in OCL 6.1.1

[eclipse-ocl-bot]

| --- | --- | | Bugzilla Link | 500089 | | Status | RESOLVED WONTFIX | | Importance | P3 normal | | Reported | Aug 22, 2016 15:36 EDT | | Modified | Sep 06, 2016 13:17 EDT | | Version | 6.1.1 | | Reporter | Christian Damus |

Description

There is no OCL 6.1.1 value available for the Version field, so I leave it 'unspecified'.

The org.eclipse.ocl.pivot bundle version 1.1.1.v20160808-1416 (OCL 6.1.1 pre-release) has an incompatible API change since the 1.1.0 version (OCL 6.1.0 release) that causes a new compilation error in the Papyrus sources.

The problem is that the

org.eclipse.ocl.pivot.utilities.OCL::createOCLHelper(EObject)

API method has added a 'throws ParserException' clause that is new. Client code that didn't previously catch this exception or some supertype thereof now fails to compile because it doesn't catch this checked exception.

I think this is not a binary compatibility problem for Papyrus installations that update to this OCL build but only a source incompatibility.

[eclipse-ocl-bot]

By Ed Willink on Aug 22, 2016 16:34

(In reply to Christian W. Damus from comment #0)

There is no OCL 6.1.1 value available for the Version field, so I leave it 'unspecified'.

I'll take another shot at finding out how to do Bugzilla admin; used to be easy; can't find it for the last few years...

I think this is not a binary compatibility problem for Papyrus installations that update to this OCL build but only a source incompatibility.

Since it is binary compatible, the API tools allow it, so technically not a bug, just a developer inconvenience.

The problem is that the

org.eclipse.ocl.pivot.utilities.OCL::createOCLHelper(EObject)

API method has added a 'throws ParserException' clause that is new. Client

Problem derives from the fix for:

[496251] Support UML elements for OCLHelper methods

Looking at the code, it seems that the exception throw can be deferred from constructor to consumer restoring source compatibility.

[eclipse-ocl-bot]

By Ed Willink on Aug 22, 2016 16:48

(In reply to Ed Willink from comment #1)

(In reply to Christian W. Damus from comment #0)

There is no OCL 6.1.1 value available for the Version field, so I leave it 'unspecified'.

I'll take another shot at finding out how to do Bugzilla admin; used to be easy; can't find it for the last few years...

Found it. Just need to read the words on https://dev.eclipse.org/committers/bugs/bugz_manager.php n=more carefully.

[eclipse-ocl-bot]

By Christian Damus on Aug 22, 2016 16:49

Thanks, Ed. This needn't be a priority. I thought I should raise it in case it was an oversight that you'd like to fix, especially as it's in the maintenance branch. If this change was deliberate and you'd rather keep the API as is, I'm sure that Papyrus will be happy to adapt.

[eclipse-ocl-bot]

By Ed Willink on Aug 22, 2016 17:55

(In reply to Ed Willink from comment #1)

Looking at the code, it seems that the exception throw can be deferred from constructor to consumer restoring source compatibility.

Mostly ok, initialize can occur lazily in createXXX with a ParserException.

But if user first calls getContextClass without a lazy initialize(), we have to wrap the ParserException as an IllegalStateException.

---

But what is actually useful? The EMF way is to hide problems in some Resource.errors where they are ignored. But if we try to parse OCL on a rubbish model surely a ParserException is better than silence?

I'm inclined to take the view that clients should take the opportunity to alert the user to a problem. (Or just ignore the exception for minimal effort and minimal utility.)

[eclipse-ocl-bot]

By Christian Damus on Aug 22, 2016 18:00

(In reply to Ed Willink from comment #4)\

But what is actually useful? The EMF way is to hide problems in some Resource.errors where they are ignored. But if we try to parse OCL on a rubbish model surely a ParserException is better than silence?

Even so, EMF does throw an exception signalling the first of the problems recorded in the resource errors list.

I'm inclined to take the view that clients should take the opportunity to alert the user to a problem. (Or just ignore the exception for minimal effort and minimal utility.)

+1

[eclipse-ocl-bot]

By Ed Willink on Sep 06, 2016 13:17

(In reply to Christian W. Damus from comment #5)

+1