Hi Eric,
Comments below...
Am 06.01.2012 15:48, schrieb Eric Moffatt:
Ed, thanks a bunch....
Just to make sure I understand...
If there are issues they'll appear as compile errors against the offending
source once it's compiled with the latest EMF
correct ?
Yes. For example CDO offers two different integrations with EMF. One that requires regeneration of a model to insert an
abstract base class below BasicEObjectImpl, so that the new interface methods don't harm. Another one is based on
wrapper objects that implement InternalEObject directly. There we have these three methods:
/**
* @since 3.0
*/
public int eDerivedOperationID(int baseOperationID, Class<?> baseClass)
{
// Note: This causes a compiler error with EMF < 2.6M4!!! Ignore it or
update your target platform.
return instance.eDerivedOperationID(baseOperationID, baseClass);
}
/**
* @since 3.0
*/
public Object eInvoke(EOperation operation, EList<?> arguments) throws
InvocationTargetException
{
// Note: This causes a compiler error with EMF < 2.6M4!!! Ignore it or
update your target platform.
return instance.eInvoke(operation, arguments);
}
/**
* @since 3.0
*/
public Object eInvoke(int operationID, EList<?> arguments) throws
InvocationTargetException
{
// Note: This causes a compiler error with EMF < 2.6M4!!! Ignore it or
update your target platform.
return instance.eInvoke(operationID, arguments);
}
Would the proposed fix be to ensure that any EObject implementations follow the
rules you outlined below (i.e. extend an
existing EMF-supplied base class) ?
Yes.
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
Thanks again (and even more for using a larger font for my fogie eyes...;-)
Eric
From: Ed Merks <[email protected]>
To: Eclipse Modelling Framework <[email protected]>
Date: 01/06/2012 02:28 AM
Subject: Re: [emf-dev] EMF API changes in Indigo
Sent by: [email protected]
------------------------------------------------------------------------------------------------------------------------
Eric,
The only thing that jumps to mind is the addition of EObject.eInvoke, but
that's wasn't a breaking API change, except
for those who ignored the following documented constraint:
Implementations of EObject should extend _BasicEObjectImpl_
<eclipse-javadoc:%E2%98%82=org.eclipse.emf.ecore/src%3Corg.eclipse.emf.ecore%7BEObject.java%E2%98%83EObject%E2%98%82org.eclipse.emf.ecore.impl.BasicEObjectImpl>or
one of its derived classes because methods can and will be added to this API.
Even in cases where this constraint is violated, it's really more of a source
incompatibility than a binary
incompatibility, because nothing else in the framework itself relies on calling
this new method. As such, I imagine you
can use the latest EMF even with binaries compiled against EMF 1.0.
Cheers,
Ed
On 05/01/2012 10:19 PM, Eric Moffatt wrote:
Last year we were looking into running an existing product on top of Eclipse 4
and ran into a 'breaking API change'. As
I remember it the change was known and intentional (introduced in mid-Indigo)
but I can't seem to track down what it
actually was and what its implications would be...could someone point me
towards whatever information is available ?
Thanks in advance,
Eric
_______________________________________________
emf-dev mailing list
[email protected]_ <mailto:[email protected]>
_https://dev.eclipse.org/mailman/listinfo/emf-dev_
_______________________________________________
emf-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/emf-dev
_______________________________________________
emf-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/emf-dev
_______________________________________________
emf-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/emf-dev
