OCL file not loaded properly when running from JAR

[Matthias Schoettle]

When running TouchRAM from a JAR, where the ocl files are located in the JAR (see #176), a NullpointerException occurs in ValidationRulesParser:

Exception in thread "Rules Parser Initializer" java.lang.NullPointerException
    at ca.mcgill.sel.ram.validator.ValidationRulesParser.importConstraints(ValidationRulesParser.java:192)
    at ca.mcgill.sel.ram.validator.ValidationRulesParser.<init>(ValidationRulesParser.java:86)
    at ca.mcgill.sel.ram.validator.ValidationRulesParser.getInstance(ValidationRulesParser.java:104)
    at ca.mcgill.ram.TouchRAM$1.run(TouchRAM.java:86)
    at java.lang.Thread.run(Thread.java:695)

It seems that there are differences when running it from the IDE and the JAR.

[Matthias Schoettle]

The problem is that using the URI of the ecore model makes it work (e.g., http://cs.mcgill.ca/sel/ram/2.1), however, when modifying the OCL file this model cannot be found, because it is not registered in the development environment.

When running from the IDE, OCL uses a StandaloneProjectMap which creates a map between resources and plugins and their actual location.

[Matthias Schoettle]

After debugging it seems that adding a mapping to ResourceSet.getURIConverter().getURIMap() requires a complete mapping of the full path. Mapping platform:/plugin/ca.mcgill.sel.ram/model/RAM.ecore to the actual location sort of works.

What seems better is to map the prefix, in ExtensibleURIConverterImpl#normalize(...) line 410 it will try to normalize the full URI and if that fails, it will check the prefixes. The prefixes are in a separate map: URIMappingRegistryImpl.INSTANCE, which is populated in the IDE on startup by scanning the class path for Eclipse plugins.

Because we use plugins, this works in the IDE. However, the built JAR is a flat JAR where everything is unpacked into it.

[Matthias Schoettle]

One option is therefore in case of running from a JAR to manually create prefix mappings for at least the RAM and CORE metamodel projects. Also, the .ecore files need to be added to the JAR.

Another option would be to use the ability to keep the JARS separated, which Eclipse supports by providing a JAR in JAR Classloader. Then scanning the class path would hopefully automatically find everything. This could be interesting when JOGL is updated to v2, which has the ability to add the native JARs to the classpath (see issue #14).

[Matthias Schoettle]

Resolved issue #180: When running from a JAR, the RAM and CORE project paths are added to the URIMappingRegistry.

→ <<cset 2a391ea75ebc>>

[Matthias Schoettle]

Fix of this issue changed/updated to fix issue #189.

→ <<cset c34f004a8a48>>