Pivot Standalone Configuration

Pivot Standalone Configuration

If you use Eclipse OCL within Eclipse, you should find that the appropriate registrations are provided for you automatically by the plugin registration mechanisms.

However if you use Eclipse OCL outside Eclipse, for instance in JUnit tests, basic configuration occurs automatically when you use some form of org.eclipse.ocl.pivot.utilities.OCL.newInstance(...) to create an OCL facade/handle. However optional facilities require further configuration by some of the following registrations in your code. Omission of required registrations is diagnosed by run-time messages.


These are elaborated on below.

UML support

As of the Mars release, support for UML is optional although omitting it in an Eclipse installation requires some effort to install Eclipse OCL without installing the org.eclipse.ocl.pivot.uml plugin. Standalone users must ensure that org.eclipse.ocl.pivot.uml is on the classpath and that the UML Abstract Syntax Resource Factory is registered. This is achieved by invoking org.eclipse.ocl.pivot.uml.UMLStandaloneSetup.init() before any significant OCL object construction occurs. Attempting to load UML models without UML support causes distinctive failures that are diagnosed by a recommendation to provide the preceding initialization.

Xtext Parsers

If you want to be able to convert any textual form of OCL to its internal pivot form you need to register the relevant parser.

*.ocl Complete OCL documents are initialized by CompleteOCLStandaloneSetup.doSetup().

*.oclinecore metamodels are initialized by OCLinEcoreStandaloneSetup.doSetup()

*.oclstdlib OCL Standard Library definitions are initialized by OCLstdlibStandaloneSetup.doSetup().

*.ecore, *.essentialocl, *.uml files or general use of the query API is initialized by EssentialOCLStandaloneSetup.doSetup().

Each of the above ensures that everything that it requires is installed. The various set ups can be found in one of the following packages:


OCL Standard Library

As of the Mars release, the default OCL Standard Library is automatically installed by a lazy invocation of org.eclipse.ocl.pivot.model.OCLstdlib.install() which installs a compiled shareable form of /org.eclipse.ocl.library/model/OCL-2.5.oclstdlib.

If you want to use an alternate library examine the code for the standard installation above, and if you want to compile your library examine the /org.eclipse.ocl.examples.build/src/org/eclipse/ocl/examples/build/GenerateOCLstdlibModel.mwe2 launcher for the /org.eclipse.ocl.examples.build/src/org/eclipse/ocl/examples/build/xtend/GenerateOCLstdlibXtend.xtend Xtend template.

Note that the library is extensible and importable so you may import your own library that in turn imports the standard library. /org.eclipse.qvtd.build/src/org/eclipse/qvtd/build/mwe2/GenerateQVTdLibraryModels.mwe2 demonstrates generation of an extended library.

If you provide a custom library that fails to meet the minimal requirements of defining the basic library types (e.g. Boolean, Set, Tuple) and methods (e.g. OclAny::“=”) you get an error such as “No 'Boolean' type in the OCL Standard Library”. The minimal library is /org.eclipse.ocl.examples.xtext.tests/src/org/eclipse/ocl/examples/test/xtext/models/minimal.oclstdlib.

Pivot Delegates

As of the Mars release, the EMF delegate registrations for textual OCL embedded within Ecore models are installed automatically. The registrations ensure that EMF get, call or validate activities dispatch the embedded OCL to the OCL delegates. The required registrations may be provided by OCLDelegateDomain.initialize(ResourceSet) from the org.eclipse.ocl.pivot.internal.delegate package.

This may be invoked with a null argument to install the registrations in the global EPackage.Registry rather than a specified local registry.

platform:/plugin and platform:/resource URIs

As of the Mars release, lightweight or heavyweight support for URIs is a construction option for org.eclipse.ocl.pivot.utilities.OCL.newInstance(...).

Using OCL.NO_PROJECTS gives lightweight support using only what is directly accessible in a conventional EMF ResourceSet and its delegate registries.

Using OCL.CLASS_PATH gives the heavyweight support enabling use of platform:/plugin/... or platform:/resource/... URIs in a standalone configuration. This is a costly activity that involves scanning the classpath and exploiting the content of any plugin.xml and MANIFEST.MF files that are found.


If your standalone environment supports OSGI bundles, as will be the case when you use Eclipse to launch a JUnit test or a transformation, the required plugin dependencies are easily configured in the MANIFEST.MF using JDT quick fixes, or the Manifest editor.

For a totally standalone Java launch, you must identify the exact spelling of each JAR that you require and identify it on your Java classpath. The Eclipse JARs may be found in the plugins folder adjacent to your eclipse.exe. So you may need org.eclipse.ocl.common_1.0.0.v20120516-1543.jar amongst many others. The required JARs can be recursively determined by looking at the Class Not Found Exceptions from the Java launch and locating the plugin with a similar name prefix. This is very tedious and has to be repeated each time you upgrade, so don’t do it. Use OSGI. However if you must, the following dependency trees may provide some clues.

The dependency tree for the basic parsing and evaluation is:


Additionally the UI requires


You may also need the Xtext, EMF, MWE, Orbit plugins and their dependencies