Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » Compare » Resolving models that span multiple languages
Resolving models that span multiple languages [message #1819267] Fri, 10 January 2020 20:17 Go to next message
Steve Hickman is currently offline Steve HickmanFriend
Messages: 13
Registered: January 2017
Junior Member
The Future Airborne Capability Environment (FACE) 3.0 spec defines 3 interrelated metamodels (See Appendices J.2, J.3 and J.4) . Models developed using EMF based on these metamodels can span multiple files, with references from file to file using any of the 3 metamodels.

I have already created a tool that can determine the transitive closure starting from any object in any project resource and following all types of references. I want to port that to work with EMF Compare which means, I think, that I need to extend org.eclipse.emf.compare.ide.ui.logical.AbstractModelResolver.

The EMF Developer Guide states: Quote:
Note: This extension point is currently in beta and may be removed in the future since the ThreadedModelResolver seems flexible enough to support all common usecases.
.

My questions are:
1) Is my understanding correct?
2) Will the extension point remain available or will it be deprecated? If it will remain available, please remove this comment from the Developer Guide. If it will be deprecated, what should I use to implement the model resolution mechanism I need?
3) Is there any additional documentation or tips (beyond the code itself) that I can refer to while doing this? If so, where do I find it?

[Updated on: Fri, 10 January 2020 20:22]

Report message to a moderator

Re: Resolving models that span multiple languages [message #1819325 is a reply to message #1819267] Mon, 13 January 2020 08:42 Go to previous message
Laurent Goubet is currently offline Laurent GoubetFriend
Messages: 1891
Registered: July 2009
Senior Member
Hello,

1) If you already have the necessary plumbing to resolve your logical models, or if the resolving from EMF Compare is not satisfying, you can indeed circumvent the default model resolving by plugging in yours.
2) The extension point is not going to be removed. It is still marked as internal since we want to keep the possibility of slightly modifying the APIs, but we do not intend to remove it.
3) As this was internal, we haven't documented it at all so you will have to use the existing code as reference. Please don't hesitate to mention it if you think that some of the APIs are insufficient or need to be opened more than they currently are.

Regards,

Laurent Goubet
Obeo
Previous Topic:Using org.eclipse.compare.compareFilters
Next Topic:Class loader error - two versions of Guava
Goto Forum:
  


Current Time: Mon Nov 30 15:11:08 GMT 2020

Powered by FUDForum. Page generated in 0.02663 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top