Re: [emf-dev] EMF 2.0 and 2.1 compatibility

[Ed Merks <merks@xxxxxxxxxx>]

Anuradha,

We generally prefer if you ask questions on the newsgroup.

There are very few things in EMF that we treat as purely internal.  In
particular, unless the package itself is called internal (and we only have
one of those), then we try to treat it as best as we can as general API,
including protected methods on implementation classes.  The EObject
hierarchy, including InternalEObject and BasicEObjectImpl's protected
methods, are kind of "sacred" so we can't and don't simply break
compatibility on those without risking major damage.  Same goes for the
Ecore APIs and the resource APIs; but you must extend the base classes and
we highly recommend you not extend Ecore, i.e., EModelElement or anything
below it.  In general, generated models should have no problems in an
updated runtime.  I believe that models generated for EMF 1.0 will still
work against even 2.3.  Of course the proof is in the testing and the
running results, but I don't think you have reasons for concern about basic
runtime components.


Ed Merks/Toronto/IBM@IBMCA
mailto: merks@xxxxxxxxxx
905-413-3265  (t/l 969)




                                                                           
             "Anuradha                                                     
             Weeraman"                                                     
             <aweeraman@gmail.                                          To 
             com>                      emf-dev@xxxxxxxxxxx                 
             Sent by:                                                   cc 
             emf-dev-bounces@e                                             
             clipse.org                                            Subject 
                                       [emf-dev] EMF 2.0 and 2.1           
                                       compatibility                       
             05/08/2007 06:13                                              
             PM                                                            
                                                                           
                                                                           
             Please respond to                                             
             Eclipse Modelling                                             
                 Framework                                                 
             <emf-dev@eclipse.                                             
                   org>                                                    
                                                                           
                                                                           




Hi,

We have an application that is based on EMF 2.0 that we would like to
have working with EMF 2.1. For the most part our application uses the
public EMF 2.0 APIs but there are places where we refer internal EMF
APIs. I would like to know if there are backward compatibility issues
in such a scenario.

One such internal interface that we've identified in our codebase is
InternalEObject which the Javadocs describe as:

"Any EObject is assumed to also implement InternalEObject, which
provides lower-level access that is not necessarily suitable for
general consumption but is required for maintaining the EMF support
mechanisms."

Does anyone know whether using InternalEObject breaks compatibility
between EMF 2.0 and 2.1? We are also in the process of identifying EMF
touchpoints to see whether we are using any internal APIs whose
implementation might change between versions. One problem that we've
run into is in determining whether an API is internal to EMF or not.
Apart from the naming conventions of prefixing "Internal" are there
any other guidelines to know which internal EMF classes we should not
use directly? Could someone refer me to the public APIs that are
guaranteed to be backwards compatible between EMF versions 2.1 and
2.0?

Thanks in advance.

Regards,
Anuradha
_______________________________________________
emf-dev mailing list
emf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/emf-dev