OMLZipResourceFactory instantiation and OMLZipResource.load() does not handle 'platform' URI

[dyates]

• OMLZipResourceFactory is unable to be instantiated and throws a CoreException. This only happens when tryting to load a Modeling project that already contains '*.omlzip' files. Upon looking into the issue and help from @melaasar we discovered that the problem is due to OMLZipResourceFactory not having a no-argument (no-arg) constructor. When a no-arg constructor was added the error goes away.

• OMLZipResource does not load 'platform' resources. For example, if the resource has a uri of the form platform:/resources/vocabulary/asserted/imce.jpl.nasa/..., an IllegalArgumentException is thrown with the error message OMLZipResource.load(): unrecognized URI scheme in: «uri» (must be either http or file): «uri.isFile»

[sjiherzig]

Please have a look at the unit tests - OMLZipResourceFactory no longer needs to be registered. Simply use the OMLStandaloneSetup.doSetup(). As a resource set, it is best to use an XtextResourceSet for loading both .omlzip and .oml files - you may need to pass the content type when calling getResource(...) on the resource set (content-type: "oml", "omlzip", etc. (it's the second argument)). For saving, you may still want to use OMLZipResourceSet.

Regarding the second issue: a workaround would be to resolve the platform URI to a file URI. This is tricky, but not impossible. I'm not sure whether this works, but you could also try to add the platform URI to the catalog, and then use a http:// scheme to resolve the file.

[NicolasRouquette]

Please include a stack trace & version of the software corresponding to the problem you're reporting about.

Regarding the first point, I struggled for a while to get the OMLZipResource & its factory to work. OMLZipResourceFactory uses an injected argument constructor just like org.eclipse.xtext.resource.XtextResourceFactory does.

This works with programmatic API as @sjiherzig mentions; there are several test cases demonstrating that. In the Eclipse UI, there is a different phenomena gong on with the Eclipse builder; or more precisely, either the modeling and/or xtext resource builder. It is unclear to why there are two different factory patterns in Eclipse.

I am not opposed to switching to a no-argument factory; however, it remains to be demonstrated with appropriate unit tests that this works for both programmatic API use as we've done in the unit tests and with new UI unit tests that have yet to be written to replicate the original issue.

The second point is a related to the first; that is, in the context of the Eclipse UI w/ resource builders, either the modeling or xtext builder or both attempt to load an *.omlzip resource using an Eclipse platform-scheme URI. Had you included a stack trace, I believe it would point to OMLZipResource.load(Map<?,?> options) which attempts to determine whether the resource uri needs to be resolved through the catalog or not. Unfortunately, Eclipse' platform-scheme URI returns false for the local file test: if (uri.file) .... A third case is needed for Eclipse' platform and convert that URI into a local file location.