[Move to EMF Facet] Fails to load catalog elements because metamodel is overwritten by AcceleoBuilder

[eclipse-modisco-bot]

| --- | --- | | Bugzilla Link | 312050 | | Status | NEW | | Importance | P5 normal | | Reported | May 07, 2010 08:47 EDT | | Modified | May 23, 2016 05:25 EDT | | Version | 0.8.0 | | Reporter | Nicolas Bros |

Description

• Install MoDisco and Acceleo SDK in Eclipse 3.6M7
• Checkout all plug-ins from "https://dev.eclipse.org/svnroot/modeling/org.eclipse.gmt.modisco/plugins/branches/0_8_0".
• Do a full clean

You get several "Failed to load" errors on QuerySets, Facets and UiCustom (attached).

After debugging, I found out the corresponding Resources in the MoDiscoResourceSet contained DynamicEObjectImpl objects, instead of the expected generated implementation classes.

Several of the MoDisco projects that were checked-out are Acceleo projects, so have the Acceleo builder enabled.

AcceleoBuilder registers all ecore files it finds in Acceleo projects and their dependencies, putting a dynamic version of the metamodel into the EPackage.Registry.

After this, EClassifier#isInstance returns false when asked whether OCLModelQueryImpl is an instance of ModelQuery (it should be true of course).

The reason for this is that these metaclasses now reside in two different metamodels: the one for which an implementation was generated, and the one that was loaded dynamically.

And this is what is causing the aforementioned "Failed to load" errors.

[eclipse-modisco-bot]

By Nicolas Bros on May 07, 2010 08:49

Created attachment 167459 stacktrace

:notepad_spiral: stacktrace.txt

[eclipse-modisco-bot]

By Nicolas Bros on May 07, 2010 10:12

Bug 305831 has been marked as a duplicate of this bug.

[eclipse-modisco-bot]

By Nicolas Bros on Oct 18, 2010 08:30

Created attachment 181087 patch

Anyway, here is a patch that fixes the problem, by removing only javadoc comments as the comment suggests, and putting back removed comments in the unhandled comments list.

:notepad_spiral: Bug 312050.patch

[eclipse-modisco-bot]

By Nicolas Bros on Oct 18, 2010 08:32

Scratch that! Wrong bug.

[eclipse-modisco-bot]

By Nicolas Bros on Oct 19, 2010 06:12

Created attachment 181165 example project

Here is a project that shows the problem:

• Import project bug312050 from the attached zip
• open A.xmi in the model browser
• Add the single instance of metaclass A in this model to the Query Execution view
• execute query A::myQuery2 using the Query Execution view

you get a message in the log giving the identity of the metaclass: metaclass A: org.eclipse.emf.ecore.impl.EClassImpl@461984

• Do "Project > Clean..." on the bug312050 project
• the query A::myQuery2 disappears from the Query Execution View, because the metamodel changed, and the instance of metaclass A that was added in the view is suddenly no more an instance of the metaclass A in the re-loaded metamodel. So, the query is not applicable to it anymore.
• close and re-open A.xmi
• Add the single instance of metaclass A in this model to the Query Execution view
• execute query A::myQuery2 using the Query Execution view

you get a new message in the log, with a different ID for the metaclass, indicating it is not the same metaclass anymore: metaclass A: org.eclipse.emf.ecore.impl.EClassImpl@1be72d6

:compression: bug312050.zip

[eclipse-modisco-bot]

By Nicolas Bros on Oct 19, 2010 06:46

Actually, this is not conclusive, because A.xmi contains a dynamic instance.\ I need to find a better example.

[eclipse-modisco-bot]

By Nicolas Bros on Oct 19, 2010 09:38

See: org.eclipse.acceleo.common.utils.ModelUtils.registerEcorePackages(String pathName). This is where Acceleo registers the EPackages.

[eclipse-modisco-bot]

By Gregoire Dupe on Sep 28, 2011 07:14

We will switch to EMF Facet before to try to solve such bugs. => P5