2.0.0 I200312101532XL (13 Bugs)
Initial EMF 2.0 driver. Eclipse 3.0 (M5) based
Eclipse M5 includes breaking API changes which will require regeneration or equivalent hand modification of generated EMF editors.
Since JDK 1.4 dictates the JAXP default implementation,
all dependencies on the Xerces plugin have now been removed from the EMF (and XSD) plugins.
Use -Djava.endorsed.dirs to choose a JAXP implementation.
E.g., this command will run Eclipse with the implementation used historically:
eclipse.exe -vmargs -Djava.endorsed.dirs=plugins/org.apache.xerces_4.0.13
Migration from 1.1
Code regeneration of 1.1 projects is required. There are some breaking changes in this version, specifically in the handling of XML Schema based models. Details are provided below.
Improved XML Schema Support
The support for XML Schema has been significantly enhanced in EMF 2.0. Much more of the complexity of XML Schema is now supported,
including mixed and open content. In addition, special Ecore annotations are now supported that allow one to specify the
Ecore model properties that XML Schema cannot otherwise represent. The most significant changes are as follows:
-
Added interface FeatureMap to represent an arbitrary feature/value pairs which are used to represent mixed or open content (wildcards).
The XSDEcoreBuilder will produce features of this type for complex types with mixed content, for element and attribute wildcards,
and for complex (repeating) model groups. The eGet(), eSet(), etc., methods can be called directly for open content features, which will
then delegate to the appropriate feature map.
-
Added support for document roots. In EMF 1.1, a global element declaration was mapped to an EClass. In 2.0, every namespace will have a single special
EClass, by default named DocumentRoot, which contains a feature for every global element or attribute declaration in the namespace. These represent open
content features which may be used in feature maps corresponding to wildcards. An instance document based on an XML Schema will now
contain a single instance of the document root, exactly one feature of which will be set to contain the actual root element.
-
Two new packages, XMLTypePackage and XMLNamespacePackage, have been added to the ecore plugin. XSDEcoreBuilder by default maps all XSD built in data types
to a corresponding EDataType in the XMLTypePackage. It maps "xml" namespace components to a corresponding XMLNamespacePackage model element
in the XMLNamespace package.
-
A text element from a complex type with mixed content is represented in a feature map by an entry whose feature is one of the attributes
from the XMLTypePackage's DocumentRoot class (i.e., text, CDATA, or comment), and whose value is the text (String). Note that comments
and CDATA are only created if you specify the XMLResource.OPTION_USE_LEXICAL_HANDLER load option. A DocumentRoot also has mixed content
and therefore can capture the comments at the beginning of a document.
-
Added EObject.eContainingFeature(), which in the simple case returns the same as eContainmentFeature(). However, in the case of open content,
containmentFeature() will return one of the features in a FeatureMap (a document root of some package) while eContainingFeature() will return
the feature for the feature map itself.
-
A new FeatureMapUtil class holds various static utility methods and implementation classes.
-
A new interface ExtendedMetaData (and default implementation class BasicExtendedMetaData) encapsulates all the meta data in
an Ecore model and any XSD2Ecore EAnnotations it may have. The default XMLResource now uses this interface
to access the data it needs to customize a schema-based model's serialization/deserialization, instead of using the XMLMap/XMLInfo mechanism.
It is enabled using a new save/load option: XMLResource.OPTION_EXTENDED_META_DATA.
-
A set of Ecore namespace (http://www.eclipse.org/emf/2002/Ecore) annotation attributes are now supported in an XSD definition of an Ecore model:
-
ecore:instanceClass may appear in a simple type to specify the Ecore instanceClassName of the corresponding EDataType.
-
ecore:name is support on any named Component to override the name of the corresponding ENamedElement.
-
ecore:documentRoot can be used on a schema component to specify the name of the document root EClass (which is "DocumentRoot" by default).
-
ecore:package can be used on a schema component to specify the fully qualified Java package name.
-
ecore:nsPrefix on a schema component specifies the nsPrefix attribute the corresponding EPackage.
-
ecore:reference can be specified on either an attribute or element declaration to specify the target of the corresponding EReference. The value
must be a QName that resolves to a complex type within the schema.
-
In EMF 1.x, anyURI, IDREF, and IDREFS mapped to a reference to EObject. Now, instead, by default they map to the corresponding EDataType
in XMLTypePackage instead. This can be tailored using ecore:reference. This is illustrated by the library.xsd example which has been changed
to use ecore:reference annotation for the books and author references.
-
Preliminary support for feature maps has been added to ItemProviderAdapter. This will be changed in the near future with a more general
wrapping mechanism, that will support any feature as a child.
-
Added int UNSPECIFIED_MULTIPLICITY = -2 to ETypedElement. This is used to specify the upper bound of any feature in a document root.
-
Support easier tailoring for handling of xsi:schemaLocation. These changes are to handle more of the
testsuite cases at http://www.xml.com/lpt/a/2003/09/03/binding.html
OMG MOF 2 Support
Several changes have been made in EMF 2.0 to align Ecore better with the EMOF (Essential MOF) subset of the MOF 2 Specification.
The following changes are related to this feature:
-
Ecore model changes
-
Moved the unique, lowerBound, upperBound, many, and required attributes from EStructuralFeature to ETypedElement.
-
Added new ordered attribute to ETypedElement.
-
Added new derived attribute to EStructuralFeature.
-
Added new eStructuralFeatures reference to EClass. This change involves replacing the two black diamond containment references,
eAttributes and eReferences, with a single containment reference eStructuralFeatures. eAttributes and eReferences are now
readonly derived non-containment references; although the add() and addUnique() methods are still supported for them,
so that the parser can read old files. This method will be removed eventually; a warning message is printed to stderr when add() is called.
The Ecore XMI Resource will always serialize Ecore models using the new reference.
-
EMOF Resource
-
An EMOF Resource is now provided and can be used to read or write a serialized Ecore/EMOF model. The EMOF Resource is registered for the .emof URI suffix.
-
The Sample Ecore Model Editor can now edit .ecore or .emof files and supports Save As to convert between Ecore and EMOF serializations of a model.
-
The EMF Model Wizard now also supports import from either .ecore or .emof files.
-
Ecore features not included in EMOF are nested in xmi:Extension elements with extender equal to
the Ecore namespace (http://www.eclipse.org/emf/2002/Ecore).
Model Import Enhancements
-
XSD diagnostics are displayed in EMF Model Wizard if errors are encountered while loading a model from XML Schema.
-
The import from XML Schema now supports schemas embedded within a WSDL (.wsdl) file.
-
Import from XML Schema now supports specifying/importing multiple URIs at once.
-
The EMF Model Wizard now provides Select All and Deselect All buttons for selecting packages to import.
-
Support for specifying XML Serialization eAnnotations/ExtendedMetaData in Rose.
-
Support for specifying arbitrary Ecore eAnnotations in Rose.
-
Rose comments and XML Schema documentation annotations are now converted to documentation eAnnotations in Ecore,
and subsequently emitted into the generated JavaDoc.
-
Support for operation method bodies (EOperation eAnnotations, see below) in the Semantic pane for a Rose operation.
-
Improved RoseEcoreBuilder handling of EObject-typed attributes in a Rose model. Previously if you had an attribute of type EObject
but the Ecore package was not available, it produced an EAttribute with an EClass as its type, resulting in class cast exceptions.
-
Fixed JavaEcoreBuilder to handle closed/missing projects. Previously exceptions were thrown and quiet failure resulted.
-
JavaEcoreBuilder now computes usage closure. This fixes a problem with missing used GenPackages. The problem stems from missing
indirect dependencies and is fixed by computing the closure when a new package dependency is added. Packages used by the
package being used also need to be used.
New Generator options and function
This new function is preliminary and still subject to change. New features include:
-
You can now specify in the GenModel a different root base interface and impl class, instead of EObject and EObjectImpl.
-
You can suppress EMF ("E") APIs in the generated interfaces (i.e., generate List instead of EList, Map instead of EMap, etc.).
-
Generator now emits throws clause for EOperations that declare eExceptions.
-
eAnnotations can now be set on an EOperation to specify the method body to generate (instead of default "throw new UnsupportedOperationException();").
-
eAnnotations can now be set to specify documentation to be emitted into the generated JavaDoc.
Miscellaneous Bug fixes and Improvements
-
The bulk of the function in EObjectImpl and NotifierImpl has been moved to base classes BasicEObjectImpl and BasicNotifierImpl, which declare
no storage. EObjectImpl and NotifierImpl are simple subclasses that implement the default current behavior. Clients that have their own implementations
of EObject/InternalEObject are encouraged to extend from these Basic implementations so that future method additions won't break them.
-
Added interface InternalEObject.EStore. A "store" can be provided to an InternalEObject, in which case the implementation of dynamic features
will be delegated to the store, instead of the default dynamic (EPropertiesHolder) implementation.
-
Added wasSet() method to Notification for determining the old isSet state.
-
EcoreUtil.Copier refactored to support easier specialization in subclasses.
-
Changed EAnnotationItemProvider to include contents as children for EAnnotation.
-
Added the option XMLResource.OPTION_FORMATTED. When set to Boolean.FALSE, this will cause linebreak and indentation to be omitted.
The default is Boolean.TRUE, so it must be explicitly set to Boolean.FALSE to have an effect.
-
Generated editors no longer reload model for resource marker changes.
-
Improved error handling in EMFPlugin. Will now throw MissingResourceException instead of NullPointerException when properties are missing.
-
Generated editors now flush the command stack when discarding changes (unloading the resource).
-
Fixed LocalTransfer.nativeToJava to handle bad data. It now catches NumberFormatException and returns null in this case.
-
XMLResource's save (XMLSaveImpl) fixed to check for null namespace when saving prefixes.
-
Added new method XMLHelper.getPrefix(EPackage, boolean) that is shared by getQName(EPackage, String, boolean) and
getPrefix(EPackage), to ensure that the package is added to the helper's packages list when getPrefix is called directly first.
-
XMLSaveImpl changed update of prefix to namespace map to avoid getting notification of an entry being set to the value it already has.
-
XMLHandler support to resolve forward references early. If an Ecore model and an instance of that model need to be processed when they are both
in the same document, it's necessary to be able to resolve all the forward references in the Ecore model before it can be used to instantiate instances.
Hence it should be possible to do some of the processing currently in endDocument early. The new method handleForwardReferences() can be called to do this.
It delegates to a handleForwardReferences() overload which takes an isEndDocument argument, so the code for processing during endDocument() can now be
shared for use earlier.
-
Fixed improper handling of primitives in EcoreFactoryImpl.createEJavaClassFromString.
-
Support EMap.putAll(EMap). By supporting EMap.putAll() from another EMap we can preserve the overall order.
-
Fixed dynamic setting for container to check feature. The getter for a container dynamic setting was not checking that the feature is the correct one
and returned the container regardless of whether it was for the feature or not.
-
Fixed generator to not set ECLIPSE_SWT classpath variable to incorrect value when org.eclipse.swt and its platform-specific fragment have different version numbers.
-
Tuned method BasicEObjectImpl.eDerivedStructuralFeatureID(EStructuralFeature). Simple dynamic eGet() will be twice as fast now.