Missing platform:/plugin fallback.

[eclipse-qvt-oml-bot]

| --- | --- | | Bugzilla Link | 533564 | | Status | REOPENED | | Importance | P3 normal | | Reported | Apr 13, 2018 13:44 EDT | | Modified | Mar 05, 2019 08:08 EDT | | Reporter | Ed Willink |

Description

https://www.eclipse.org/forums/index.php/mv/msg/1092229/1785423/#msg_1785423 provides a repro whereby transfgormation of a model referencing platform:/plugin/org.eclipse.emf.ecore/model/Ecore.ecore#//EString gets an unresolved proxy rather than falling back to platform:/plugin/org.eclipse.emf.ecore/model/Ecore.ecore#//EString

<?xml version="1.0" encoding="UTF-8"?>\ <ecore:EPackage xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"\ xmlns:ecore="http://www.eclipse.org/emf/2002/Ecore" name="test" nsURI="http://example.com/test" nsPrefix="test">\

\

\

\ \ \ \ \

[eclipse-qvt-oml-bot]

By Ed Willink on Apr 13, 2018 16:11

EcorePlugin.computePlatformURIMap(true) provides all the information needed to make the standalone URIMap behave like within Eclipse.

Available for review on branch ewillink/533565.

But it imposes the cost of population of the URIMap for all plugins on all transformations even though very few need it.

[eclipse-qvt-oml-bot]

By Ed Willink on Apr 14, 2018 04:07

(In reply to Ed Willink from comment #1)

But it imposes the cost of population of the URIMap for all plugins on all transformations even though very few need it.

We could add a "Register installed models" checkbox in the launch dialog to avoid the cost, but the initialization is a standard Ecore/GenModel init for use in Eclipse, so I think we just add it anyway.

May also help for standalone usage, since EcorePlugin.computePlatformURIMap(true) now has standalone functionality too.

---

Copyright/contributors corrected. Aggregated in branch ewillink/master in preparation for push to master for M7.

[eclipse-qvt-oml-bot]

By Christopher Gerking on Apr 18, 2018 16:42

(In reply to Ed Willink from comment #2)

We could add a "Register installed models" checkbox in the launch dialog to avoid the cost, but the initialization is a standard Ecore/GenModel init for use in Eclipse, so I think we just add it anyway.

I agree that we need to establish the default Ecore behavior for loading user-defined models.

(In reply to Sergey Boyko from mail)

You're right about possible performace penalty introduced by 'EcorePlugin.computePlatformURIMap(true)'. Looks like the filling of URIMap should be done upon creation of ResourceSet which is then passed to EmfUtil.loadModel(..).

I also agree that a non-null ResourceSet passed explicitly to one of the loadModel implementations should not be adapted to use the platform URI map. However, in case of a null ResourceSet passed to loadModel, I think that using the platform URI map is a good default behavior for the ResourceSet created on demand. In any case, we need to ensure that all user models are loadable.

[eclipse-qvt-oml-bot]

By Sergey Boyko on Apr 19, 2018 13:10

(In reply to Christopher Gerking from comment #3)\

(In reply to Sergey Boyko from mail)

You're right about possible performace penalty introduced by 'EcorePlugin.computePlatformURIMap(true)'. Looks like the filling of URIMap should be done upon creation of ResourceSet which is then passed to EmfUtil.loadModel(..).

I also agree that a non-null ResourceSet passed explicitly to one of the loadModel implementations should not be adapted to use the platform URI map. However, in case of a null ResourceSet passed to loadModel, I think that using the platform URI map is a good default behavior for the ResourceSet created on demand. In any case, we need to ensure that all user models are loadable.

Good reasoning. I agree with them. \ So URIMap population should be done conditionally done only for non-initialized ResourceSets.

[eclipse-qvt-oml-bot]

By Christopher Gerking on Apr 20, 2018 09:33

(In reply to Christopher Gerking from comment #3)

I think that using the platform URI map is a good default behavior for the ResourceSet created on demand.

The right place to add this behavior as a default would be EmfUtil.createResourceSet(...).

[eclipse-qvt-oml-bot]

By Ed Willink on May 22, 2018 03:51

In the absence of further evaluated changes, I propose to commit my minimal change to invoke EcorePlugin.computePlatformURIMap(true) in EmfUtil.loadModel only, for RC1 today. This fixes the specific problem.

The refactoring to introduce a uniform EmfUtil.createResourceSet can wait. See Bug 533155.

[eclipse-qvt-oml-bot]

By Christopher Gerking on May 22, 2018 04:04

(In reply to Ed Willink from comment #6)

In the absence of further evaluated changes, I propose to commit my minimal change to invoke EcorePlugin.computePlatformURIMap(true) in EmfUtil.loadModel only, for RC1 today. This fixes the specific problem.

+1 for a transitory solution. Even though the performance penalty becomes clearly visible, e.g., when executing QVTo's JUnit tests.

[eclipse-qvt-oml-bot]

By Ed Willink on May 22, 2018 11:21

Pushed to master for RC1.

[eclipse-qvt-oml-bot]

By Christopher Gerking on Aug 22, 2018 07:42

Is there already a JUnit test case that demonstrates the improvement? I'm asking because when running the xcore test model via the Eclipse launch configs, I can't see any difference with/without the loadModel changes.

[eclipse-qvt-oml-bot]

By Ed Willink on Aug 22, 2018 08:06

The difference is likely to show up most on very simple models in a standalone config. xcore and/or plugin testing is likely to load everything anyway.

[eclipse-qvt-oml-bot]

By Christopher Gerking on Aug 22, 2018 11:57

(In reply to Ed Willink from comment #10)

The difference is likely to show up most on very simple models in a standalone config. xcore and/or plugin testing is likely to load everything anyway.

No difference shows up because the bug doesn't seem to be solved for transformations launched through the Eclipse UI. The input model loads, but there are still EJavaType attributes as described in the initial forum thread. This is because ModelExtentHelper.loadExtent doesn't delegate to EmfUtil.loadModel which actually contains the fix. Apparently we need to delegate in a more clever way, or use the platform URI map at different places.

[eclipse-qvt-oml-bot]

By Christopher Gerking on Mar 05, 2019 08:08

(In reply to Christopher Gerking from comment #11)

No difference shows up because the bug doesn't seem to be solved for transformations launched through the Eclipse UI.

Reopening to keep track of the shortcoming.