The Object Constraint Language(OCL) is an expression language that can be used with Ecore to specify constraints, derived features and operation bodies. To make including OCL in models easier, a(nother) textual language has been designed for Ecore, which includes using the OCL syntax for constraints, derived features and operation bodies, in addition to a more Java-like syntax for the ordinary model elements. The custom OCLinEcore Editor supports this languages, while still using the standard XMI-based serialization of Ecore as storage format, so it interoperates nicely with other tools. This is different from Xcore's approach (see below), where the storage format is the same as the editor's language.

An example of the language is shown to the right. Almost at the bottom, the invariant keyword introduces the 'oneManager' constraint, where OCL is used for specifying the logic.

Note that support for OCL must be installed on top of the standard modeling package using the OCL Examples and Editors SDK feature from the main Eclipse installation site.

Xcore is a project that provides a textual notation for Ecore. Due to Xcore's architecture, you cannot just convert en Ecore model to text and start editing, you'll need to create an Xcore project from scratch using the Xcore project wizard. Then, create an "xcore" file using the Untitled Text File wizard, making sure to name it with the "xcore" file extension (you may need to type something to make the file dirty and saveable). Finally, right-click on the file and select Open With->Xcore Editor to get an editor supporting the Xcore syntax. Alternatively, you can close the original text editor and just double-click the file, since the Xcore Editor will be used by default.

A textual Xcore model corresponding to the models above is shown right. The syntax is similar to Java's, and with the proposals you get by typing ctrl-space it shouldn't be very difficult to learn the syntax. Or you can read https://wiki.eclipse.org/Xcore.

What makes Xcore different is that it actually replaces both ecore and genmodel files, i.e. both will implicitly be generated internally from the xcore file. In addition, the corresponding Java code will also be automatically generated in the src-gen forlder of the project, so the workflow is greatly simplified compared to how you otherwise need to create and open a Genmodel file and selected Generator->Generate Model Code for each model change, as described in the Genmodel page.

As mentioned, Xcore combines Ecore and Genmodel in one syntax. To see this, try opening the xcore file with Open With->Reflective Xcore Model Editor. This will give you a tree-based editor containing both Ecore and Genmodel models, as well as other, related models. This is shown in the figure to the right. The first (expanded) tree node named no.hal.org represents the Xcore textual structure (abstract syntax tree). The second node named Org represents the Genmodel model and the third one named org represents the Ecore model.

When loading an xcore file using the standard EMF API, the result is these three hierarchies having similar structure and corresponding objects, e.g. there will be an XClass instance, GenClass instance and EClass instance for each class in the model. Hence, if you have a tool that processes Ecore model elements, you can support both ecore and xcore files by simply searching for EPackages that are the container of Ecore model elements. Unfortunately, although Xcore corresponds to a combination of Ecore and Genmodel, not all tools that need ecore and genmodel files can use an xcore file instead.