Eclipse Community Forums: Epsilon » Concordance documentation

Help

Home

Home » Modeling » Epsilon » Concordance documentation

Show: Today's Messages :: Show Polls :: Message Navigator

Concordance documentation [message #1103017]

Fri, 06 September 2013 09:47

Maarten Bezemer

Messages: 117
Registered: February 2012

Senior Member

Hello,

I am back! I (finally) finished my thesis, so there is time for some other work. Smile

Out models have relations to other models in the workspace (e.g. to provide the implementation for a component). I was checking out the Epsilon website for news and I saw the concordance description. It seemed as it could help in keeping the inter-model relations up-to-date...

I could not really find documentation on concordance. Is there any available? (The Epsilon book does not seem to contain concordance information)

Regards,
Maarten

Report message to a moderator

Re: Concordance documentation [message #1103931 is a reply to message #1103017]

Sat, 07 September 2013 15:18

Antonio Garcia-Dominguez

Messages: 594
Registered: January 2010
Location: Birmingham, UK

Senior Member

Hi Maarten,

The book focuses on the languages and the workflow tasks, and doesn't delve much into the extra tools, such as Eugenia or Concordance. However, we do have an article in the website about Concordance:

http://eclipse.org/epsilon/doc/articles/concordance-cross-references/

Hope it helps!
Antonio

Report message to a moderator

Re: Concordance documentation [message #1105109 is a reply to message #1103931]

Mon, 09 September 2013 11:28

Maarten Bezemer

Messages: 117
Registered: February 2012

Senior Member

Thanks for your reply.

I was more looking on how to integrate it with my own application, like information about its API or example applications.
And whether it is possible to add (custom) actions when a change has been detected.

I was planning to build it myself, but if concordance is providing the same functionality, I rather reuse it! Smile

Thanks,
Maarten

Report message to a moderator

Re: Concordance documentation [message #1106796 is a reply to message #1105109]

Wed, 11 September 2013 15:01

Louis Rose

Messages: 440
Registered: July 2009
Location: York, United Kingdom

Senior Member

Hi Maarten,

I'm afraid that we don't yet have very much API documentation for Concordance. For a conceptual overview, our ECMFA 2010 paper might be of interest. For a more technical overview, perhaps the following will be helpful....

Epsilon currently ships with three Concordance clients (i.e., extensions to org.eclipse.epsilon.concordance.core that do something useful). These are perhaps best understood by looking at plugins/org.eclipse.epsilon.concordance.clients/plugin.xml, but briefly there are :

CrossReferenceReconciler - when a source EMF model contains references to a target model, this client updates the cross-model references in the source model when the target model is moved (e.g., to another directory).
ConformanceChecker - when a registered Ecore EPackage or its contents change, this client checks to see whether all models that use this EPackage continue to conform to the EPackage.
AutomaticMigrator - when a registered Ecore EPackage or its contents change, this client checks to see whether the user has registered a Flock migration strategy to update models affected by this change, and if so, applies the Flock migration strategy to migrate the affected models such that they conform to the new version of the EPackage.

One or more of these clients might give some clues into how Concordance can be used right now. The main entry points for a custom Concordance client are to extend either DefaultMetamodelChangeListener or DefaultModelChangeListener.

With luck, the Concordance core plugins will already capture all of the information you need to implement your client(s). If not though, do let us know and we can discuss whether it would be feasible for us to patch together.

Hope this helps!

Cheers,
Louis.

Report message to a moderator

Re: Concordance documentation [message #1106822 is a reply to message #1106796]

Wed, 11 September 2013 15:42

Maarten Bezemer

Messages: 117
Registered: February 2012

Senior Member

Hi,

Thank you for your reply!
I already read/skimmed through your paper, but your explanation of the Concordance clients sounds promising!

I probably need the functionality of CrossReferenceReconciler client, but adjusted to my own models/needs. (I need to synchronize components interfaces and their implementations, each having their own model)
I'll check the client implementation soon, and if I need more help or changes in the concordance code, I'll come back! Smile

Thanks again,
Maarten

Report message to a moderator

Re: Concordance documentation [message #1107522 is a reply to message #1106822]

Thu, 12 September 2013 14:29

Maarten Bezemer

Messages: 117
Registered: February 2012

Senior Member

Hi all,

I checked the implementation and understood the following:

Projects need to have a concordance nature to make use of concordance. This nature triggers the concordance builder, which keeps track of modified (added, renamed, deleted, etc.) resources. These resources are filtered using the ecore registry of available meta-models and their file extensions. The builder calls the client methods to actually perform their required actions for the modification.

Am I about right?

I do have some questions though Rolling Eyes

Is concordance meant to be used in an application? I noticed that I seem to need *.dt.* packages for implement concordance. These are normally the Epsilon 'Development Tool' packages...
Is concordance able to handle 'in memory models' using (Transactional)EditingDomain? I.e. is concordances able to modify models that are opened in editors in such a way that the editors are able to show updated model directly after it got modified by a client? For example, the *.model.CrossReferenceReconciler seems to really load the resource. So I suppose this needs to be modified to use EditingDomains?
Are the concordance clients enabled by default? I do not seem to require them, except for the CrossReferenceReconciler client (which probably needs modifications as well)
Is there an example on how to add the concordance nature to a project? I noticed the ToggleConcordanceNatureAction, but I did not find a part of the UI that allows me to try it on a project...

Thanks

Report message to a moderator

Re: Concordance documentation [message #1107573 is a reply to message #1107522]

Thu, 12 September 2013 16:01

Louis Rose

Messages: 440
Registered: July 2009
Location: York, United Kingdom

Senior Member

Hi Maarten,

Please see comments below:

Quote:

I checked the implementation and understood the following:

Projects need to have a concordance nature to make use of concordance. This nature triggers the concordance builder, which keeps track of modified (added, renamed, deleted, etc.) resources. These resources are filtered using the ecore registry of available meta-models and their file extensions. The builder calls the client methods to actually perform their required actions for the modification.

Am I about right?

That sounds right to me. The index is persisted in a (H2) database and so is available between restarts of the Eclipse workbench.

Quote:

Is concordance meant to be used in an application? I noticed that I seem to need *.dt.* packages for implement concordance. These are normally the Epsilon 'Development Tool' packages...

Right now, the Concordance core is very dependent on some Eclipse concepts (e.g. natures, builders) and so it can't really run outside of Eclipse. Because of that, there's no separate concordance.core and concordance.core.dt plugins. This separation of concerns would certainly be desirable, but I haven't yet thought of a simple way to implement versions of natures and builders that would run outside of Eclipse.

Quote:

Is concordance able to handle 'in memory models' using (Transactional)EditingDomain? I.e. is concordances able to modify models that are opened in editors in such a way that the editors are able to show updated model directly after it got modified by a client? For example, the *.model.CrossReferenceReconciler seems to really load the resource. So I suppose this needs to be modified to use EditingDomains?

Right now, I don't think that Concordance clients will work with in-memory models for the reasons you describe. This sounds useful though, so I'd be happy to review any patch to Concordance core that addressed this.

Quote:

Are the concordance clients enabled by default? I do not seem to require them, except for the CrossReferenceReconciler client (which probably needs modifications as well)

It depends on the client. You can write a client that is always enabled, or you can write a client that is enabled only when some condition is met. For example, the Migrator client is only enabled when there is more than one extension loaded which conforms to its extension point.

Quote:

Is there an example on how to add the concordance nature to a project? I noticed the ToggleConcordanceNatureAction, but I did not find a part of the UI that allows me to try it on a project...
[/list]

If you right-click on a project, you should be able to select Concordance > Enable Concordance Project Nature, as shown in the attached screenshot.

Hope that helps!

Cheers,
Louis.

Attachment: Screen Shot 2013-09-12 at 17.00.25.png
(Size: 115.42KB, Downloaded 166 times)

Report message to a moderator

Re: Concordance documentation [message #1108109 is a reply to message #1107573]

Fri, 13 September 2013 10:57

Maarten Bezemer

Messages: 117
Registered: February 2012

Senior Member

Louis Rose

Quote:
Am I about right?

That sounds right to me. The index is persisted in a (H2) database and so is available between restarts of the Eclipse workbench.

Ah.. Index us used to store the current state of the references, so they can be managed..? I was indeed wondering about Index and History.

Louis Rose

Quote:
Is concordance meant to be used in an application? I noticed that I seem to need *.dt.* packages for implement concordance. These are normally the Epsilon 'Development Tool' packages...

Right now, the Concordance core is very dependent on some Eclipse concepts (e.g. natures, builders) and so it can't really run outside of Eclipse. Because of that, there's no separate concordance.core and concordance.core.dt plugins. This separation of concerns would certainly be desirable, but I haven't yet thought of a simple way to implement versions of natures and builders that would run outside of Eclipse.

The dt classes of concordance are not really 'development tools', but the required implementation. Besides some parts to add the Concordance Project converter for example.
So, I guess the 'dt' plugin/packages needs to be renamed? (to prevent 'confusion')

Louis Rose

Right now, I don't think that Concordance clients will work with in-memory models for the reasons you describe. This sounds useful though, so I'd be happy to review any patch to Concordance core that addressed this.

Currently, my application does not (correctly) support the EditingDomains... But when I have fixed this, I'll take a look to add this functionality to concordance as well.

Louis Rose

Quote:
Are the concordance clients enabled by default? I do not seem to require them, except for the CrossReferenceReconciler client (which probably needs modifications as well)

It depends on the client. You can write a client that is always enabled, or you can write a client that is enabled only when some condition is met. For example, the Migrator client is only enabled when there is more than one extension loaded which conforms to its extension point.

I meant the Epsilon provided ones... Smile

They register themselves with their extension points, but I am a little worried that they mess up/influence my use case. (Although, maybe not (I did not try it yet) Smile

)

Louis Rose

If you right-click on a project, you should be able to select Concordance > Enable Concordance Project Nature, as shown in the attached screenshot.

Heh.. I does not work for Java projects, so I tried it on the wrong project... On a generic project it indeed shows in the menu.

Thanks a lot for your clarifications!
Cheers,
Maarten

Report message to a moderator

Re: Concordance documentation [message #1110118 is a reply to message #1108109]

Mon, 16 September 2013 11:54

Louis Rose

Messages: 440
Registered: July 2009
Location: York, United Kingdom

Senior Member

Hi Maarten,

With regard to the "dt" package, I suspect you are right -- probably only a couple of these classes are true development tools. For now, I'd recommend we don't change this, however, as it would be a breaking change for anybody who is extending / otherwise customising these classes.

As for the built-in Concordance clients, I now understand your original comment. Sorry for the confusion! If any of the existing clients is problematic for your use case, perhaps it would be helpful for us to add a Concordance preferences pane for projects. This would allow users to enable / disable specific clients on a per-project basis. If that sounds useful, do file an enhancement request and I'll take a look.

Cheers,
Louis.

Report message to a moderator

Re: Concordance documentation [message #1129341 is a reply to message #1110118]

Tue, 08 October 2013 14:35

Maarten Bezemer

Messages: 117
Registered: February 2012

Senior Member

Hello,

I have further looked into the CrossReferenceReconciler client and tried it in my application.

I have to conclude it does not match: I use IPath objects to refer to an external model/file while the client assumes to find EMF proxies.
Another thing is that I want to perform the changes in memory: Each of my models, that is in use by a tool, has its own EditingDomain. I need to modify the resoruces in these EditingDomains.

So, I'll write my own clients, albeit using lots of the infrastructure of Concordance!

Therefore I would like to be able to hide (or at least disable) the concordance clients as they do not make any sense with respect to my application.
What seems to be the best approach to accomplish this? Your proposal to add a preference page, allows the user to disable the clients, not the application. Unless there is some kind of API to also let the applciation do so.

Regards,
Maarten

PS Epsilon has 2 classes named CrossReferenceReconciler (in org.eclipse.epsilon.concordance.model and org.eclipse.epsilon.concordance.clients.xref), which was a bit confusing at first... Confused

Report message to a moderator

Re: Concordance documentation [message #1129354 is a reply to message #1129341]

Tue, 08 October 2013 14:49

Maarten Bezemer

Messages: 117
Registered: February 2012

Senior Member

An additional question:

It seems that history (ConcordanceHistory) is only recording changes. It is not used for any task? (Or so it seems)
If so, I am not required to implement it in my clients?

Report message to a moderator

Re: Concordance documentation [message #1129373 is a reply to message #1129354]

Tue, 08 October 2013 15:09

Maarten Bezemer

Messages: 117
Registered: February 2012

Senior Member

Hm... sorry for posting so much...

If I want to add EditingDomains to Concordance, I need to recreate the org.eclipse.epsilon.concordance.model.Model (e.g. ModelMemory or ModelEditingDomain).
This is not problem, but the instantiation of the Model objects is done in org.eclipse.epsilon.concordance.dt.ConcordanceBuilder.

Telling this class to use either Model or ModelMemory is a bit tricky...
I could/need to put 'new Model()' into a method, which is able to determine which model type needs to be instantiated. But I am unsure how to determine this properly... I could add some kind of extension point to 'configure' this? Although it seems more of a hack than a proper solution...

Report message to a moderator

Re: Concordance documentation [message #1220041 is a reply to message #1129373]

Mon, 09 December 2013 09:50

Maarten Bezemer

Messages: 117
Registered: February 2012

Senior Member

I have submitted bug report #419001 (and a patch) a while ago, to add a new interface for the Model class.
The patch changes concordance to use the interface instead of the class, so it is possible to provide other implementations (e.g. one that uses the ModelEditingDomain to get hold of the model data).

Unfortunately, there was not any response to my report, so I'll try here.
Could someone provide feedback whether the patch is OK and is going to be implemented, or whether there needs to be things changed?
(I am kind of waiting for response before I continue modifying my application into this direction, to prevent reverting my work if this patch/method is rejected)

Report message to a moderator