o.m.a.eclipse initialization does not find Alf libraries

[JoriDubrovin]

I am trying to set up the EMF resources for Libraries/uml/Alf.library.uml and other library files by running

new org.modeldriven.alf.eclipse.units.RootNamespaceImpl().initialize();

That seems to run into two issues:

• The constructor ends up calling setLibraryDirectory with null resourceSet, so pathmaps do not get initialized. This is an instance of the "calling a non-final method from constructor" problem.
• The baseURI is hard coded, so it does not find Libraries in the plugin.

My current attempt at a workaround is

URI baseUri = URI.createURI(Platform.getBundle("org.modeldriven.alf.eclipse").getResource("/").toString());
RootNamespaceImpl rootNs = new RootNamespaceImpl(baseUri);

// Work around org.modeldriven.alf.eclipse.units.RootNamespaceImpl.resourceSet being uninitialized when
// setLibraryDirectory is called from RootNamespaceImpl constructor.
rootNs.setLibraryDirectory(RootNamespaceImpl.DEFAULT_LIBRARY_DIRECTORY);

rootNs.initialize();

while patching RootNamespaceImpl with another constructor

public RootNamespaceImpl(URI baseURI) {
    super();
    this.resourceSet = new ResourceSetImpl();
    this.baseURI = baseURI;
    UMLResourcesUtil.init(this.resourceSet);
}

Using v0.6.0g.

[seidewitz]

The first issue is due to setLibraryDirectory being called in the constructor for the superclass org.modeldriven.alf.fuml.units.RootNamespaceImpl(). This is definitely a bug, which was covered up by the fact that org.modeldriven.alf.eclipse.fuml.execution.AlfCompiler has leftover code to explicitly set the default library (much as you did in your workaround).

The second issue was not a bug for the original intent of the Eclipse implementation, but it is for actually using the implementation as a plugin.

[JoriDubrovin]

v0.6.0h works without problems using the new RootNamespaceImpl(URI) constructor.

[seidewitz]

Resolved in v0.6.0h.