Community
Participate
Working Groups
4.0.0M2 imported as source plugins. Open Types.uml with UML model editor and expand a few nodes. Bombs because the reference to <mergedPackage href="../../org.eclipse.uml2/model/PrimitiveTypes.xmi#_0"/> is not satisfied.
Did you import the org.eclipse.uml2 plug-in? I checked the source bundle for that plug-in and that file is there...
No, but shouldn't the wonders of URI resolution automatically load the JAR copy.
No, because the references are relative (as opposed to being platform URIs). Do you think making the references absolute would help in this case?
(In reply to comment #3) > No, because the references are relative (as opposed to being platform URIs). Do > you think making the references absolute would help in this case? GIT has made things much harder/more apparently difficult by fragmenting the typical workspace. "../.." to another project's plugins is now highly suspect for a naive resolver. But it seems to me that EMF provides the tools to make URI resolution work via EcorePlugin.platformResourceMap and ResourceSet.uriConverter.uriMap but expects applications to populate them without any further help. Hence the significant problems and inconsistent solutions in many modeling projects. Naive URI resolution works fine for simple developer tests, but needs a bit of tweaking for users and the tweaks fall apart under serious stress. MWE2 provides an interesting automation for standalone registrations by reconstructing the Eclipse plugin locations via a classpath scan, but does not fully exploit the discovery to solve the problem. I've recently taken this further so that a ProjectMap is derived from either the Platform bundles or classpath. The ProjectMap.initialize(ResourceSet) is then used to populate BOTH uriMap AND platformResourceMap so that both platform:/resource and platform:/plugin reference the resource if project or the plugin otherwise and this works whether running standalone or as a plugin. Once both platform:/resource and platform:/plugin work for EMF URI resolution, there is no need for applications to mess around with absolute locations C:/Mine/GIT etc and so ../.. can be sensible again. (Except that a URIConverter.toOSString() is still needed to provide the absolute reference to non-EMF tools.) I plan to contribute ProjectMap to EMF since it seems to solve a major problem. If the UML (or any generated) Editor used ProjectMap to initialize then all URIs may just work. So back to the question: The invoking context is platform:/resource/org.eclipse.uml2.uml.types/model/Types.uml" so EMF's deresolution of the target to "../../org.eclipse.uml2/model/PrimitiveTypes.xmi#_0" is fine provided platform:/resource and platform:/plugin are synonymous in ALL application contexts. ProjectMap supports this.
OK... resolving this as "WONTFIX" in UML2, then.
