User-agent: Mozilla/5.0 (Windows NT 6.0; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
The Juno release of MDT/UML2 adds UML 2.4 and 2.4.1 support and
consequently many more namespaces whose content handlers need to be
When running within Eclipse, the magic of extension points should ensure
that this happens automatically.
When running standalone, these registrations have been a consumer
responsibility. Most modeling tools have emerged in the last few years
while UML2 has been stable with support for UML 2.2 and so the
complexities of multi-version support is easily overlooked in some
handcrafted UML initialisation code.
In the latest MDT/UML2 I-build, there is a UML standalone initialization
routine (https://bugs.eclipse.org/bugs/show_bug.cgi?id=364419). Just
invoke UMLResourcesUtil.init(null). This does all the hard work, and
should hide the next generation of changes for UML 2.5. Only the
physical location URI mappings are missing; i.e. from the resolution of
URI.createURI(UMLResource.PROFILES_PATHMAP); similarly for 'metamodels'
and 'libraries'. If you have automated plugin location, using classpath
analysis as performed by MWE2's StandaloneSetup scanPath, or
missing step may be done automatically as well.
A patch to upgrade org.eclipse.ocl.uml.OCL.initialize(resourceSet) to
call UMLResourcesUtil.init(resourceSet) is in the pipeline, so consumers
of OCL.initialize need take no action other than taking the opportunity
to remove their duplicate initializations.
Other tools are encouraged to start using UMLResourcesUtil.init(null) as
soon as possible so that any residual bugs are fixed for Juno, ensuring
that UML 2.5 can be introduced without a further downstream