Bug 361063

Comment 1 Ed Willink 2011-10-15 12:12:33 EDT

Created attachment 205263 [details]
ProjectMap class solution

The attached class solves these problems typically allowing an application to just do

new ProjectMap().initializeResourceSet(aResourceSet)

to make all the problems go away.

Provided an initial resource is opened as platform:/... then the correct root is established so that arbitrary ../.. go to sensible places, the URImap ensures that platform:/resource and platform:/project are interchangeable, preefderring the resource, and that in a standalone environment the EcorePlugin.getPlatformResourceMap() is initialized with the locations of all resources and plugins using the classpath scanning algorithm developed by MWE's StandaloneSetup.

This class has been in use for about a month on MDT/OCL where a variety of difficult resolution problems have suddenly had an easy solution.

[I'm not sure whether this class is best as an independent class, as part of EcoreUtil, or part or EcorePlugin.]

Comment 2 Ed Willink 2011-11-15 14:08:38 EST

Attachment 205263 [details] does not work for the case of retargetting e.g. platform:/plugin/org.eclipse.emf.ecore/model/Ecore.ecore or platform:/resource/org.eclipse.emf.ecore/model/Ecore.ecore to a registered package name such as http://www.eclipse.org/emf/2002/Ecore. The problem is that normalized URIs are not used as extensively as desirable in ResourceSetImpl.getResource.

This forces a redesign to provide multiple registrations in an EPackage.Registry, but then allows meta-model schiziophrenia to be substantially avoided.

An improved implementation, soon to be pushed to GIT master, as org.eclipse.ocl.examples.domain.utilities.ProjectMap therefore reads genmodels in both standalone and plugin environment to ensure that an EPackage.Registry is populated with three declarations per package thereby ensuring that each of e.g.

http://www.eclipse.org/emf/2002/Ecore
platform:/plugin/org.eclipse.emf.ecore/model
platform:/resource/org.eclipse.emf.ecore/model/Ecore.ecore

can resolve to the same Resource.

Comment 3 Ed Merks 2012-10-31 09:15:25 EDT

*** This bug has been marked as a duplicate of bug 220218 ***

Comment 4 Ed Willink 2012-11-01 04:13:54 EDT

Not a duplicate of Bug 220218, since that provides no standalone support.

Probably amenable to a significantly simpler solution now that Bug 271253 allows the EMF registries to populate in standalone.

Comment 5 Ed Merks 2012-11-01 05:37:09 EDT

Sorry, but there are no test cases and there's no design spelled out that I fully comprehend.  I suspect there's something simpler I could do via a utility method in EcorePlugin, given there is support for a workspace/target platform aware package registry and given there's support for plugin.xml extension processing stand alone, but without use cases, test cases, nor a detailed design description, I'm at a loss for exactly what that should be.

I think what's there now is sufficient and simple for an Eclipse application. Perhaps something else would be useful for stand alone, but what exactly is needed?  A map from platform:/plugin to physical jar/folder location?  Should that work with or without stand alone plugin.xml registration?

Comment 6 Ed Willink 2012-11-01 08:41:59 EDT

The use case was to make platform: URI references and GenModel NS URI maps work for a standalone application. A beneficial side effect was to provode a project descriptor that enabled application code to lookup the actual project entry in workspace/archive.

Now that some minor EMF changes have occurred to make the registries useable standalone, and there is some prtospect of this cvhange being incorporated, I'll rework the current MDT/OCL solution that requires zero EMF changes into simpler code that exploits EMF evolution and requires little/no further EMF change.

Comment 7 Ed Willink 2012-11-01 08:44:07 EDT

(In reply to comment #5)
> Sorry, but there are no test cases and there's no design spelled out that I
> fully comprehend. 

The ProjectMap code in GIT has Javadoc and the MDT/OCL project has four JUnit tests in org.eclipse.ocl.examples.test.ecore.ProjectMapTest.java.

Comment 8 Ed Merks 2012-11-01 10:46:04 EDT

I committed the following additional changes to master:

http://git.eclipse.org/c/emf/org.eclipse.emf.git/commit/?id=d0eed729a1727b498dfc8a4340eedb904d7b63d4

This ensures that
    resourceSet.getURIConverter().getURIMap().putAll(EcorePlugin.computePlatformURIMap(true));

will producing mappings that allow registered GenModels to be loaded stand alone when extension processing is enabled.  In fact they can be loaded using either platform:/resource/<plugin-id> or platform:/plugin/<plugin-id> as the resource URI.

Comment 9 Ed Willink 2012-11-04 05:23:10 EST

(In reply to comment #4)
> Probably amenable to a significantly simpler solution now that Bug 271253
> allows the EMF registries to populate in standalone.

Bug 271253 indeed provides a better and integrated solution to standalone registry population, but makes no contribution to the fight against meta-model schizophrenia mentioned in comment #2. Bug 393505 raised for this residual issue.

Comment 10 Ed Merks 2013-07-10 11:27:32 EDT

The changes are available in Kepler.