Currently the OCL Standard Library EPakcage for 'org.eclipse.ocl.ecore' has an URI Mapping defined:
<extension
point="org.eclipse.emf.ecore.uri_mapping">
<mapping
source="http://www.eclipse.org/ocl/1.1.0/oclstdlib.ecore"
target="platform:/plugin/org.eclipse.ocl.ecore/model/oclstdlib.ecore">
</mapping>
</extension>
In order to perform model transformations such as QVTc2ATC, it needs to be registered, e.g., via an extension:
<extension
point="org.eclipse.emf.ecore.dynamic_package">
<resource
location="model/oclstdlib.ecore"
uri="http://www.eclipse.org/ocl/1.1.0/oclstdlib.ecore">
</resource>
</extension>
But this extension is not part of the official plugin. The registration should be relocated somewhere else so as not to clutter the global EPackage.Registry.
The same problem affects the QVT Operational Mappings Standard Library.
This registration should not be done in any of the VM plugins.
The QVT Model Registry could be used to locate it, but forces the user to take action.
So far the OCLStandardLibrary has not been registered straight into the global registry. This means that the need for that reduces to model transformation activities. Therefore it should not pollute the global registry.
We should attempt to register it into the VM's ResourceSet. This should be performed in a neutral way. That is, no dependencies from the VM's projects should take place in order to achieve this. That's the way to go.
One thing that cannot be forgotten is that it should not change after Eclipse has started. As has been said, otherwise you get strange behaviours whereby doing something works in one way then when you do it again it works in another. Just imagine that an editor changes it, during a build, at the same time as some transformation activity occurs in the background; totally irreproducible problems. And of course changes to a registry are probably not guarded by a suitable "finally" that works even when something crashes.
This would not apply in the current case, since the org.eclipse.ocl.ecore plugin is required to be present at all times in order for translation transformations involving OCL to work. This means that the OCL Standard Library dynamic registration mentioned via an extension that we want to eliminate happens during Eclipse startup and is never modified by anybody during the Eclipse session's lifetime.