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, you should initialize the appropriate language support using at least one of.
org.eclipse.ocl.xtext.completeocl.
CompleteOCLStandaloneSetup.doSetup(); // *.ocl
org.eclipse.ocl.xtext.essentialocl.
EssentialOCLStandaloneSetup.doSetup(); // *.essentialocl
org.eclipse.ocl.xtext.oclinecore.
OCLinEcoreStandaloneSetup.doSetup(); // *.ecore, *.oclinecore
org.eclipse.ocl.xtext.oclstdlib.
OCLstdlibStandaloneSetup.doSetup(); // *.oclstdlib
Failure to initialize language support usually results in one of the following diagnostics.
No OCL Standard Library content available
No 'XXX' type in the OCL Standard Library
If you want to use UML models, the optional functionality must be activated.
org.eclipse.ocl.pivot.uml.UMLStandaloneSetup.init(); // *.uml
The following initializations that were once recommended should happen automatically.
org.eclipse.ocl.pivot.OCL.initialize(resourceSet);
org.eclipse.ocl.pivot.uml.internal.es2as.
UML2AS.initialize(resourceSet);
org.eclipse.ocl.pivot.model.OCLstdlib.install();
org.eclipse.ocl.pivot.internal.delegate.
OCLDelegateDomain.initialize(resourceSet);
org.eclipse.ocl.pivot.internal.resource.
StandaloneProjectMap.getAdapter(resourceSet);
These are elaborated on below.
For the Pivot metamodel, the required registrations should be provided by invoking
org.eclipse.ocl.pivot.OCL.initialize(ResourceSet)
. This initialization ensures that *.ecore is understood.
If *.uml support is also required, invoke
org.eclipse.ocl.pivot.uml.internal.es2as.UML2AS.initialize(ResourceSet)
as well.
This initialization ensures that *.uml is understood and that standard pathmap: locations are resolvable. It also invokes
org.eclipse.uml2.uml.resources.util.UMLResourcesUtil.init(ResourceSet)
to ensure that all Eclipse and OMG UML namespaces and extensions are registered.
If you want to use the default OCL Standard Library you should invoke
org.eclipse.ocl.pivot.model.OCLstdlib.install()
which installs a compiled shareable form of
/org.eclipse.ocl.pivot/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.
If you neglect to install an OCL Standard Library, you get the error “No OCL Standard Library content available”. If you provide a custom library that fails to meet the miinimal 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”.
If you have textual OCL embedded within Ecore models you need to register the EMF delegates so that EMF gets, calls or validates 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.
If you neglect to register delegates before generated EMF classes are initialized, you may get an NPE or an error of the form "An exception occurred while delegating evaluation of the ..."
If you want to be able to convert any textual form of OCL to its internal pivot form you need to initialize 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:
org.eclipse.ocl.xtext.completeocl.
org.eclipse.ocl.xtext.essentialocl.
org.eclipse.ocl.xtext.oclinecore.
org.eclipse.ocl.xtext.oclstdlib.
If you want to be able to use
platform:/plugin/...
or
platform:/resource/...
URIs in a standalone configuration you need to configure the EMF package and URI map registries appropriately. 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.
org.eclipse.ocl.pivot.internal.resource.StandaloneProjectMap.getAdapter(resourceSet);
creates a
StandaloneProjectMap
to cache all the scan results, initializes the ResourceSet and installs itself as an adapter on the ResourceSet so that it can be retrieved again if needed. Users are strongly recommended to ensure that a single
StandaloneProjectMap
is shared by all clients and so avoid incurring the classpath scan cost more than once.
(The
StandaloneProjectMap
has no OCL-specific functionality; it just cures a major problem in the standalone usage of EMF.)
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:
org.eclipse.ocl.common
org.eclipse.ocl.pivot
org.eclipse.ocl.xtext.base
org.eclipse.ocl.xtext.essentialocl
org.eclipse.ocl.xtext.completeocl
org.eclipse.ocl.xtext.oclinecore
org.eclipse.ocl.xtext.oclstdlib
Additionally the UI requires
org.eclipse.ocl.common.ui
org.eclipse.ocl.examples.markup
org.eclipse.ocl.examples.markup.ui
org.eclipse.ocl.xtext.essentialocl.ui
org.eclipse.ocl.xtext.completeocl.ui
org.eclipse.ocl.xtext.oclinecore.ui
org.eclipse.ocl.xtext.oclstdlib.ui
org.eclipse.ocl.examples.xtext.console
org.eclipse.ocl.pivot.ui
You may also need the Xtext, EMF, MWE, Orbit plugins and their dependencies
com.google.guava
com.google.inject
org.apache.log4j
org.eclipse.emf.common
org.eclipse.emf.ecore
org.eclipse.emf.codegen
org.eclipse.emf.ecore.xmi
org.eclipse.xtext
org.eclipse.xtext.common.types
org.eclipse.xtext.common.types.ui
org.eclipse.xtext.ui
org.eclipse.xtext.ui.shared
org.eclipse.xtext.util