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.
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.
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
*.oclinecore metamodels are initialized by
*.oclstdlib OCL Standard Library definitions are initialized by
*.ecore, *.essentialocl, *.uml files or general use of the query API is initialized by
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:
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
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
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
This may be invoked with a null argument to install the registrations in the global EPackage.Registry rather than a specified local registry.
As of the Mars release, lightweight or heavyweight support for URIs is a construction option for
OCL.NO_PROJECTS gives lightweight support using only what is directly accessible in a conventional EMF ResourceSet and its delegate registries.
OCL.CLASS_PATH gives the heavyweight support enabling use of
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