Description:
| Removing the implementation of
the ILogicalResource API from the org.eclipse.gmf.runtime.emf.core plug-in.
The following APIs are deprecated and, mostly, no longer have any effect
(within the limits of the contract):
Package org.eclipse.gmf.runtime.emf.core.resources:
- ILogicalResource: the interface is
deprecated. Note that the canSeparate() method now always returns
false and getMappedResources() always returns an empty map.
- ILogicalResourcePolicy: the interface
is deprecated. Logical resource policies are no longer constructed
or invoked by the system.
- CannotSeparateException, CannotAbsorbException
classes are deprecated.
- AbstractLogicalResource, AbstractLogicalResourcePolicy
classes are deprecated. No longer support separation or the resource
map
Package org.eclipse.gmf.runtime.emf.core:
- Event types: the ABSORB, SEPARATE,
and LOAD event types are deprecated. Notifications of these types
are no longer fired.
Package org.eclipse.gmf.runtime.emf.core.edit:
- MFilter: the SEPARATED_ABSORBED and
ELEMENT_LOADED filters are deprecated.
- MEditingDomain: the isLogicalResource()
and asLogicalResource() methods are deprecated, but still implement their
contracts.
- IDemuxedMListener2: the handleElementAbsorbedEvent(),
handleElementSeparatedEvent(), and handleElementLoadedEvent() callbacks
are deprecated.
- DemuxedMListener: the default implementations
of the deprecated IDemuxedMListener2 methods are deprecated.
- MResourceOption: the LOAD_ALL_SUBUNITS
and DONT_AUTO_LOAD_SUBUNITS load options are deprecated and no longer have
any effect.
Package org.eclipse.gmf.runtime.emf.core.util:
- ResourceUtil: the isLogicalResource()
and asLogicalResource() methods are deprecated, but still implement their
contracts.
- EObjectContainmentLoadingEList and EObjectContainmentWithInverseLoadingEList
are deprecated and no longer peform auto-loading of elements (as there
are no longer any separate elements)
Extension point org.eclipse.gmf.runtime.emf.core.resourcePolicies:
- the extension point is deprecated and is
no longer consulted by the runtime
|
New API Availability:
| EMF 2.2 M3 and M4 already include the cross-resource
containment support via proxy resolution in containment references.
|
Old API Removal:
| 31 January 2006 (early in M5 milestone)
|
Tracking:
| Bugzilla
113863
|
Clients Migrated:
| GMF, including examples. Migration
consisted of removing usage of the deprecated APIs, not updating the code
to use EMF cross-resource containment.
|
Other Clients' Actions:
| Update your code to use EMF's cross-resource
containment capability, as described in Bugzilla
105937 if your metamodel supports
proxy resolution in any of its containment references. In either
case, discontinue use of the APIs listed above.
To "separate" an object that is contained by a reference that
resolves proxies (i.e., has isResolveProxies() == true), simply add it
to the contents of another resource. When the two resources are saved,
an href is saved in the first resource that references the root element
of the second resource, which then actually stores the object and its contents.
This has the following corollaries:
- the cross-resource-contained object is still
contained by its eContainer() object, not by the resource contents, though
it appears in two lists that behave like containment lists
- the object has a different eResource() than
its eContainer()
- the object is in its container's eContents()
but not in its eProperContents()
Objects can only be "separated" if they are contained in references
that declare (in the ecore model) that they resolve proxies. Note
that this requires explicit support from the metamodel.
To "absorb" a separated element, simply remove it from the contents
list of the resource that stores it. It will continue to be contained
by an eContainer() object, and will be stored with it the next time it
is saved.
EMF's cross-resource containment does not support the separation of root
elements of a resource. It also does not implement a "logical
resource"; all resources are top-level resources in the resource set
and are merely interconnected by containment cross-references as has always
been the case with non-containment references. |