Eclipse Community Forums: EMF » Resolve an EClass that is a Proxy

Home » Modeling » EMF » Resolve an EClass that is a Proxy(Traverse through EPackage give unresolved EClass)

Resolve an EClass that is a Proxy [message #1837376]

Thu, 28 January 2021 16:13

Eclipse User

I have two models A and B
In the B model I have a class with an EReference to another class in the A model. EClass Y (model B) has a ref-> EClass X (from model A)

I'm trying to create a program that list all available Attribute in the EClass Y of the B model. Including the reference.

I load the EPackage of the B model (given the URL) and get the target class Y.
As I go through the Refences the ref.getEType() gives me the EClass X from model A but it is a proxy and does not have any metadata.

How do I resolve the EClass (so I can get the EAttribute from it) or load the A EPackage from the program without adding the dependencies?

thanks
Yigal

Re: Resolve an EClass that is a Proxy [message #1837379 is a reply to message #1837376]

Thu, 28 January 2021 19:07

Eclipse User

After some investigate, I found that when I load the gemodel of the model B, the package for model A has the same folder as model B and therefore can't be loaded.
Here is a sample of the code:

                                    // Load the genmodel
                                    ResourceSet set = new ResourceSetImpl();
                                    // Register the appropriate resource factory to handle all file
                                    // extensions.
                                    set.getResourceFactoryRegistry().getExtensionToFactoryMap().put(EcorePackage.eNAME, new XMIResourceFactoryImpl());

                                    // Register the package to ensure it is available during loading.
                                    set.getPackageRegistry().put(EcorePackage.eNS_URI, EcorePackage.eINSTANCE);

                                    URI uri = URI.createFileURI(targetPackageFolder +"model/csm.genmodel");
                                    Resource ecoreResource = set.getResource(uri, true);
                                    if (!ecoreResource.getContents().isEmpty()) {
                                        GenModel model = (GenModel) ecoreResource.getContents().get(0);
                                        List<GenPackage> listPkgs = model.getUsedGenPackages();

                                        for (GenPackage g1 : listPkgs) {
                                            EPackage pk = g1.getEcorePackage();
                                           // PK is NULL since the base location is invalid
                                        }

In the genmodel file it is clear that the depended EPackage are in a different folder (see used Packages attribute):

<genmodel:GenModel xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:ecore="http://www.eclipse.org/emf/2002/Ecore"
    xmlns:genmodel="http://www.eclipse.org/emf/2002/GenModel" copyrightText="Copyrights 2018 Accenture.  All rights reserved."
    modelDirectory="/com.accenture.fso.fsd.transact.model.csm/src" editDirectory="/com.accenture.fso.fsd.transact.model.csm/src"
    editorDirectory="/com.accenture.fso.fsd.editors.csm/src" modelPluginID="com.accenture.fso.fsd.transact.model.csm"
    templateDirectory="platform:/plugin/com.accenture.fso.tools.emf.generator.validator/emftemplates"
    dynamicTemplates="true" forceOverwrite="true" modelName="Csm" editPluginClass="com.accenture.fso.fsd.transact.model.csm.CsmPluginActivator"
    editorPluginClass="com.accenture.fso.fsd.editors.csm.CsmEditorPluginActivator"
    importerID="org.eclipse.emf.importer.ecore" complianceLevel="8.0" copyrightFields="false"
    editPluginID="com.accenture.fso.fsd.transact.model.csm" editorPluginID="com.accenture.fso.fsd.editors.csm"
    fontProviders="true" usedGenPackages="../../com.accenture.fso.mdd.model.types/model/etype.genmodel#//types ../../com.accenture.fso.fsd.app.model.fsdmodel/model/fsdmodel.genmodel#//fsdmodel"
    styleProviders="true" modelDocumentation="1.4.0">
  <foreignModel>file:/C:/Temp/csm.ecore</foreignModel>

[Updated on: Thu, 28 January 2021 19:31] by Moderator

Re: Resolve an EClass that is a Proxy [message #1837383 is a reply to message #1837379]

Thu, 28 January 2021 23:29

Eclipse User

Is this running stand alone that you need to do the registrations? Both *.ecore and *.genmodel resources are generally loaded with org.eclipse.emf.ecore.xmi.impl.EcoreResourceFactoryImpl, but those are registered when running an Eclipse/Equinox application...

Is targetPackageFolder an absolute file system path? If not, call File.getCanonicalPath on it. The relative URIs will be resolved against whatever value "uri" has. That means whatever folder contains model/csm.genmodel, two folders up from that must exist com.accenture.fso.fsd.app.model.fsdmodel/model/fsdmodel.genmodel in the file system.

Re: Resolve an EClass that is a Proxy [message #1837418 is a reply to message #1837383]

Fri, 29 January 2021 10:44

Eclipse User

Hi Ed,
The targetPackageFolder is a full path. But the usedGenPackages values are invalid as a reference. I modified the used packages manually:

usedGenPackages="../../../../../MDD/base/com.accenture.fso.mdd.model.types/model/etype.genmodel#//types ../../../../App/com.accenture.fso.fsd.app.model.fsdmodel/model/fsdmodel.genmodel#//fsdmodel"

Now, when I open the genmodle Editor, I get an error,

java.net.MalformedURLException: Unsupported "platform:" protocol variation "..".
	at org.eclipse.core.internal.boot.PlatformURLHandler.openConnection(PlatformURLHandler.java:61)
	at org.eclipse.osgi.internal.url.URLStreamHandlerProxy.openConnection(URLStreamHandlerProxy.java:123)
	at java.base/java.net.URL.openConnection(URL.java:1051)

However the used package do load in my code but the Editor does not work.
How can I fix that?

Thanks
Yigal

[Updated on: Fri, 29 January 2021 10:47] by Moderator

Re: Resolve an EClass that is a Proxy [message #1837424 is a reply to message #1837418]

Fri, 29 January 2021 12:05

Eclipse User

Hi

If you want that the genmodel can be loaded correctly both in the editor and in your code, you have to be sure that the relative URI specified in the usedGenPackages resolve both to an existing resource in the workspace hierarchy (when loaded by the editor) and to an existing file in the files system (when loaded by your standalone program).

The easiest way to ensure that is that your file system directory structure reflects the workspace hierarchy: you have a single directory that contains subdirectories for "com.accenture.fso.mdd.model.types" and "com.accenture.fso.fsd.app.model.fsdmodel".

If your file system directory structure is different than your workspace hierarchy (that seems to be your case as you seem to have some directories MDD/base and App) then you have to use URI mappings in your code to map the two hierarchies.

Hope it helps

Re: Resolve an EClass that is a Proxy [message #1837425 is a reply to message #1837424]

Fri, 29 January 2021 12:12

Eclipse User

Thanks for the answer.
What I ended up doing is a recursive loop. If the current genmodel as used packages that are proxy, I retrieved the genmodel name from the URI (since the relative path is invalid) and scan all extension points and load the package from the extension point information.

Re: Resolve an EClass that is a Proxy [message #1837426 is a reply to message #1837425]

Fri, 29 January 2021 12:22

Eclipse User

Hi

If you are scanning the classpath and loading the extension point information manually in your code, you should consider instead using EcorePlugin.computePlatformURIMap

see https://wiki.eclipse.org/EMF/FAQ#How_do_I_make_my_EMF_standalone_application_Eclipse-aware.3F

Re: Resolve an EClass that is a Proxy [message #1837427 is a reply to message #1837426]

Fri, 29 January 2021 12:59

Eclipse User

Hi

It is unusual to need so many ../.. terms. It suggests that you navigating from a src/p/a/c/k/a/g/e path, the start of which is stripped once resources materialize in a jar. It is very strongly recommended that you keep all your models in a distinct hierarchy; typically just model/... for a few models but a little more elaborate if necessary.

You should find that all tools can read platform:/resource/... paths although for standalone applications you may need to ensure that you exploit EcorePlugin.ExtensionProcessor.

It is perhaps unfortunate that a genmodel save uses the minimum length save and so typically replaces platform:/resource by ../.. but this should not matter if you have your files at stable locations so that the number of .. segments is fixed.

Regards

Ed Willink

Previous Topic:	JUnit + ResourceSetListener
Next Topic:	Gather element lines when loading a resource (without extending XMLHandler)

Goto Forum:

-=] Back to Top [=-

Current Time: Sun Jul 20 07:52:38 EDT 2025

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter