Home » Modeling » Epsilon » Concordance documentation
| | |
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.
|
|
| | |
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.
|
|
|
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 RoseQuote: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 RoseQuote: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 RoseRight 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 RoseQuote: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...
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) )
Louis RoseIf 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
|
|
|
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.
|
|
|
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...
|
|
| | | | |
Goto Forum:
Current Time: Mon Sep 23 19:21:58 GMT 2024
Powered by FUDForum. Page generated in 0.04238 seconds
|