[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[mdt-uml2.dev] UML Standalone Initialization


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 correctly registered.

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 "platform:/resource/org.eclipse.uml2.uml.resources/profiles/" to 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 org.eclipse.ocl.examples.domain.utilities.StandaloneProjectMap, this 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 initialization ripple.


        Ed Willink