http://wiki.eclipse.org/api.php?action=feedcontributions&user=Stephane.bouchet.obeo.fr&feedformat=atomEclipsepedia - User contributions [en]2016-12-10T02:48:56ZUser contributionsMediaWiki 1.26.2http://wiki.eclipse.org/index.php?title=EEF/Installation_Guide&diff=302370EEF/Installation Guide2012-05-16T09:41:29Z<p>Stephane.bouchet.obeo.fr: /* EEF Installation */</p>
<hr />
<div>== EEF Installation ==<br />
=== Using update sites ===<br />
<br />
* Add the EEF update site ( it contains all the releases from 0.8 )<br />
<br />
http://download.eclipse.org/modeling/emft/eef/updates/releases<br />
<br />
* Looking for an older version ? <br />
<br />
EEF 1.1 is located here : http://download.eclipse.org/modeling/emft/eef/updates/releases/1.1<br />
<br />
EEF 1.0 is located here : http://download.eclipse.org/modeling/emft/eef/updates/releases/1.0<br />
<br />
EEF 0.9 is located here : http://download.eclipse.org/modeling/emft/eef/updates/releases/0.9<br />
<br />
EEF 0.8 is located here : http://download.eclipse.org/modeling/emft/eef/updates/releases/0.8<br />
<br />
EEF 0.7 does not provides an update site.<br />
<br />
* looking for development builds ? (WARNING, some builds are not qualified, [http://www.eclipse.org/modeling/downloads/build-types.php explanation of the different build types here]):<br />
** Stables ( includes Milestones and Releases Candidates ) : http://download.eclipse.org/modeling/emft/eef/updates/milestones/1.1<br />
** Interim ( includes Integration and Maintenance ) : http://download.eclipse.org/modeling/emft/eef/updates/interim/1.1<br />
** Nightly : http://download.eclipse.org/modeling/emft/eef/updates/nightly/1.1<br />
<br />
<br />
=== From Annual release train ===<br />
<br />
*EEF is integrated in the annual eclipse release train ! Just find it in the installable softwares.<br />
<br />
=== From Eclipse modeling package ===<br />
<br />
*Use the modeling discovery Ui and choose EEF !<br />
<br />
=== Directly from eclipse.org ===<br />
<br />
You can also access to the archived EEF update site and SDK here : http://www.eclipse.org/modeling/emft/downloads/?project=eef<br />
<br />
== Third Parties ==<br />
<br />
EEF extension requires the RichText plugin of the EPF project. We aren't able to provide a P2 artifact for this plugin, you download it on the EPF website. Here is the download page where you can found the RichText feature : http://www.eclipse.org/epf/downloads/tool/epf1.5.0_downloads.php .<br />
<br />
You only need the RichText feature, so you have to download the RichText specific feature like http://www.eclipse.org/downloads/download.php?file=/technology/epf/composer/release/epfc-richtext-1.5.1.1-win32.zip or http://www.eclipse.org/downloads/download.php?file=/technology/epf/composer/release/epfc-richtext-1.5.1.1-linux.zip.<br />
<br />
[[Category:EEF]]</div>Stephane.bouchet.obeo.frhttp://wiki.eclipse.org/index.php?title=EEF/Metrics&diff=295900EEF/Metrics2012-03-30T13:26:30Z<p>Stephane.bouchet.obeo.fr: </p>
<hr />
<div><br />
Since Helios release, projects should provide some summary metrics, such as number of bundles, number of committers, lines of code, number of bugs opened and fixed...<br />
<br />
For global stats, you can check also the ohloh page : https://www.ohloh.net/p/eef<br />
<br />
=Committers=<br />
<br />
* Goulwen Le Fur, Obeo - Project lead<br />
* Nathalie Lépine, Obeo<br />
* Stéphane Bouchet, Obeo<br />
* Patrick Tessier, CEA List - UML codegen maintainer<br />
<br />
=Helios=<br />
<br />
* number of bundles : 6<br />
* lines of code : ~ 150 000 ( mostly generated )<br />
* units tests : 125 ( mostly the generated cases )<br />
* code coverage : ~ 40 % ( runtime and generated cases )<br />
* resolved bugs : 32<br />
* still open bugs : 52<br />
<br />
[[Category:EEF]]</div>Stephane.bouchet.obeo.frhttp://wiki.eclipse.org/index.php?title=EEF/Installation_Guide&diff=295899EEF/Installation Guide2012-03-30T13:23:30Z<p>Stephane.bouchet.obeo.fr: /* EEF Installation */</p>
<hr />
<div>== EEF Installation ==<br />
=== Using update sites ===<br />
<br />
* Add the EEF update site ( it contains all the releases from 0.8 )<br />
<br />
http://download.eclipse.org/modeling/emft/eef/updates/releases<br />
<br />
* Looking for an older version ? <br />
<br />
EEF 1.0 is located here : http://download.eclipse.org/modeling/emft/eef/updates/releases/1.0<br />
<br />
EEF 0.9 is located here : http://download.eclipse.org/modeling/emft/eef/updates/releases/0.9<br />
<br />
EEF 0.8 is located here : http://download.eclipse.org/modeling/emft/eef/updates/releases/0.8<br />
<br />
EEF 0.7 does not provides an update site.<br />
<br />
* looking for development builds ? (WARNING, some builds are not qualified, [http://www.eclipse.org/modeling/downloads/build-types.php explanation of the different build types here]):<br />
** Stables ( includes Milestones and Releases Candidates ) : http://download.eclipse.org/modeling/emft/eef/updates/milestones/1.1<br />
** Interim ( includes Integration and Maintenance ) : http://download.eclipse.org/modeling/emft/eef/updates/interim/1.1<br />
** Nightly : http://download.eclipse.org/modeling/emft/eef/updates/nightly/1.1<br />
<br />
<br />
=== From Annual release train ===<br />
<br />
*EEF is integrated in the annual eclipse release train ! Just find it in the installable softwares.<br />
<br />
=== From Eclipse modeling package ===<br />
<br />
*Use the modeling discovery Ui and choose EEF !<br />
<br />
=== Directly from eclipse.org ===<br />
<br />
You can also access to the archived EEF update site and SDK here : http://www.eclipse.org/modeling/emft/downloads/?project=eef<br />
<br />
== Third Parties ==<br />
<br />
EEF extension requires the RichText plugin of the EPF project. We aren't able to provide a P2 artifact for this plugin, you download it on the EPF website. Here is the download page where you can found the RichText feature : http://www.eclipse.org/epf/downloads/tool/epf1.5.0_downloads.php .<br />
<br />
You only need the RichText feature, so you have to download the RichText specific feature like http://www.eclipse.org/downloads/download.php?file=/technology/epf/composer/release/epfc-richtext-1.5.1.1-win32.zip or http://www.eclipse.org/downloads/download.php?file=/technology/epf/composer/release/epfc-richtext-1.5.1.1-linux.zip.<br />
<br />
[[Category:EEF]]</div>Stephane.bouchet.obeo.frhttp://wiki.eclipse.org/index.php?title=EEF/Releng_Guide&diff=289084EEF/Releng Guide2012-02-08T11:00:02Z<p>Stephane.bouchet.obeo.fr: /* EEF Releng HOW TO */</p>
<hr />
<div>= EEF Releng HOW TO =<br />
The EEF project is built using [[Athena Common Build]], [[Buckminster]] and [[Tycho]].<br />
== How to start a build? ==<br />
<br />
=== Automatically ===<br />
<br />
* Nightly builds are run every 6 hours everyday, at 03:41, 09:41, 15:41 and 21:41 EST, monitoring every change in CVS.<br />
<br />
=== Manually ===<br />
<br />
* Only committers in the EEF project can launch build jobs from Hudson. ( do not forget to login )<br />
* 0.8 build [Athena] : go to the [https://hudson.eclipse.org/hudson/job/emf-eef-0.8/ 0.8.x job]<br />
* 0.9 build [buckminster] : go to the [https://hudson.eclipse.org/hudson/job/emf-eef-0.9/ 0.9.x job]<br />
* 1.0 build [buckminster] : go to the [https://hudson.eclipse.org/hudson/job/emf-eef-1.0/ 1.0.x job]<br />
* 1.1 build [tycho] : go to the [https://hudson.eclipse.org/hudson/job/emf-eef-master/ 1.1.x job]<br />
<br />
Then:<br />
* In Hudson, click on '''Build Now''', change the build parameters as needed (see [[#Build parameters]]), and click on '''Build'''.<br />
* You can then click on the job name in the ''Build History'' section in the left column, and then on '''Console Output''', to follow build progress in real time.<br />
<br />
== How to test a build? ==<br />
you can test the latest successful build directly on hudson using the update site URL below : <br />
* 1.1 build : https://hudson.eclipse.org/hudson/job/emf-eef-master/lastSuccessfulBuild/artifact/org.eclipse.emf/org.eclipse.emf.eef/releng/org.eclipse.emf.eef.update/target/repository/<br />
* 1.0 build : https://hudson.eclipse.org/hudson/job/emf-eef-1.0/lastSuccessfulBuild/artifact/EEF.p2.repository/<br />
* 0.9 build : https://hudson.eclipse.org/hudson/job/emf-eef-0.9/lastSuccessfulBuild/artifact/EEF.p2.repository/<br />
* 0.8 build : this build only provides a zipped update site.<br />
<br />
Use with caution, the contents can be totally untested.<br />
<br />
== How to publish a build? ==<br />
=== Automatically ===<br />
All successful builds are automatically published to download.eclipse.org once a day.<br />
These promote actions are done by a cron job on the build server : <br />
<br />
# daily 1.1 EEF builds<br />
4 11 * * * ant -f /shared/jobs/emf-eef-master/lastSuccessful/archive/org.eclipse.emf/org.eclipse.emf.eef/releng/org.eclipse.emf.eef.update/target/promotion/promoter.xml -verbose &gt; cronLog-1.1.txt<br />
# daily 1.0 EEF builds<br />
3 17 * * * ant -f /shared/jobs/emf-eef-1.0/lastSuccessful/archive/publishroot/publisher.ant -verbose &gt; cronLog-1.0.txt<br />
# daily 0.9 EEF builds<br />
5 22 * * * ant -f /shared/jobs/emf-eef-0.9/lastSuccessful/archive/publishroot/publisher.ant -verbose &gt; cronLog-0.9.txt<br />
# weekly 0.8 EEF builds<br />
12 19 * * 2 bash /shared/jobs/emf-eef-integration/workspace/org.eclipse.emf/org.eclipse.emf.eef/releng/bash-promote-I.sh<br />
<br />
The called scripts unpack the update sites in the correct places, and copies the necessary files in correct places, too.<br />
<br />
These builds can then be seen and downloaded from [http://www.eclipse.org/modeling/emft/downloads/?project=eef the EEF download page], where additional information is available (test results, build log, build configuration, build dependencies).<br />
<br />
See also the [[EEF_Installation_Guide | EEF Installation page]] to use the update sites if wanted.<br />
<br />
=== Manually ===<br />
you can manually publish a successful build, a Release build for example.<br />
After testing, ssh to build.eclipse.org with commiter id and password and use the above script depending on what build you want to promote.<br />
<br />
== Build parameters ==<br />
<br />
=== Buckminster based builds [0.9-1.0]===<br />
* PROJECTID : modeling.emft.eef : no reason to change this<br />
* VERSION : the version being built.<br />
* BUILDTYPE : the kind of build, represented by a code letter (see [http://www.eclipse.org/modeling/downloads/build-types.php this page]):<br />
** '''N''': Nightly<br />
** '''I''': Integration<br />
** '''M''': Maintenance ('''NOT''' milestone)<br />
** '''S''': Stable (for Milestones and Release Candidate builds)<br />
** '''R''': Release<br />
* BUILDALIAS : for release, maintenance and stable builds, use this option to give a more meaningful name to the build. For example, add &lt;code&gt;0.8.0M2&lt;/code&gt; to get &quot;EEF-SDK-incubation-0.8.0M2.zip&quot; instead of &quot;EEF-SDK-incubation-Sxxxx.zip&quot;.<br />
* FETCHTAG : Force a specific tag to be used when pulling sources from CVS. For example, use &lt;code&gt;HEAD&lt;/code&gt; to build from HEAD instead of from the versions specified in the releng project's map files.<br />
<br />
=== Tycho builds [1.1]===<br />
* BUILD_TYPE : the kind of build, represented by a code letter (see [http://www.eclipse.org/modeling/downloads/build-types.php this page]):<br />
** '''N''': Nightly<br />
** '''I''': Integration<br />
** '''S''': Stable (for Milestones and Release Candidate builds)<br />
** '''R''': Release<br />
* BUILD_ALIAS : for release, maintenance and stable builds, use this option to give a more meaningful name to the build. For example, add &lt;code&gt;1.1.0M2&lt;/code&gt; to get &quot;EEF-SDK-1.1.0M2.zip&quot; instead of &quot;EEF-SDK-Sxxxx.zip&quot;.<br />
* BUILD_SIGN : set to true when building a S or R, for signing the repo<br />
<br />
== Building locally ==<br />
<br />
First, checkout EEF projects into your workspace :pserver:dev.eclipse.org:/cvsroot/modeling,org.eclipse.emf/org.eclipse.emf.eef/ <br />
<br />
Then install maven 3 somewhere in your filesystem.<br />
<br />
Then simply use the external tool launch configuration to build EEF with tycho. Modify the path of the program to launch to point to the maven3 installation directory.<br />
<br />
=Retention Policy=<br />
<br />
== Code in SCM ==<br />
<br />
Any code that was included in a Release, is left in SCM forever. For all major version, a branch is created with a convenient name, like &quot;0_8_BRANCH&quot;. For each Released version, a tag is created with convenient name, like &quot;0_8_0_RELEASE&quot;.<br />
<br />
== Distributions in zip files ==<br />
<br />
Formal releases are kept forever, but only the most recent release is kept on the main download page ( see [http://wiki.eclipse.org/EEF_Installation_Guide installation guide] ). Other, older distributions can be found on the archive site. <br />
<br />
While developing a new releases, ALL milestone builds are kept until the release, at which point they are deleted. <br />
<br />
Similarly, while developing a milestone, weekly integration builds are kept until the milestone is available, and then they are deleted.<br />
<br />
Finally, while developing an integration build, nightly are kept until the integration is available, and then they are deleted.<br />
<br />
== Features in update site repository == <br />
<br />
EEF provides only p2 repository.<br />
<br />
Like distribution in zip files, all releases are kept forever on update sites. For each release, there will be a composite repository that aggregates all the releases for a major version. <br />
<br />
While developing a new releases, ALL milestone updates sites are kept until the release, at which point they are deleted. <br />
<br />
Similarly, while developing a milestone, weekly integration updates sites are kept until the milestone is available, and then they are deleted.<br />
<br />
Finally, while developing an integration updates sites, nightly are kept until the integration is available, and then they are deleted.<br />
<br />
see [http://wiki.eclipse.org/EEF_Installation_Guide installation guide] for the list of available update sites.<br />
<br />
[[Category:EEF]]<br />
[[Category:Releng]]<br />
[[Category:Athena Common Build Users]]</div>Stephane.bouchet.obeo.frhttp://wiki.eclipse.org/index.php?title=EEF/Releng_Guide&diff=289083EEF/Releng Guide2012-02-08T10:58:45Z<p>Stephane.bouchet.obeo.fr: /* Building locally */</p>
<hr />
<div>= EEF Releng HOW TO =<br />
The EEF project is built using [[Athena Common Build]],[[Buckminster]] and [[Tycho]].<br />
== How to start a build? ==<br />
<br />
=== Automatically ===<br />
<br />
* Nightly builds are run every 6 hours everyday, at 03:41, 09:41, 15:41 and 21:41 EST, monitoring every change in CVS.<br />
<br />
=== Manually ===<br />
<br />
* Only committers in the EEF project can launch build jobs from Hudson. ( do not forget to login )<br />
* 0.8 build [Athena] : go to the [https://hudson.eclipse.org/hudson/job/emf-eef-0.8/ 0.8.x job]<br />
* 0.9 build [buckminster] : go to the [https://hudson.eclipse.org/hudson/job/emf-eef-0.9/ 0.9.x job]<br />
* 1.0 build [buckminster] : go to the [https://hudson.eclipse.org/hudson/job/emf-eef-1.0/ 1.0.x job]<br />
* 1.1 build [tycho] : go to the [https://hudson.eclipse.org/hudson/job/emf-eef-master/ 1.1.x job]<br />
<br />
Then:<br />
* In Hudson, click on '''Build Now''', change the build parameters as needed (see [[#Build parameters]]), and click on '''Build'''.<br />
* You can then click on the job name in the ''Build History'' section in the left column, and then on '''Console Output''', to follow build progress in real time.<br />
<br />
== How to test a build? ==<br />
you can test the latest successful build directly on hudson using the update site URL below : <br />
* 1.1 build : https://hudson.eclipse.org/hudson/job/emf-eef-master/lastSuccessfulBuild/artifact/org.eclipse.emf/org.eclipse.emf.eef/releng/org.eclipse.emf.eef.update/target/repository/<br />
* 1.0 build : https://hudson.eclipse.org/hudson/job/emf-eef-1.0/lastSuccessfulBuild/artifact/EEF.p2.repository/<br />
* 0.9 build : https://hudson.eclipse.org/hudson/job/emf-eef-0.9/lastSuccessfulBuild/artifact/EEF.p2.repository/<br />
* 0.8 build : this build only provides a zipped update site.<br />
<br />
Use with caution, the contents can be totally untested.<br />
<br />
== How to publish a build? ==<br />
=== Automatically ===<br />
All successful builds are automatically published to download.eclipse.org once a day.<br />
These promote actions are done by a cron job on the build server : <br />
<br />
# daily 1.1 EEF builds<br />
4 11 * * * ant -f /shared/jobs/emf-eef-master/lastSuccessful/archive/org.eclipse.emf/org.eclipse.emf.eef/releng/org.eclipse.emf.eef.update/target/promotion/promoter.xml -verbose &gt; cronLog-1.1.txt<br />
# daily 1.0 EEF builds<br />
3 17 * * * ant -f /shared/jobs/emf-eef-1.0/lastSuccessful/archive/publishroot/publisher.ant -verbose &gt; cronLog-1.0.txt<br />
# daily 0.9 EEF builds<br />
5 22 * * * ant -f /shared/jobs/emf-eef-0.9/lastSuccessful/archive/publishroot/publisher.ant -verbose &gt; cronLog-0.9.txt<br />
# weekly 0.8 EEF builds<br />
12 19 * * 2 bash /shared/jobs/emf-eef-integration/workspace/org.eclipse.emf/org.eclipse.emf.eef/releng/bash-promote-I.sh<br />
<br />
The called scripts unpack the update sites in the correct places, and copies the necessary files in correct places, too.<br />
<br />
These builds can then be seen and downloaded from [http://www.eclipse.org/modeling/emft/downloads/?project=eef the EEF download page], where additional information is available (test results, build log, build configuration, build dependencies).<br />
<br />
See also the [[EEF_Installation_Guide | EEF Installation page]] to use the update sites if wanted.<br />
<br />
=== Manually ===<br />
you can manually publish a successful build, a Release build for example.<br />
After testing, ssh to build.eclipse.org with commiter id and password and use the above script depending on what build you want to promote.<br />
<br />
== Build parameters ==<br />
<br />
=== Buckminster based builds [0.9-1.0]===<br />
* PROJECTID : modeling.emft.eef : no reason to change this<br />
* VERSION : the version being built.<br />
* BUILDTYPE : the kind of build, represented by a code letter (see [http://www.eclipse.org/modeling/downloads/build-types.php this page]):<br />
** '''N''': Nightly<br />
** '''I''': Integration<br />
** '''M''': Maintenance ('''NOT''' milestone)<br />
** '''S''': Stable (for Milestones and Release Candidate builds)<br />
** '''R''': Release<br />
* BUILDALIAS : for release, maintenance and stable builds, use this option to give a more meaningful name to the build. For example, add &lt;code&gt;0.8.0M2&lt;/code&gt; to get &quot;EEF-SDK-incubation-0.8.0M2.zip&quot; instead of &quot;EEF-SDK-incubation-Sxxxx.zip&quot;.<br />
* FETCHTAG : Force a specific tag to be used when pulling sources from CVS. For example, use &lt;code&gt;HEAD&lt;/code&gt; to build from HEAD instead of from the versions specified in the releng project's map files.<br />
<br />
=== Tycho builds [1.1]===<br />
* BUILD_TYPE : the kind of build, represented by a code letter (see [http://www.eclipse.org/modeling/downloads/build-types.php this page]):<br />
** '''N''': Nightly<br />
** '''I''': Integration<br />
** '''S''': Stable (for Milestones and Release Candidate builds)<br />
** '''R''': Release<br />
* BUILD_ALIAS : for release, maintenance and stable builds, use this option to give a more meaningful name to the build. For example, add &lt;code&gt;1.1.0M2&lt;/code&gt; to get &quot;EEF-SDK-1.1.0M2.zip&quot; instead of &quot;EEF-SDK-Sxxxx.zip&quot;.<br />
* BUILD_SIGN : set to true when building a S or R, for signing the repo<br />
<br />
== Building locally ==<br />
<br />
First, checkout EEF projects into your workspace :pserver:dev.eclipse.org:/cvsroot/modeling,org.eclipse.emf/org.eclipse.emf.eef/ <br />
<br />
Then install maven 3 somewhere in your filesystem.<br />
<br />
Then simply use the external tool launch configuration to build EEF with tycho. Modify the path of the program to launch to point to the maven3 installation directory.<br />
<br />
=Retention Policy=<br />
<br />
== Code in SCM ==<br />
<br />
Any code that was included in a Release, is left in SCM forever. For all major version, a branch is created with a convenient name, like &quot;0_8_BRANCH&quot;. For each Released version, a tag is created with convenient name, like &quot;0_8_0_RELEASE&quot;.<br />
<br />
== Distributions in zip files ==<br />
<br />
Formal releases are kept forever, but only the most recent release is kept on the main download page ( see [http://wiki.eclipse.org/EEF_Installation_Guide installation guide] ). Other, older distributions can be found on the archive site. <br />
<br />
While developing a new releases, ALL milestone builds are kept until the release, at which point they are deleted. <br />
<br />
Similarly, while developing a milestone, weekly integration builds are kept until the milestone is available, and then they are deleted.<br />
<br />
Finally, while developing an integration build, nightly are kept until the integration is available, and then they are deleted.<br />
<br />
== Features in update site repository == <br />
<br />
EEF provides only p2 repository.<br />
<br />
Like distribution in zip files, all releases are kept forever on update sites. For each release, there will be a composite repository that aggregates all the releases for a major version. <br />
<br />
While developing a new releases, ALL milestone updates sites are kept until the release, at which point they are deleted. <br />
<br />
Similarly, while developing a milestone, weekly integration updates sites are kept until the milestone is available, and then they are deleted.<br />
<br />
Finally, while developing an integration updates sites, nightly are kept until the integration is available, and then they are deleted.<br />
<br />
see [http://wiki.eclipse.org/EEF_Installation_Guide installation guide] for the list of available update sites.<br />
<br />
[[Category:EEF]]<br />
[[Category:Releng]]<br />
[[Category:Athena Common Build Users]]</div>Stephane.bouchet.obeo.frhttp://wiki.eclipse.org/index.php?title=EEF/Releng_Guide&diff=289072EEF/Releng Guide2012-02-08T10:33:51Z<p>Stephane.bouchet.obeo.fr: </p>
<hr />
<div>= EEF Releng HOW TO =<br />
The EEF project is built using [[Athena Common Build]],[[Buckminster]] and [[Tycho]].<br />
== How to start a build? ==<br />
<br />
=== Automatically ===<br />
<br />
* Nightly builds are run every 6 hours everyday, at 03:41, 09:41, 15:41 and 21:41 EST, monitoring every change in CVS.<br />
<br />
=== Manually ===<br />
<br />
* Only committers in the EEF project can launch build jobs from Hudson. ( do not forget to login )<br />
* 0.8 build [Athena] : go to the [https://hudson.eclipse.org/hudson/job/emf-eef-0.8/ 0.8.x job]<br />
* 0.9 build [buckminster] : go to the [https://hudson.eclipse.org/hudson/job/emf-eef-0.9/ 0.9.x job]<br />
* 1.0 build [buckminster] : go to the [https://hudson.eclipse.org/hudson/job/emf-eef-1.0/ 1.0.x job]<br />
* 1.1 build [tycho] : go to the [https://hudson.eclipse.org/hudson/job/emf-eef-master/ 1.1.x job]<br />
<br />
Then:<br />
* In Hudson, click on '''Build Now''', change the build parameters as needed (see [[#Build parameters]]), and click on '''Build'''.<br />
* You can then click on the job name in the ''Build History'' section in the left column, and then on '''Console Output''', to follow build progress in real time.<br />
<br />
== How to test a build? ==<br />
you can test the latest successful build directly on hudson using the update site URL below : <br />
* 1.1 build : https://hudson.eclipse.org/hudson/job/emf-eef-master/lastSuccessfulBuild/artifact/org.eclipse.emf/org.eclipse.emf.eef/releng/org.eclipse.emf.eef.update/target/repository/<br />
* 1.0 build : https://hudson.eclipse.org/hudson/job/emf-eef-1.0/lastSuccessfulBuild/artifact/EEF.p2.repository/<br />
* 0.9 build : https://hudson.eclipse.org/hudson/job/emf-eef-0.9/lastSuccessfulBuild/artifact/EEF.p2.repository/<br />
* 0.8 build : this build only provides a zipped update site.<br />
<br />
Use with caution, the contents can be totally untested.<br />
<br />
== How to publish a build? ==<br />
=== Automatically ===<br />
All successful builds are automatically published to download.eclipse.org once a day.<br />
These promote actions are done by a cron job on the build server : <br />
<br />
# daily 1.1 EEF builds<br />
4 11 * * * ant -f /shared/jobs/emf-eef-master/lastSuccessful/archive/org.eclipse.emf/org.eclipse.emf.eef/releng/org.eclipse.emf.eef.update/target/promotion/promoter.xml -verbose &gt; cronLog-1.1.txt<br />
# daily 1.0 EEF builds<br />
3 17 * * * ant -f /shared/jobs/emf-eef-1.0/lastSuccessful/archive/publishroot/publisher.ant -verbose &gt; cronLog-1.0.txt<br />
# daily 0.9 EEF builds<br />
5 22 * * * ant -f /shared/jobs/emf-eef-0.9/lastSuccessful/archive/publishroot/publisher.ant -verbose &gt; cronLog-0.9.txt<br />
# weekly 0.8 EEF builds<br />
12 19 * * 2 bash /shared/jobs/emf-eef-integration/workspace/org.eclipse.emf/org.eclipse.emf.eef/releng/bash-promote-I.sh<br />
<br />
The called scripts unpack the update sites in the correct places, and copies the necessary files in correct places, too.<br />
<br />
These builds can then be seen and downloaded from [http://www.eclipse.org/modeling/emft/downloads/?project=eef the EEF download page], where additional information is available (test results, build log, build configuration, build dependencies).<br />
<br />
See also the [[EEF_Installation_Guide | EEF Installation page]] to use the update sites if wanted.<br />
<br />
=== Manually ===<br />
you can manually publish a successful build, a Release build for example.<br />
After testing, ssh to build.eclipse.org with commiter id and password and use the above script depending on what build you want to promote.<br />
<br />
== Build parameters ==<br />
<br />
=== Buckminster based builds [0.9-1.0]===<br />
* PROJECTID : modeling.emft.eef : no reason to change this<br />
* VERSION : the version being built.<br />
* BUILDTYPE : the kind of build, represented by a code letter (see [http://www.eclipse.org/modeling/downloads/build-types.php this page]):<br />
** '''N''': Nightly<br />
** '''I''': Integration<br />
** '''M''': Maintenance ('''NOT''' milestone)<br />
** '''S''': Stable (for Milestones and Release Candidate builds)<br />
** '''R''': Release<br />
* BUILDALIAS : for release, maintenance and stable builds, use this option to give a more meaningful name to the build. For example, add &lt;code&gt;0.8.0M2&lt;/code&gt; to get &quot;EEF-SDK-incubation-0.8.0M2.zip&quot; instead of &quot;EEF-SDK-incubation-Sxxxx.zip&quot;.<br />
* FETCHTAG : Force a specific tag to be used when pulling sources from CVS. For example, use &lt;code&gt;HEAD&lt;/code&gt; to build from HEAD instead of from the versions specified in the releng project's map files.<br />
<br />
=== Tycho builds [1.1]===<br />
* BUILD_TYPE : the kind of build, represented by a code letter (see [http://www.eclipse.org/modeling/downloads/build-types.php this page]):<br />
** '''N''': Nightly<br />
** '''I''': Integration<br />
** '''S''': Stable (for Milestones and Release Candidate builds)<br />
** '''R''': Release<br />
* BUILD_ALIAS : for release, maintenance and stable builds, use this option to give a more meaningful name to the build. For example, add &lt;code&gt;1.1.0M2&lt;/code&gt; to get &quot;EEF-SDK-1.1.0M2.zip&quot; instead of &quot;EEF-SDK-Sxxxx.zip&quot;.<br />
* BUILD_SIGN : set to true when building a S or R, for signing the repo<br />
<br />
== Building locally ==<br />
<br />
First, checkout EEF projects into your workspace, [[EEF_Sources | see this page]].<br />
<br />
Checkout also the releng projects : <br />
* :pserver:dev.eclipse.org:/cvsroot/modeling,org.eclipse.emf/org.eclipse.emf.eef/releng<br />
* :pserver:dev.eclipse.org:/cvsroot/technology,org.eclipse.dash/athena/org.eclipse.dash.commonbuilder/org.eclipse.dash.common.releng,org.eclipse.dash.common.releng<br />
* :pserver:dev.eclipse.org:/cvsroot/eclipse,org.eclipse.releng.basebuilder,org.eclipse.releng.basebuilder,r35x_v20090811<br />
<br />
Then, setup the &lt;code&gt;build.properties&lt;code&gt; file in the releng project with correct information for your system:<br />
* Set all the &lt;code&gt;JAVA*_HOME&lt;/code&gt; properties to the location of your JDK install (eg: &lt;code&gt;/usr/lib/jvm/java-1.6.0-openjdk&lt;/code&gt; or &lt;code&gt;C:/Program Files/Java/jdk1.6.0_16&lt;/code&gt;)<br />
* Set the &lt;code&gt;WORKSPACE&lt;/code&gt; property to a writable directory (eg: &lt;code&gt;/tmp&lt;/code&gt; or &lt;code&gt;C:/temp&lt;/code&gt;)<br />
* change the &lt;code&gt;dependencyURLs&lt;/code&gt; with the Eclipse SDK zip specific to your platform<br />
<br />
Additionally, you should change all the &lt;code&gt;dependencyURLs&lt;/code&gt; to point to one of your local Eclipse mirrors, to avoid saturating the main Eclipse download server, and getting extremely slow downloads.<br />
<br />
Alternatively, you can download the dependencies manually and put them in your &lt;code&gt;downloadsDir&lt;/code&gt;. The build will then use the files you provided instead of downloading them itself.<br />
<br />
Finally, start the build by right-clicking the &lt;code&gt;build.xml&lt;/code&gt; file in the releng project inside Eclipse and choosing '''Run as &gt; Ant Build'''.<br />
<br />
=Retention Policy=<br />
<br />
== Code in SCM ==<br />
<br />
Any code that was included in a Release, is left in SCM forever. For all major version, a branch is created with a convenient name, like &quot;0_8_BRANCH&quot;. For each Released version, a tag is created with convenient name, like &quot;0_8_0_RELEASE&quot;.<br />
<br />
== Distributions in zip files ==<br />
<br />
Formal releases are kept forever, but only the most recent release is kept on the main download page ( see [http://wiki.eclipse.org/EEF_Installation_Guide installation guide] ). Other, older distributions can be found on the archive site. <br />
<br />
While developing a new releases, ALL milestone builds are kept until the release, at which point they are deleted. <br />
<br />
Similarly, while developing a milestone, weekly integration builds are kept until the milestone is available, and then they are deleted.<br />
<br />
Finally, while developing an integration build, nightly are kept until the integration is available, and then they are deleted.<br />
<br />
== Features in update site repository == <br />
<br />
EEF provides only p2 repository.<br />
<br />
Like distribution in zip files, all releases are kept forever on update sites. For each release, there will be a composite repository that aggregates all the releases for a major version. <br />
<br />
While developing a new releases, ALL milestone updates sites are kept until the release, at which point they are deleted. <br />
<br />
Similarly, while developing a milestone, weekly integration updates sites are kept until the milestone is available, and then they are deleted.<br />
<br />
Finally, while developing an integration updates sites, nightly are kept until the integration is available, and then they are deleted.<br />
<br />
see [http://wiki.eclipse.org/EEF_Installation_Guide installation guide] for the list of available update sites.<br />
<br />
[[Category:EEF]]<br />
[[Category:Releng]]<br />
[[Category:Athena Common Build Users]]</div>Stephane.bouchet.obeo.frhttp://wiki.eclipse.org/index.php?title=EEF/User_Guide/Custom_Element_Editor&diff=284041EEF/User Guide/Custom Element Editor2012-01-06T09:46:46Z<p>Stephane.bouchet.obeo.fr: /* Modifying the PropertiesEditionPartForm */</p>
<hr />
<div>== Need of new widgets ? ==<br />
<br />
EEF generators offer a set of widgets to build EMF editing forms. Sometimes needs for other widgets appear in order to create more efficient GUIs. In this case, EEF provides ''CustomElementEditor'' to generate user code areas inside the EEF properties code.<br />
<br />
Let's start this tutorial with this sample Ecore model :<br />
<br />
[[Image:EEF_SampleCustomPEE_Metamodel.png|Ecore model for CustomElementEditor sample]]<br />
<br />
By following the [[../../Tutorials/First_Generation | first generation tutorial]], EEF generates these forms :<br />
<br />
[[Image:EEF_CustomPEESample_Standard_result.png | Standard result]]<br />
<br />
Now suppose we want to use a [http://www.eclipse.org/swt/snippets/#spinner spinner] instead of a Text for the age entry. Spinners aren't yet available in the EEF generation. We may, in this case, use a ''CustomElementEditor''.<br />
<br />
{{tip | The ''CustomElementEditor'' is fully operational since the 1.1.0 version of EEF }}<br />
<br />
== CustomElementEditor in the EEF models ==<br />
<br />
The first step is to replace the ElementEditor generated by the EEF Initializer with a CustomElementEditor. This must be done in the View associated to our EClass Person, the &quot;Person&quot; View.<br />
<br />
[[Image:SampleCEE_Viewsmodelchange.png| CustomElementEditor in views model]]<br />
<br />
The removed ElementEditor was defined as the view of the &quot;age&quot; PropertiesEditionElement of the &quot;Person&quot; PropertiesEditionComponent. We need to define our CustomElementEditor as the new &quot;age&quot; PropertiesEditionElement view.<br />
<br />
[[Image:EEF_SampleCEE_Componentsmodelchange.png | Referencing the CustomElementEditor in the associated PropertiesEditionElement]]<br />
<br />
These changes made, we can regenerate the EEF code.<br />
<br />
== Modifying the generated code ==<br />
<br />
By using CustomElementEditor, EEF generates user code areas in four classes. We need to complete these classes to include our own widget and to bind it with the EMF model. The four classes to modify are :<br />
* the IPropertiesEditionPart : '''XXXPropertiesEditionPart'''<br />
* the PropertiesEditionPartForm : '''XXXPropertiesEditionPartForm'''<br />
* the PropertiesEditionPartImpl : '''XXXPropertiesEditionPartImpl'''<br />
* the PropertiesEditionComponent : '''XXXPropertiesEditionComponent'''<br />
<br />
=== Modifying the IPropertiesEditionPart ===<br />
<br />
The IPropertiesEditionPart interfaces defines the view's getters and setters for each widget. As we used a CustomElementEditor, EEF has generated a user code area in the ''PersonPropertiesEditionPart'' :<br />
<br />
[[Image:EEF_SampleCEE_PartModifying.png | CustomElementEditor : User code area for PropertiesEditionPart ]]<br />
<br />
We need getter and setter for our spinner : <br />
<br />
&lt;source lang=&quot;java&quot;&gt;<br />
// Start of user code for age specific getters and setters declaration<br />
/**<br />
* @return the age<br />
* <br />
*/<br />
public String getAge();<br />
<br />
/**<br />
* Defines a new age<br />
* @param newValue the new age to set<br />
* <br />
*/<br />
public void setAge(String newValue);<br />
// End of user code<br />
&lt;/source&gt;<br />
<br />
=== Modifying the PropertiesEditionPartForm ===<br />
<br />
The PropertiesEditionPartForm is an EEF view used in a [http://www.eclipse.org/articles/Article-Forms/article.html Eclipse Forms] Context (properties views, editors, ...). As in the interface, the PropertiesEditionPartForm code contains user code areas where we can include our own widget :<br />
<br />
[[Image:EEF_SampleCEE_PartFormModifying.png | CustomElementEditor : User code areas for PropertiesEditionPartForm]]<br />
<br />
In the first area, we can define the fields we need for our own widget :<br />
&lt;source lang=java&gt;<br />
// Start of user code for age widgets declarations<br />
protected Spinner age;<br />
// End of user code<br />
&lt;/source&gt;<br />
<br />
In the third area, we can create our getter and setter. In the PropertiesEditionPart we added two methods in the interface : getAge() and setAge(), we have to implement them in this class :<br />
<br />
&lt;source lang=java&gt;<br />
// Start of user code for age specific getters and setters implementation<br />
/**<br />
* {@inheritDoc}<br />
* @see customsample.parts.PersonPropertiesEditionPart#getAge()<br />
*/<br />
public String getAge() {<br />
return String.valueOf(age.getSelection());<br />
}<br />
<br />
/**<br />
* {@inheritDoc}<br />
* @see customsample.parts.PersonPropertiesEditionPart#setAge(String newValue)<br />
*/<br />
public void setAge(String newValue) {<br />
if (newValue != null) {<br />
Integer valueOf = Integer.valueOf(newValue);<br />
age.setSelection(valueOf);<br />
} <br />
}<br />
// End of user code<br />
&lt;/source&gt;<br />
<br />
In the second area, we have to invoke the method creating our widget in the editing form :<br />
<br />
&lt;source lang=java&gt;<br />
// Start of user code for age addToPart creation<br />
if (key == CustomsampleViewsRepository.Person.Properties.age) {<br />
return createAgeSpinner(widgetFactory, parent);<br />
} <br />
// End of user code<br />
&lt;/source&gt;<br />
<br />
In this sample, we named this method ''createAgeSpinner''. This method is defined in the fourth area. We create our spinner at this point.<br />
<br />
&lt;source lang=java&gt;<br />
// Start of user code additional methods<br />
protected Composite createAgeSpinner(FormToolkit widgetFactory, Composite parent) {<br />
createDescription(parent, CustomsampleViewsRepository.Person.Properties.age, CustomsampleMessages.PersonPropertiesEditionPart_AgeLabel);<br />
age = new Spinner(parent, SWT.NONE); //$NON-NLS-1$<br />
age.setData(FormToolkit.KEY_DRAW_BORDER, FormToolkit.TEXT_BORDER);<br />
widgetFactory.paintBordersFor(parent);<br />
GridData ageData = new GridData(GridData.FILL_HORIZONTAL);<br />
age.setLayoutData(ageData);<br />
FormUtils.createHelpButton(widgetFactory, parent, propertiesEditionComponent.getHelpContent(CustomsampleViewsRepository.Person.Properties.age, CustomsampleViewsRepository.FORM_KIND), null); //$NON-NLS-1$<br />
return parent;<br />
}<br />
// End of user code<br />
&lt;/source&gt;<br />
<br />
After this step, we can relaunch our plugin to see our new widget in a Form context (basically the properties view) :<br />
<br />
[[Image:EEF_SampleCEE_FormResult.png | CustomElementEditor : Spinner in a form context]]<br />
<br />
=== Modifying the PropertiesEditionPartImpl ===<br />
<br />
The PropertiesEditionPartImpl is an EEF view used in a standard SWT Context (wizards, dialogs, ...). As in the interface, the PropertiesEditionPartImpl code contains user code areas where we can include our own widget :<br />
<br />
[[Image:EEF_SampleCEE_PartImplModifying.png | CustomElementEditor : User code areas for PropertiesEditionPartImpl]]<br />
<br />
In the first area, we can define the fields we need for our own widget :<br />
&lt;source lang=java&gt;<br />
// Start of user code for age widgets declarations<br />
protected Spinner age;<br />
// End of user code<br />
&lt;/source&gt;<br />
<br />
In the third area, we can create our getter and setter. In the PropertiesEditionPart we added two methods in the interface : getAge() and setAge(), we have to implement them in this class :<br />
<br />
&lt;source lang=java&gt;<br />
// Start of user code for age specific getters and setters implementation<br />
/**<br />
* {@inheritDoc}<br />
* @see customsample.parts.PersonPropertiesEditionPart#getAge()<br />
*/<br />
public String getAge() {<br />
return String.valueOf(age.getSelection());<br />
}<br />
<br />
/**<br />
* {@inheritDoc}<br />
* @see customsample.parts.PersonPropertiesEditionPart#setAge(String newValue)<br />
*/<br />
public void setAge(String newValue) {<br />
if (newValue != null) {<br />
Integer valueOf = Integer.valueOf(newValue);<br />
age.setSelection(valueOf);<br />
} <br />
}<br />
// End of user code<br />
&lt;/source&gt;<br />
<br />
In the second area, we have to invoke the method creating our widget in the editing form :<br />
<br />
&lt;source lang=java&gt;<br />
// Start of user code for age addToPart creation<br />
if (key == CustomsampleViewsRepository.Person.Properties.age) {<br />
return createAgeSpinner(parent);<br />
} <br />
// End of user code<br />
&lt;/source&gt;<br />
<br />
In this sample, we named this method ''createAgeSpinner''. This method is defined in the fourth area. We create our spinner at this point.<br />
<br />
&lt;source lang=java&gt;<br />
// Start of user code additional methods<br />
protected Composite createAgeSpinner(Composite parent) {<br />
createDescription(parent, CustomsampleViewsRepository.Person.Properties.age, CustomsampleMessages.PersonPropertiesEditionPart_AgeLabel);<br />
age = new Spinner(parent, SWT.BORDER); //$NON-NLS-1$<br />
GridData ageData = new GridData(GridData.FILL_HORIZONTAL);<br />
age.setLayoutData(ageData);<br />
SWTUtils.createHelpButton(parent, propertiesEditionComponent.getHelpContent(CustomsampleViewsRepository.Person.Properties.age, CustomsampleViewsRepository.FORM_KIND), null); //$NON-NLS-1$<br />
return parent;<br />
}<br />
// End of user code<br />
&lt;/source&gt;<br />
<br />
After this step, we can relaunch our plugin to see our new widget in a Form context (basically the properties view) :<br />
<br />
[[Image:EEF_SampleCEE_ImplResult.png | CustomElementEditor : Spinner in a standard swt context]]<br />
<br />
=== Modifying the PropertiesEditionComponent ===<br />
<br />
At this point, all views contain a spinner to display and edit the age attribute of a Person, but these graphical elements aren't bound to the EMF model. The last part of the tutorial consists in modifying the PropertiesEditionComponent code to enable communication between views and model.<br />
<br />
[[Image:EEF_SampleCEE_ComponentModifying.png | CustomElementEditor : User code areas for component ]]<br />
<br />
We have to edit three different areas in order to activate a binding between model and views.<br />
<br />
The first method is the ''initPart'' method. This method is called when the widgets of the managed view must be initialized with the current value of the model. In our case, we must set the current age of the person in the spinner via the setter we developed in the views.<br />
<br />
&lt;source lang=java&gt;<br />
// Start of user code for age command update<br />
if (isAccessible(CustomsampleViewsRepository.Person.Properties.age)) {<br />
basePart.setAge(EEFConverterUtil.convertToString(EcorePackage.eINSTANCE.getEInt(), person.getAge()));<br />
}<br />
// End of user code<br />
&lt;/source&gt;<br />
<br />
The second method is the ''updateSemanticModel'' method. This method is called when the value of a widget has changed in the view so the new value must be set in the model. These method is implemented like this in our case :<br />
<br />
&lt;source lang=java&gt;<br />
if (CustomsampleViewsRepository.Person.Properties.age == event.getAffectedEditor()) {<br />
// Start of user code for updateAge method body<br />
person.setAge((EEFConverterUtil.createIntFromString(EcorePackage.eINSTANCE.getEInt(), (String)event.getNewValue())));<br />
// End of user code<br />
}<br />
&lt;/source&gt;<br />
<br />
This method takes a IPropertiesEditionEvent as a parameter . This parameter is thrown by the widget in the view, we must add a piece of code to our views to handle this event. In the ''createAgeSpinner'' method of both ''PersonPropertiesEditionPartImpl'' and ''PersonPropertiesEditionPartForm'' classes, we add <br />
<br />
&lt;source lang=java&gt;<br />
age.addSelectionListener(new SelectionAdapter() {<br />
/**<br />
* {@inheritDoc}<br />
* @see org.eclipse.swt.events.SelectionAdapter#widgetSelected(org.eclipse.swt.events.SelectionEvent)<br />
*/<br />
@Override<br />
public void widgetSelected(SelectionEvent e) {<br />
if (propertiesEditionComponent != null)<br />
propertiesEditionComponent.firePropertiesChanged(new PropertiesEditionEvent(PersonPropertiesEditionPartForm.this, CustomsampleViewsRepository.Person.Properties.age, PropertiesEditionEvent.COMMIT, PropertiesEditionEvent.SET, null, String.valueOf(age.getSelection())));<br />
}<br />
});<br />
&lt;/source&gt;<br />
<br />
Finally, the last method is the ''updatePart'' method. This method is called when a property is changed in the model and we must update the value in the view. The code of this last method is : <br />
<br />
&lt;source lang=java&gt;<br />
// Start of user code for age live update<br />
if (CustomsamplePackage.eINSTANCE.getPerson_Age().equals(msg.getFeature()) &amp;&amp; basePart != null &amp;&amp; isAccessible(CustomsampleViewsRepository.Person.Properties.age)) {<br />
if (msg.getNewValue() != null) {<br />
basePart.setAge(EcoreUtil.convertToString(EcorePackage.eINSTANCE.getEInt(), msg.getNewValue()));<br />
} else {<br />
basePart.setAge(&quot;&quot;);<br />
}<br />
}<br />
// End of user code<br />
&lt;/source&gt;<br />
<br />
== Conclusion ==<br />
<br />
After these steps, our spinner is functional and can be used to set the age of the persons in our UIs. <br />
<br />
The CustomElementEditor allows EEF users to integrate any kind of widgets in their editing forms without any change in the EEF generation.</div>Stephane.bouchet.obeo.frhttp://wiki.eclipse.org/index.php?title=EMF_Compare/GMF_Notation_model_Comparison&diff=271986EMF Compare/GMF Notation model Comparison2011-10-11T14:48:44Z<p>Stephane.bouchet.obeo.fr: /* Implementation */</p>
<hr />
<div>The GMF diagram comparison task can be splitted into four parts. First, we must be able to compare GMF Notation models, then we have to know how we handle the link with the comparison of the semantic model (i.e. the elements represented by the diagram). Third, we have to know how to integrate existing GMF editor within the EMF Compare editor. Finally, we have to know how to create generic markers on the diagram to give a feedback of the computed differences to the user.<br />
<br />
== Notation model comparison ==<br />
<br />
Notation model comparison need its own MatchEngine and DiffEngine. The whole notation metamodel will not be taken into account. The difference computation will only occur on a subpart as depicted below:<br />
<br />
[[Image:gmf_notation_compare.png]]<br />
<br />
The nodes and edges will be matched by their XMI IDs. Containment between nodes will be handled in a generic way (i.e. by the super class GenericMatchEngine). <br />
<br />
Only following differences will be computed:<br />
<br />
* Addition / Removal of a node<br />
* Addition / Removal of an edge<br />
* Change of a Label on an edge or on a node<br />
* Move of a node within the diagram (with a configurable translation threshold for the move its location x/y).<br />
* Move of an edge within the diagram (total number of bendpoints, change of bendpoints - sourceX, sourceY, targetX, targetY - and positions of the anchors).<br />
<br />
== Link with the semantic comparison ==<br />
<br />
For many cases, we need the semantic comparison to be done before the graphical one. The work on logical model integration should give us this facility by computing the differences of a whole resource set instead of just the current resource containing the notation model.<br />
<br />
The link with the semantic comparison had to be provided for the labels. For each element , we have to get the text of the label and compare them. They are not stored directly into the notation model.<br />
<br />
Move operations of Edge and Node never correspond to semantic change.<br />
<br />
For addition and removal of nodes and edges, graphical differences may or may not corresponds to a semantic change. For instance, a graphical element may be removed because it has been hidden or deleted from the diagram. It does not correspond to a change in the semantic model. This graphical change does not have to be linked to a semantic change. In the other case, the addition or the removal of a node or an edge must match an addition or a deletion in the semantic model.<br />
<br />
=== Merge ===<br />
<br />
As a we don't know from the notation model how labels are build and from which feature(s) of the semantic model, the merge operation of labels modification must be applied on the notation model to trigger the appropriate underlying commands on the semantic model. This merger operation can be triggered only if the label is editable (=&gt; ask to the editpart of the view '''isEditModeEnabled()''')<br />
<br />
The merge of a move a node or an edge never triggers a merge on the semantic model, only on the graphical notation. The merge is a simple copy of values of bendpoints/layout constraints.<br />
<br />
Addition/Removal of node or edge trigger the merge of the semantic difference if it is associated to one, and the merge operation of the graphical difference otherwise. This merge operation consist of re-create the element if it has been deleted from the diagram, or to restor the hidden status of this view (View.isVisible())<br />
<br />
== Use of Difference Extensions and Hiding mechanism ==<br />
<br />
To detect the differences related to functional cases of diagram comparison, new kinds of differences (extensions) are created to complete the DiffModel.<br />
<br />
These extensions lean on the generic differences to be build and they are able to hide them.<br />
<br />
Here is the list of the generic differences which are managed and, for each of them, what are the extensions which are created and the differences which are hidden:<br />
<br />
* A '''ModelElementChangeLeftTarget''' difference, related to a ''View'', will involve the creation of a '''''DiagramModelElementChangeLeftTarget''''' difference extension. This extension will hide the '''ModelElementChangeLeftTarget''' input difference which was used to build it.<br />
<br />
* In the same way, a '''ModelElementChangeRightTarget''' difference, related to a ''View'', will involve the creation of a '''''DiagramModelElementChangeRightTarget''''' difference extension. This extension will hide the '''ModelElementChangeRightTarget''' input difference which was used to build it.<br />
<br />
* An '''UpdateAttribute''' on the ''EAttribute'' &quot;''View_visible''&quot;, where the right view is not visible and it is not a remotely change OR the right view is visible but it is a remotely change, will involve the creation of a '''''DiagramShowElement''''' difference extension. This one will hide the '''UpdateAttribute''' input difference which was used to build it.<br />
<br />
* In the same way, an '''UpdateAttribute''' on the ''EAttribute'' &quot;''View_visible''&quot;, where the left view is not visible and it is not a remotely change or the left view is visible but it is a remotely change, will involve the creation of a '''''DiagramHideElement''''' difference extension. This one will hide the '''UpdateAttribute''' input difference which was used to build it.<br />
<br />
* An '''UpdateAttribute''', where the container of its ''EAttribute'' is a ''Location'' and the related compared elements are not edges and the move is over the threshold specified in the page preferences, will involve the creation of a '''''DiagramMoveNode''''' difference extension. This extension will hide the '''UpdateAttribute''' input difference which was used to build it.<br />
<br />
* On each matched object, it is checked (in the same time as the attributes checking) if the GMF labels are different to create a '''''DiagramLabelChange''''' difference extension. This one hides no existing difference. To check the labels, the ''ITextAwareEditPart'' edit parts are retrieved and their GMF parser to get the print string and to compare them.<br />
<br />
* An '''UpdateAttribute''', where the container of its ''EAttribute'' is a ''RelativeBendpoints'' OR the ''EAttribute'' is ''IdentityAnchor_Id'', will involve the creation of a '''''DiagramEdgeChange''''' difference extension. Besides, an '''ModelElementChange''', where the related element is an ''IdentityAnchor'', will involve the creation of a '''''DiagramEdgeChange''''' difference extension too. For a same ''Edge'', it is possible to have several combined generic differences (several '''UpdateAttribute''' and '''ModelElementChange'''). To create only one extension for these ones, it is checked if there already exists a '''''DiagramEdgeChange''''' for this ''Edge'' in the building ''DiffModel''. This extension will hide the '''UpdateAttribute''' and/or '''ModelElementChange''' input differences which were used to build it.<br />
<br />
=== Mergers ===<br />
<br />
* For every difference extensions which lean on diagram changes only (no semantic changes), a single merger is used to merge these ones: ''DiagramDiffExtensionMerger''.<br />
It is the case of ''DiagramShowElement'', ''DiagramHideElement'', ''DiagramMoveNode'' and ''DiagramEdgeChange'' difference extensions. The merger retrieves all the hidden differences of the extension and call the related merger for each of them.<br />
<br />
* For ''DiagramLabelChange'', a ''DiagramlabelChangeMerger'' is used to set the new label from the GMF Command. This command allows to deploy changes on the semantic model.<br />
<br />
* For ''DiagramModelElementChangeLeftTarget'' and ''DiagramModelElementChangeRightTarget'', a respectively ''DiagramModelElementChangeLeftTargetMerger'' and ''DiagramModelElementChangeRightTargetMerger'' are used. They have the same behavior as ''DiagramDiffExtensionMerger'' unless for the merge of the delete of a ''View''. Indeed, for the add of a View, the generic merger is able to merge the ''View'' and the semantic object together. But, for the delete, it does not manage to merge the semantic difference. These 2 mergers retrieve the semantic difference to merge it before the merge of the delete of the View.<br />
<br />
== GMF editor integration within Comparison editor ==<br />
<br />
The integration of GMF editor within the comparison editor has to be done through specific contentMergeViewer (org.eclipse.compare.contentMergeViewers extension point) and maybe a specific structureMergerViewer (org.eclipse.compare.structureMergeViewers extension point) to provide the separation between graphical differences and semantic differences.<br />
<br />
The content merge viewer has to instantiate DiagramGraphicalViewer inside its '''createControls()''' method:<br />
<br />
viewer = new DiagramGraphicalViewer();<br />
viewer.createControl(composite);<br />
viewer.getControl().setBackground(ColorConstants.listBackground);<br />
<br />
The resize of the left/right/ancestor panes has to be handled gracefully like this:<br />
<br />
viewer_left.getControl().setBounds(x, y, leftWidth, height);<br />
viewer_right.getControl().setBounds(x + leftWidth + centerWidth, y, rightWidth, height);<br />
<br />
=== Initialization ===<br />
<br />
The left/right/ancestor viewers has to be initialized with a proper editing domain. This creation takes the resourceSet as input:<br />
<br />
DiagramEditingDomainFactory.getInstance().createEditingDomain(resourceset);<br />
<br />
Then, the viewers has to be configured like this: <br />
<br />
viewer.setEditDomain(new DefaultEditDomain(null)); // GEF editDomain<br />
viewer.setEditPartFactory(EditPartService.getInstance());<br />
viewer.setRootEditPart(new DiagramRootEditPart(diag.getMeasurementUnit()));<br />
viewer.setContents(diag); // the diagram from the notation model<br />
<br />
It is also possible to make the viewer uneditable by browsing all children of the rootEditPart of each viewer, but then, we will not be able to ask for the '''editability''' of views. It should be better to add a top layer that forbid the editing.<br />
<br />
== Markers for GMF diagrams ==<br />
<br />
Difference marker on notation model are provided by using the '''org.eclipse.gmf.runtime.diagram.ui.decoratorProviders''' extension point.<br />
<br />
The provided IDecoratorProvider will create a decorator based on the proposed IDecoratorTarget. This IDecoratorTarget can be adapted to a Notation View like this :<br />
<br />
View view = (View) decoratorTarget.getAdapter(View.class);<br />
<br />
The decorator should be created if, and only if, there is a graphical difference associated with the given View. The graphical difference model will be retrieved from the owning EditPart.<br />
<br />
Provided decorators has to implement IDecorator interface. <br />
<br />
The issue with specific decorator is to define the locator. Each Figure has its own bounds and we will start from the assumption that:<br />
<br />
* Marker of decorated figure will be rectangle following their bounds (smallest rectangle completely enclosing the IFigure)<br />
* Marker of decorated edges will be handled for polylines only and bounds of the decoration will be the bounds of the decorated<br />
* Marker of move will be an icon (picture not yet defined) located:<br />
** in the middle of the edge if the edge has moved<br />
** in the top right of the bounds of the figure if it is a node.<br />
<br />
See samples of first annotation prototypes (on Ecore diagram):<br />
<br />
Class added:<br />
[[Image:markedAdded.png]]<br />
<br />
Class removed:<br />
[[Image:markedRemoved.png]]<br />
<br />
Label of class changed:<br />
[[Image:markedLabel.png]]<br />
<br />
Edge marked (added)<br />
[[Image:markedEdge.png]]<br />
<br />
Edge marked (moved)<br />
[[Image:markedMovedEdge.png]]<br />
<br />
=== Implementation ===<br />
<br />
Here are some screenshots of the current development under the ericsson_integration branch of the following repository https://github.com/mbarbero/emfcompare <br />
<br />
{| cellspacing=&quot;1&quot; cellpadding=&quot;1&quot; border=&quot;1&quot;<br />
|-<br />
! align=&quot;center&quot; colspan=&quot;4&quot; | EcoreTools Tests Cases<br />
|-<br />
! align=&quot;center&quot;| Description<br />
! align=&quot;center&quot;| State<br />
! align=&quot;center&quot; colspan=&quot;2&quot;| Screenshot<br />
|-<br />
| Added nodes<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC1.png|thumb]]<br />
|-<br />
| Deleted nodes<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC2.png|thumb]]<br />
|-<br />
| Mix of added and deleted nodes<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC3.png|thumb]]<br />
|-<br />
| Added node inside a node<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC04.png|thumb]]<br />
|-<br />
| Removed node inside a node<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC05.png|thumb]]<br />
|-<br />
| Moved node<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC6.png|thumb]]<br />
| [[Image:preference.png|thumb|A move threshold can be set in the preference page to detect this change]]<br />
|-<br />
| Modified bounds of a node<br />
! style=&quot;color:red&quot; | ko<br />
| [[Image:TC7.png|thumb|not implemented]]<br />
|-<br />
| Hidden node<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC09.png|thumb]]<br />
|-<br />
| Revealed node<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC08.png|thumb]]<br />
|-<br />
| Modified label<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC10.png|thumb]]<br />
|-<br />
| Added label<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC11.png|thumb]]<br />
|-<br />
| Removed label<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC12.png|thumb]]<br />
|-<br />
| Mix of added and removed label<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC13.png|thumb]]<br />
|-<br />
| Hidden label<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC15.png|thumb]]<br />
|-<br />
| Revealed label<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC14.png|thumb]]<br />
|-<br />
| Modified label<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC16.png|thumb]]<br />
|-<br />
| Modified label<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC17.png|thumb]]<br />
|-<br />
| Added edge<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC18.png|thumb|no highlight on labels]]<br />
|-<br />
| Removed edge<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC19.png|thumb|no highlight on labels]]<br />
|-<br />
| Mix of added and removed edges<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC20.png|thumb|no highlight on labels]]<br />
|-<br />
| Moved edge<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC21.png|thumb]]<br />
|-<br />
| Modified edge label<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC23.png|thumb]]<br />
|-<br />
| Modified edge label<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC24.png|thumb]]<br />
|-<br />
| Revealed edge<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC25.png|thumb]]<br />
|-<br />
| Hidden edge<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC26.png|thumb]]<br />
|-<br />
| Revealed edge label<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC27.png|thumb]]<br />
|-<br />
| Hidden edge label<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC28.png|thumb]]<br />
|-<br />
| Removed node with edge<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC29.png|thumb| no highlight on labels]]<br />
|-<br />
| Removed node with edge ( delete from diagram )<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC30.png|thumb| no highlight on labels]]<br />
|-<br />
| Removed edge ( delete from diagram )<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC31.png|thumb| no highlight on labels]]<br />
|-<br />
| 3 WAY ; added node<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC32.png|thumb]]<br />
|-<br />
| 3 WAY ; removed node<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC33.png|thumb]]<br />
|-<br />
| 3 WAY ; moved node (remote)<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC34.png|thumb | both nodes are marked]]<br />
|-<br />
| 3 WAY ; moved node (local)<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC35.png|thumb | both nodes are marked]]<br />
|-<br />
| 3 WAY ; modified label<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC36.png|thumb]]<br />
|-<br />
| 3 WAY ; remotely hidden node<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC37.png|thumb]]<br />
|-<br />
| 3 WAY ; locally hidden node<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC38.png|thumb]]<br />
|-<br />
| 3 WAY ; remotely revealed node<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC39.png|thumb]]<br />
|-<br />
| 3 WAY ; locally revealed node<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC40.png|thumb]]<br />
|-<br />
| Multiple diagram ; Added node in sub-diagram<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC50.png|thumb]]<br />
|-<br />
| Multiple diagram ; Removed node in sub-diagram<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC51.png|thumb]]<br />
|-<br />
| Multiple diagram ; Mix of Added and Removed node in sub-diagram<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC52.png|thumb]] [[Image:TC52b.png|thumb]]<br />
|-<br />
| 3 WAY and Multiple diagram ; Modified labels in sub-diagram<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC53a.png|thumb]] [[Image:TC53b.png|thumb]]<br />
|-<br />
| Multiple diagram ; Mix of Added and Removed node and edges in sub-diagram<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC54a.png|thumb]] [[Image:TC54b.png|thumb]]<br />
|-<br />
! align=&quot;center&quot; colspan=&quot;4&quot; | Papyrus Tests Cases<br />
|-<br />
| Package diagram<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC60.png|thumb]]<br />
|-<br />
| Class diagram<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC61.png|thumb]]<br />
|-<br />
| Composite diagram<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC62.png|thumb]]<br />
|-<br />
| UseCase diagram<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC63.png|thumb]]<br />
|-<br />
| Sequence diagram<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC64.png|thumb]]<br />
|-<br />
| Activity diagram<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC65.png|thumb]]<br />
|-<br />
| StateMachine diagram<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC66.png|thumb]]<br />
|-<br />
| Communication diagram<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC67.png|thumb]]<br />
|-<br />
| Component diagram<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC68.png|thumb]]<br />
|-<br />
| Deployment diagram<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC69.png|thumb]]<br />
|-<br />
| Profile diagram<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC70.png|thumb]]<br />
|-<br />
| Multi diagrams<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC71a.png|thumb]] [[Image:TC71b.png|thumb]] [[Image:TC71c.png|thumb]]<br />
|}</div>Stephane.bouchet.obeo.frhttp://wiki.eclipse.org/index.php?title=EMF_Compare/GMF_Notation_model_Comparison&diff=271985EMF Compare/GMF Notation model Comparison2011-10-11T14:48:06Z<p>Stephane.bouchet.obeo.fr: /* Implementation */</p>
<hr />
<div>The GMF diagram comparison task can be splitted into four parts. First, we must be able to compare GMF Notation models, then we have to know how we handle the link with the comparison of the semantic model (i.e. the elements represented by the diagram). Third, we have to know how to integrate existing GMF editor within the EMF Compare editor. Finally, we have to know how to create generic markers on the diagram to give a feedback of the computed differences to the user.<br />
<br />
== Notation model comparison ==<br />
<br />
Notation model comparison need its own MatchEngine and DiffEngine. The whole notation metamodel will not be taken into account. The difference computation will only occur on a subpart as depicted below:<br />
<br />
[[Image:gmf_notation_compare.png]]<br />
<br />
The nodes and edges will be matched by their XMI IDs. Containment between nodes will be handled in a generic way (i.e. by the super class GenericMatchEngine). <br />
<br />
Only following differences will be computed:<br />
<br />
* Addition / Removal of a node<br />
* Addition / Removal of an edge<br />
* Change of a Label on an edge or on a node<br />
* Move of a node within the diagram (with a configurable translation threshold for the move its location x/y).<br />
* Move of an edge within the diagram (total number of bendpoints, change of bendpoints - sourceX, sourceY, targetX, targetY - and positions of the anchors).<br />
<br />
== Link with the semantic comparison ==<br />
<br />
For many cases, we need the semantic comparison to be done before the graphical one. The work on logical model integration should give us this facility by computing the differences of a whole resource set instead of just the current resource containing the notation model.<br />
<br />
The link with the semantic comparison had to be provided for the labels. For each element , we have to get the text of the label and compare them. They are not stored directly into the notation model.<br />
<br />
Move operations of Edge and Node never correspond to semantic change.<br />
<br />
For addition and removal of nodes and edges, graphical differences may or may not corresponds to a semantic change. For instance, a graphical element may be removed because it has been hidden or deleted from the diagram. It does not correspond to a change in the semantic model. This graphical change does not have to be linked to a semantic change. In the other case, the addition or the removal of a node or an edge must match an addition or a deletion in the semantic model.<br />
<br />
=== Merge ===<br />
<br />
As a we don't know from the notation model how labels are build and from which feature(s) of the semantic model, the merge operation of labels modification must be applied on the notation model to trigger the appropriate underlying commands on the semantic model. This merger operation can be triggered only if the label is editable (=&gt; ask to the editpart of the view '''isEditModeEnabled()''')<br />
<br />
The merge of a move a node or an edge never triggers a merge on the semantic model, only on the graphical notation. The merge is a simple copy of values of bendpoints/layout constraints.<br />
<br />
Addition/Removal of node or edge trigger the merge of the semantic difference if it is associated to one, and the merge operation of the graphical difference otherwise. This merge operation consist of re-create the element if it has been deleted from the diagram, or to restor the hidden status of this view (View.isVisible())<br />
<br />
== Use of Difference Extensions and Hiding mechanism ==<br />
<br />
To detect the differences related to functional cases of diagram comparison, new kinds of differences (extensions) are created to complete the DiffModel.<br />
<br />
These extensions lean on the generic differences to be build and they are able to hide them.<br />
<br />
Here is the list of the generic differences which are managed and, for each of them, what are the extensions which are created and the differences which are hidden:<br />
<br />
* A '''ModelElementChangeLeftTarget''' difference, related to a ''View'', will involve the creation of a '''''DiagramModelElementChangeLeftTarget''''' difference extension. This extension will hide the '''ModelElementChangeLeftTarget''' input difference which was used to build it.<br />
<br />
* In the same way, a '''ModelElementChangeRightTarget''' difference, related to a ''View'', will involve the creation of a '''''DiagramModelElementChangeRightTarget''''' difference extension. This extension will hide the '''ModelElementChangeRightTarget''' input difference which was used to build it.<br />
<br />
* An '''UpdateAttribute''' on the ''EAttribute'' &quot;''View_visible''&quot;, where the right view is not visible and it is not a remotely change OR the right view is visible but it is a remotely change, will involve the creation of a '''''DiagramShowElement''''' difference extension. This one will hide the '''UpdateAttribute''' input difference which was used to build it.<br />
<br />
* In the same way, an '''UpdateAttribute''' on the ''EAttribute'' &quot;''View_visible''&quot;, where the left view is not visible and it is not a remotely change or the left view is visible but it is a remotely change, will involve the creation of a '''''DiagramHideElement''''' difference extension. This one will hide the '''UpdateAttribute''' input difference which was used to build it.<br />
<br />
* An '''UpdateAttribute''', where the container of its ''EAttribute'' is a ''Location'' and the related compared elements are not edges and the move is over the threshold specified in the page preferences, will involve the creation of a '''''DiagramMoveNode''''' difference extension. This extension will hide the '''UpdateAttribute''' input difference which was used to build it.<br />
<br />
* On each matched object, it is checked (in the same time as the attributes checking) if the GMF labels are different to create a '''''DiagramLabelChange''''' difference extension. This one hides no existing difference. To check the labels, the ''ITextAwareEditPart'' edit parts are retrieved and their GMF parser to get the print string and to compare them.<br />
<br />
* An '''UpdateAttribute''', where the container of its ''EAttribute'' is a ''RelativeBendpoints'' OR the ''EAttribute'' is ''IdentityAnchor_Id'', will involve the creation of a '''''DiagramEdgeChange''''' difference extension. Besides, an '''ModelElementChange''', where the related element is an ''IdentityAnchor'', will involve the creation of a '''''DiagramEdgeChange''''' difference extension too. For a same ''Edge'', it is possible to have several combined generic differences (several '''UpdateAttribute''' and '''ModelElementChange'''). To create only one extension for these ones, it is checked if there already exists a '''''DiagramEdgeChange''''' for this ''Edge'' in the building ''DiffModel''. This extension will hide the '''UpdateAttribute''' and/or '''ModelElementChange''' input differences which were used to build it.<br />
<br />
=== Mergers ===<br />
<br />
* For every difference extensions which lean on diagram changes only (no semantic changes), a single merger is used to merge these ones: ''DiagramDiffExtensionMerger''.<br />
It is the case of ''DiagramShowElement'', ''DiagramHideElement'', ''DiagramMoveNode'' and ''DiagramEdgeChange'' difference extensions. The merger retrieves all the hidden differences of the extension and call the related merger for each of them.<br />
<br />
* For ''DiagramLabelChange'', a ''DiagramlabelChangeMerger'' is used to set the new label from the GMF Command. This command allows to deploy changes on the semantic model.<br />
<br />
* For ''DiagramModelElementChangeLeftTarget'' and ''DiagramModelElementChangeRightTarget'', a respectively ''DiagramModelElementChangeLeftTargetMerger'' and ''DiagramModelElementChangeRightTargetMerger'' are used. They have the same behavior as ''DiagramDiffExtensionMerger'' unless for the merge of the delete of a ''View''. Indeed, for the add of a View, the generic merger is able to merge the ''View'' and the semantic object together. But, for the delete, it does not manage to merge the semantic difference. These 2 mergers retrieve the semantic difference to merge it before the merge of the delete of the View.<br />
<br />
== GMF editor integration within Comparison editor ==<br />
<br />
The integration of GMF editor within the comparison editor has to be done through specific contentMergeViewer (org.eclipse.compare.contentMergeViewers extension point) and maybe a specific structureMergerViewer (org.eclipse.compare.structureMergeViewers extension point) to provide the separation between graphical differences and semantic differences.<br />
<br />
The content merge viewer has to instantiate DiagramGraphicalViewer inside its '''createControls()''' method:<br />
<br />
viewer = new DiagramGraphicalViewer();<br />
viewer.createControl(composite);<br />
viewer.getControl().setBackground(ColorConstants.listBackground);<br />
<br />
The resize of the left/right/ancestor panes has to be handled gracefully like this:<br />
<br />
viewer_left.getControl().setBounds(x, y, leftWidth, height);<br />
viewer_right.getControl().setBounds(x + leftWidth + centerWidth, y, rightWidth, height);<br />
<br />
=== Initialization ===<br />
<br />
The left/right/ancestor viewers has to be initialized with a proper editing domain. This creation takes the resourceSet as input:<br />
<br />
DiagramEditingDomainFactory.getInstance().createEditingDomain(resourceset);<br />
<br />
Then, the viewers has to be configured like this: <br />
<br />
viewer.setEditDomain(new DefaultEditDomain(null)); // GEF editDomain<br />
viewer.setEditPartFactory(EditPartService.getInstance());<br />
viewer.setRootEditPart(new DiagramRootEditPart(diag.getMeasurementUnit()));<br />
viewer.setContents(diag); // the diagram from the notation model<br />
<br />
It is also possible to make the viewer uneditable by browsing all children of the rootEditPart of each viewer, but then, we will not be able to ask for the '''editability''' of views. It should be better to add a top layer that forbid the editing.<br />
<br />
== Markers for GMF diagrams ==<br />
<br />
Difference marker on notation model are provided by using the '''org.eclipse.gmf.runtime.diagram.ui.decoratorProviders''' extension point.<br />
<br />
The provided IDecoratorProvider will create a decorator based on the proposed IDecoratorTarget. This IDecoratorTarget can be adapted to a Notation View like this :<br />
<br />
View view = (View) decoratorTarget.getAdapter(View.class);<br />
<br />
The decorator should be created if, and only if, there is a graphical difference associated with the given View. The graphical difference model will be retrieved from the owning EditPart.<br />
<br />
Provided decorators has to implement IDecorator interface. <br />
<br />
The issue with specific decorator is to define the locator. Each Figure has its own bounds and we will start from the assumption that:<br />
<br />
* Marker of decorated figure will be rectangle following their bounds (smallest rectangle completely enclosing the IFigure)<br />
* Marker of decorated edges will be handled for polylines only and bounds of the decoration will be the bounds of the decorated<br />
* Marker of move will be an icon (picture not yet defined) located:<br />
** in the middle of the edge if the edge has moved<br />
** in the top right of the bounds of the figure if it is a node.<br />
<br />
See samples of first annotation prototypes (on Ecore diagram):<br />
<br />
Class added:<br />
[[Image:markedAdded.png]]<br />
<br />
Class removed:<br />
[[Image:markedRemoved.png]]<br />
<br />
Label of class changed:<br />
[[Image:markedLabel.png]]<br />
<br />
Edge marked (added)<br />
[[Image:markedEdge.png]]<br />
<br />
Edge marked (moved)<br />
[[Image:markedMovedEdge.png]]<br />
<br />
=== Implementation ===<br />
<br />
Here are some screenshots of the current development under the ericsson_integration branch of the following repository https://github.com/mbarbero/emfcompare <br />
<br />
{| cellspacing=&quot;1&quot; cellpadding=&quot;1&quot; border=&quot;1&quot;<br />
|-<br />
! align=&quot;center&quot; colspan=&quot;3&quot; | EcoreTools Tests Cases<br />
|-<br />
! align=&quot;center&quot;| Description<br />
! align=&quot;center&quot;| State<br />
! align=&quot;center&quot;| Screenshot<br />
|-<br />
| Added nodes<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC1.png|thumb]]<br />
|-<br />
| Deleted nodes<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC2.png|thumb]]<br />
|-<br />
| Mix of added and deleted nodes<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC3.png|thumb]]<br />
|-<br />
| Added node inside a node<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC04.png|thumb]]<br />
|-<br />
| Removed node inside a node<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC05.png|thumb]]<br />
|-<br />
| Moved node<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC6.png|thumb]]<br />
| [[Image:preference.png|thumb|A move threshold can be set in the preference page to detect this change]]<br />
|-<br />
| Modified bounds of a node<br />
! style=&quot;color:red&quot; | ko<br />
| [[Image:TC7.png|thumb|not implemented]]<br />
|-<br />
| Hidden node<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC09.png|thumb]]<br />
|-<br />
| Revealed node<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC08.png|thumb]]<br />
|-<br />
| Modified label<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC10.png|thumb]]<br />
|-<br />
| Added label<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC11.png|thumb]]<br />
|-<br />
| Removed label<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC12.png|thumb]]<br />
|-<br />
| Mix of added and removed label<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC13.png|thumb]]<br />
|-<br />
| Hidden label<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC15.png|thumb]]<br />
|-<br />
| Revealed label<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC14.png|thumb]]<br />
|-<br />
| Modified label<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC16.png|thumb]]<br />
|-<br />
| Modified label<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC17.png|thumb]]<br />
|-<br />
| Added edge<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC18.png|thumb|no highlight on labels]]<br />
|-<br />
| Removed edge<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC19.png|thumb|no highlight on labels]]<br />
|-<br />
| Mix of added and removed edges<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC20.png|thumb|no highlight on labels]]<br />
|-<br />
| Moved edge<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC21.png|thumb]]<br />
|-<br />
| Modified edge label<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC23.png|thumb]]<br />
|-<br />
| Modified edge label<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC24.png|thumb]]<br />
|-<br />
| Revealed edge<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC25.png|thumb]]<br />
|-<br />
| Hidden edge<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC26.png|thumb]]<br />
|-<br />
| Revealed edge label<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC27.png|thumb]]<br />
|-<br />
| Hidden edge label<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC28.png|thumb]]<br />
|-<br />
| Removed node with edge<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC29.png|thumb| no highlight on labels]]<br />
|-<br />
| Removed node with edge ( delete from diagram )<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC30.png|thumb| no highlight on labels]]<br />
|-<br />
| Removed edge ( delete from diagram )<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC31.png|thumb| no highlight on labels]]<br />
|-<br />
| 3 WAY ; added node<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC32.png|thumb]]<br />
|-<br />
| 3 WAY ; removed node<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC33.png|thumb]]<br />
|-<br />
| 3 WAY ; moved node (remote)<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC34.png|thumb | both nodes are marked]]<br />
|-<br />
| 3 WAY ; moved node (local)<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC35.png|thumb | both nodes are marked]]<br />
|-<br />
| 3 WAY ; modified label<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC36.png|thumb]]<br />
|-<br />
| 3 WAY ; remotely hidden node<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC37.png|thumb]]<br />
|-<br />
| 3 WAY ; locally hidden node<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC38.png|thumb]]<br />
|-<br />
| 3 WAY ; remotely revealed node<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC39.png|thumb]]<br />
|-<br />
| 3 WAY ; locally revealed node<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC40.png|thumb]]<br />
|-<br />
| Multiple diagram ; Added node in sub-diagram<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC50.png|thumb]]<br />
|-<br />
| Multiple diagram ; Removed node in sub-diagram<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC51.png|thumb]]<br />
|-<br />
| Multiple diagram ; Mix of Added and Removed node in sub-diagram<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC52.png|thumb]] [[Image:TC52b.png|thumb]]<br />
|-<br />
| 3 WAY and Multiple diagram ; Modified labels in sub-diagram<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC53a.png|thumb]] [[Image:TC53b.png|thumb]]<br />
|-<br />
| Multiple diagram ; Mix of Added and Removed node and edges in sub-diagram<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC54a.png|thumb]] [[Image:TC54b.png|thumb]]<br />
|-<br />
! align=&quot;center&quot; colspan=&quot;3&quot; | Papyrus Tests Cases<br />
|-<br />
| Package diagram<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC60.png|thumb]]<br />
|-<br />
| Class diagram<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC61.png|thumb]]<br />
|-<br />
| Composite diagram<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC62.png|thumb]]<br />
|-<br />
| UseCase diagram<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC63.png|thumb]]<br />
|-<br />
| Sequence diagram<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC64.png|thumb]]<br />
|-<br />
| Activity diagram<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC65.png|thumb]]<br />
|-<br />
| StateMachine diagram<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC66.png|thumb]]<br />
|-<br />
| Communication diagram<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC67.png|thumb]]<br />
|-<br />
| Component diagram<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC68.png|thumb]]<br />
|-<br />
| Deployment diagram<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC69.png|thumb]]<br />
|-<br />
| Profile diagram<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC70.png|thumb]]<br />
|-<br />
| Multi diagrams<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC71a.png|thumb]] [[Image:TC71b.png|thumb]] [[Image:TC71c.png|thumb]]<br />
|}</div>Stephane.bouchet.obeo.frhttp://wiki.eclipse.org/index.php?title=File:TC71c.png&diff=271984File:TC71c.png2011-10-11T14:41:24Z<p>Stephane.bouchet.obeo.fr: </p>
<hr />
<div></div>Stephane.bouchet.obeo.frhttp://wiki.eclipse.org/index.php?title=File:TC71b.png&diff=271983File:TC71b.png2011-10-11T14:41:14Z<p>Stephane.bouchet.obeo.fr: </p>
<hr />
<div></div>Stephane.bouchet.obeo.frhttp://wiki.eclipse.org/index.php?title=File:TC71a.png&diff=271982File:TC71a.png2011-10-11T14:41:01Z<p>Stephane.bouchet.obeo.fr: </p>
<hr />
<div></div>Stephane.bouchet.obeo.frhttp://wiki.eclipse.org/index.php?title=File:TC70.png&diff=271981File:TC70.png2011-10-11T14:40:49Z<p>Stephane.bouchet.obeo.fr: </p>
<hr />
<div></div>Stephane.bouchet.obeo.frhttp://wiki.eclipse.org/index.php?title=File:TC69.png&diff=271980File:TC69.png2011-10-11T14:40:39Z<p>Stephane.bouchet.obeo.fr: </p>
<hr />
<div></div>Stephane.bouchet.obeo.frhttp://wiki.eclipse.org/index.php?title=File:TC68.png&diff=271979File:TC68.png2011-10-11T14:40:29Z<p>Stephane.bouchet.obeo.fr: </p>
<hr />
<div></div>Stephane.bouchet.obeo.frhttp://wiki.eclipse.org/index.php?title=File:TC67.png&diff=271978File:TC67.png2011-10-11T14:40:18Z<p>Stephane.bouchet.obeo.fr: </p>
<hr />
<div></div>Stephane.bouchet.obeo.frhttp://wiki.eclipse.org/index.php?title=File:TC66.png&diff=271977File:TC66.png2011-10-11T14:40:08Z<p>Stephane.bouchet.obeo.fr: </p>
<hr />
<div></div>Stephane.bouchet.obeo.frhttp://wiki.eclipse.org/index.php?title=File:TC65.png&diff=271976File:TC65.png2011-10-11T14:39:57Z<p>Stephane.bouchet.obeo.fr: </p>
<hr />
<div></div>Stephane.bouchet.obeo.frhttp://wiki.eclipse.org/index.php?title=File:TC64.png&diff=271975File:TC64.png2011-10-11T14:39:46Z<p>Stephane.bouchet.obeo.fr: </p>
<hr />
<div></div>Stephane.bouchet.obeo.frhttp://wiki.eclipse.org/index.php?title=File:TC63.png&diff=271974File:TC63.png2011-10-11T14:39:36Z<p>Stephane.bouchet.obeo.fr: </p>
<hr />
<div></div>Stephane.bouchet.obeo.frhttp://wiki.eclipse.org/index.php?title=File:TC62.png&diff=271973File:TC62.png2011-10-11T14:39:22Z<p>Stephane.bouchet.obeo.fr: </p>
<hr />
<div></div>Stephane.bouchet.obeo.frhttp://wiki.eclipse.org/index.php?title=File:TC61.png&diff=271972File:TC61.png2011-10-11T14:39:06Z<p>Stephane.bouchet.obeo.fr: </p>
<hr />
<div></div>Stephane.bouchet.obeo.frhttp://wiki.eclipse.org/index.php?title=File:TC60.png&diff=271971File:TC60.png2011-10-11T14:38:54Z<p>Stephane.bouchet.obeo.fr: </p>
<hr />
<div></div>Stephane.bouchet.obeo.frhttp://wiki.eclipse.org/index.php?title=EMF_Compare/GMF_Notation_model_Comparison&diff=271963EMF Compare/GMF Notation model Comparison2011-10-11T13:59:24Z<p>Stephane.bouchet.obeo.fr: /* Implementation */</p>
<hr />
<div>The GMF diagram comparison task can be splitted into four parts. First, we must be able to compare GMF Notation models, then we have to know how we handle the link with the comparison of the semantic model (i.e. the elements represented by the diagram). Third, we have to know how to integrate existing GMF editor within the EMF Compare editor. Finally, we have to know how to create generic markers on the diagram to give a feedback of the computed differences to the user.<br />
<br />
== Notation model comparison ==<br />
<br />
Notation model comparison need its own MatchEngine and DiffEngine. The whole notation metamodel will not be taken into account. The difference computation will only occur on a subpart as depicted below:<br />
<br />
[[Image:gmf_notation_compare.png]]<br />
<br />
The nodes and edges will be matched by their XMI IDs. Containment between nodes will be handled in a generic way (i.e. by the super class GenericMatchEngine). <br />
<br />
Only following differences will be computed:<br />
<br />
* Addition / Removal of a node<br />
* Addition / Removal of an edge<br />
* Change of a Label on an edge or on a node<br />
* Move of a node within the diagram (with a configurable translation threshold for the move its location x/y).<br />
* Move of an edge within the diagram (total number of bendpoints, change of bendpoints - sourceX, sourceY, targetX, targetY - and positions of the anchors).<br />
<br />
== Link with the semantic comparison ==<br />
<br />
For many cases, we need the semantic comparison to be done before the graphical one. The work on logical model integration should give us this facility by computing the differences of a whole resource set instead of just the current resource containing the notation model.<br />
<br />
The link with the semantic comparison had to be provided for the labels. For each element , we have to get the text of the label and compare them. They are not stored directly into the notation model.<br />
<br />
Move operations of Edge and Node never correspond to semantic change.<br />
<br />
For addition and removal of nodes and edges, graphical differences may or may not corresponds to a semantic change. For instance, a graphical element may be removed because it has been hidden or deleted from the diagram. It does not correspond to a change in the semantic model. This graphical change does not have to be linked to a semantic change. In the other case, the addition or the removal of a node or an edge must match an addition or a deletion in the semantic model.<br />
<br />
=== Merge ===<br />
<br />
As a we don't know from the notation model how labels are build and from which feature(s) of the semantic model, the merge operation of labels modification must be applied on the notation model to trigger the appropriate underlying commands on the semantic model. This merger operation can be triggered only if the label is editable (=&gt; ask to the editpart of the view '''isEditModeEnabled()''')<br />
<br />
The merge of a move a node or an edge never triggers a merge on the semantic model, only on the graphical notation. The merge is a simple copy of values of bendpoints/layout constraints.<br />
<br />
Addition/Removal of node or edge trigger the merge of the semantic difference if it is associated to one, and the merge operation of the graphical difference otherwise. This merge operation consist of re-create the element if it has been deleted from the diagram, or to restor the hidden status of this view (View.isVisible())<br />
<br />
== Use of Difference Extensions and Hiding mechanism ==<br />
<br />
To detect the differences related to functional cases of diagram comparison, new kinds of differences (extensions) are created to complete the DiffModel.<br />
<br />
These extensions lean on the generic differences to be build and they are able to hide them.<br />
<br />
Here is the list of the generic differences which are managed and, for each of them, what are the extensions which are created and the differences which are hidden:<br />
<br />
* A '''ModelElementChangeLeftTarget''' difference, related to a ''View'', will involve the creation of a '''''DiagramModelElementChangeLeftTarget''''' difference extension. This extension will hide the '''ModelElementChangeLeftTarget''' input difference which was used to build it.<br />
<br />
* In the same way, a '''ModelElementChangeRightTarget''' difference, related to a ''View'', will involve the creation of a '''''DiagramModelElementChangeRightTarget''''' difference extension. This extension will hide the '''ModelElementChangeRightTarget''' input difference which was used to build it.<br />
<br />
* An '''UpdateAttribute''' on the ''EAttribute'' &quot;''View_visible''&quot;, where the right view is not visible and it is not a remotely change OR the right view is visible but it is a remotely change, will involve the creation of a '''''DiagramShowElement''''' difference extension. This one will hide the '''UpdateAttribute''' input difference which was used to build it.<br />
<br />
* In the same way, an '''UpdateAttribute''' on the ''EAttribute'' &quot;''View_visible''&quot;, where the left view is not visible and it is not a remotely change or the left view is visible but it is a remotely change, will involve the creation of a '''''DiagramHideElement''''' difference extension. This one will hide the '''UpdateAttribute''' input difference which was used to build it.<br />
<br />
* An '''UpdateAttribute''', where the container of its ''EAttribute'' is a ''Location'' and the related compared elements are not edges and the move is over the threshold specified in the page preferences, will involve the creation of a '''''DiagramMoveNode''''' difference extension. This extension will hide the '''UpdateAttribute''' input difference which was used to build it.<br />
<br />
* On each matched object, it is checked (in the same time as the attributes checking) if the GMF labels are different to create a '''''DiagramLabelChange''''' difference extension. This one hides no existing difference. To check the labels, the ''ITextAwareEditPart'' edit parts are retrieved and their GMF parser to get the print string and to compare them.<br />
<br />
* An '''UpdateAttribute''', where the container of its ''EAttribute'' is a ''RelativeBendpoints'' OR the ''EAttribute'' is ''IdentityAnchor_Id'', will involve the creation of a '''''DiagramEdgeChange''''' difference extension. Besides, an '''ModelElementChange''', where the related element is an ''IdentityAnchor'', will involve the creation of a '''''DiagramEdgeChange''''' difference extension too. For a same ''Edge'', it is possible to have several combined generic differences (several '''UpdateAttribute''' and '''ModelElementChange'''). To create only one extension for these ones, it is checked if there already exists a '''''DiagramEdgeChange''''' for this ''Edge'' in the building ''DiffModel''. This extension will hide the '''UpdateAttribute''' and/or '''ModelElementChange''' input differences which were used to build it.<br />
<br />
=== Mergers ===<br />
<br />
* For every difference extensions which lean on diagram changes only (no semantic changes), a single merger is used to merge these ones: ''DiagramDiffExtensionMerger''.<br />
It is the case of ''DiagramShowElement'', ''DiagramHideElement'', ''DiagramMoveNode'' and ''DiagramEdgeChange'' difference extensions. The merger retrieves all the hidden differences of the extension and call the related merger for each of them.<br />
<br />
* For ''DiagramLabelChange'', a ''DiagramlabelChangeMerger'' is used to set the new label from the GMF Command. This command allows to deploy changes on the semantic model.<br />
<br />
* For ''DiagramModelElementChangeLeftTarget'' and ''DiagramModelElementChangeRightTarget'', a respectively ''DiagramModelElementChangeLeftTargetMerger'' and ''DiagramModelElementChangeRightTargetMerger'' are used. They have the same behavior as ''DiagramDiffExtensionMerger'' unless for the merge of the delete of a ''View''. Indeed, for the add of a View, the generic merger is able to merge the ''View'' and the semantic object together. But, for the delete, it does not manage to merge the semantic difference. These 2 mergers retrieve the semantic difference to merge it before the merge of the delete of the View.<br />
<br />
== GMF editor integration within Comparison editor ==<br />
<br />
The integration of GMF editor within the comparison editor has to be done through specific contentMergeViewer (org.eclipse.compare.contentMergeViewers extension point) and maybe a specific structureMergerViewer (org.eclipse.compare.structureMergeViewers extension point) to provide the separation between graphical differences and semantic differences.<br />
<br />
The content merge viewer has to instantiate DiagramGraphicalViewer inside its '''createControls()''' method:<br />
<br />
viewer = new DiagramGraphicalViewer();<br />
viewer.createControl(composite);<br />
viewer.getControl().setBackground(ColorConstants.listBackground);<br />
<br />
The resize of the left/right/ancestor panes has to be handled gracefully like this:<br />
<br />
viewer_left.getControl().setBounds(x, y, leftWidth, height);<br />
viewer_right.getControl().setBounds(x + leftWidth + centerWidth, y, rightWidth, height);<br />
<br />
=== Initialization ===<br />
<br />
The left/right/ancestor viewers has to be initialized with a proper editing domain. This creation takes the resourceSet as input:<br />
<br />
DiagramEditingDomainFactory.getInstance().createEditingDomain(resourceset);<br />
<br />
Then, the viewers has to be configured like this: <br />
<br />
viewer.setEditDomain(new DefaultEditDomain(null)); // GEF editDomain<br />
viewer.setEditPartFactory(EditPartService.getInstance());<br />
viewer.setRootEditPart(new DiagramRootEditPart(diag.getMeasurementUnit()));<br />
viewer.setContents(diag); // the diagram from the notation model<br />
<br />
It is also possible to make the viewer uneditable by browsing all children of the rootEditPart of each viewer, but then, we will not be able to ask for the '''editability''' of views. It should be better to add a top layer that forbid the editing.<br />
<br />
== Markers for GMF diagrams ==<br />
<br />
Difference marker on notation model are provided by using the '''org.eclipse.gmf.runtime.diagram.ui.decoratorProviders''' extension point.<br />
<br />
The provided IDecoratorProvider will create a decorator based on the proposed IDecoratorTarget. This IDecoratorTarget can be adapted to a Notation View like this :<br />
<br />
View view = (View) decoratorTarget.getAdapter(View.class);<br />
<br />
The decorator should be created if, and only if, there is a graphical difference associated with the given View. The graphical difference model will be retrieved from the owning EditPart.<br />
<br />
Provided decorators has to implement IDecorator interface. <br />
<br />
The issue with specific decorator is to define the locator. Each Figure has its own bounds and we will start from the assumption that:<br />
<br />
* Marker of decorated figure will be rectangle following their bounds (smallest rectangle completely enclosing the IFigure)<br />
* Marker of decorated edges will be handled for polylines only and bounds of the decoration will be the bounds of the decorated<br />
* Marker of move will be an icon (picture not yet defined) located:<br />
** in the middle of the edge if the edge has moved<br />
** in the top right of the bounds of the figure if it is a node.<br />
<br />
See samples of first annotation prototypes (on Ecore diagram):<br />
<br />
Class added:<br />
[[Image:markedAdded.png]]<br />
<br />
Class removed:<br />
[[Image:markedRemoved.png]]<br />
<br />
Label of class changed:<br />
[[Image:markedLabel.png]]<br />
<br />
Edge marked (added)<br />
[[Image:markedEdge.png]]<br />
<br />
Edge marked (moved)<br />
[[Image:markedMovedEdge.png]]<br />
<br />
=== Implementation ===<br />
<br />
Here are some screenshots of the current development under the ericsson_integration branch of the following repository https://github.com/mbarbero/emfcompare <br />
<br />
{| cellspacing=&quot;1&quot; cellpadding=&quot;1&quot; border=&quot;1&quot;<br />
|-<br />
! align=&quot;center&quot;| Description<br />
! align=&quot;center&quot;| State<br />
! align=&quot;center&quot;| Screenshot<br />
|-<br />
| Added nodes<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC1.png|thumb]]<br />
|-<br />
| Deleted nodes<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC2.png|thumb]]<br />
|-<br />
| Mix of added and deleted nodes<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC3.png|thumb]]<br />
|-<br />
| Added node inside a node<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC04.png|thumb]]<br />
|-<br />
| Removed node inside a node<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC05.png|thumb]]<br />
|-<br />
| Moved node<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC6.png|thumb]]<br />
| [[Image:preference.png|thumb|A move threshold can be set in the preference page to detect this change]]<br />
|-<br />
| Modified bounds of a node<br />
! style=&quot;color:red&quot; | ko<br />
| [[Image:TC7.png|thumb|not implemented]]<br />
|-<br />
| Hidden node<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC09.png|thumb]]<br />
|-<br />
| Revealed node<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC08.png|thumb]]<br />
|-<br />
| Modified label<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC10.png|thumb]]<br />
|-<br />
| Added label<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC11.png|thumb]]<br />
|-<br />
| Removed label<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC12.png|thumb]]<br />
|-<br />
| Mix of added and removed label<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC13.png|thumb]]<br />
|-<br />
| Hidden label<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC15.png|thumb]]<br />
|-<br />
| Revealed label<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC14.png|thumb]]<br />
|-<br />
| Modified label<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC16.png|thumb]]<br />
|-<br />
| Modified label<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC17.png|thumb]]<br />
|-<br />
| Added edge<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC18.png|thumb|no highlight on labels]]<br />
|-<br />
| Removed edge<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC19.png|thumb|no highlight on labels]]<br />
|-<br />
| Mix of added and removed edges<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC20.png|thumb|no highlight on labels]]<br />
|-<br />
| Moved edge<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC21.png|thumb]]<br />
|-<br />
| Modified edge label<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC23.png|thumb]]<br />
|-<br />
| Modified edge label<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC24.png|thumb]]<br />
|-<br />
| Revealed edge<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC25.png|thumb]]<br />
|-<br />
| Hidden edge<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC26.png|thumb]]<br />
|-<br />
| Revealed edge label<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC27.png|thumb]]<br />
|-<br />
| Hidden edge label<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC28.png|thumb]]<br />
|-<br />
| Removed node with edge<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC29.png|thumb| no highlight on labels]]<br />
|-<br />
| Removed node with edge ( delete from diagram )<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC30.png|thumb| no highlight on labels]]<br />
|-<br />
| Removed edge ( delete from diagram )<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC31.png|thumb| no highlight on labels]]<br />
|-<br />
| 3 WAY ; added node<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC32.png|thumb]]<br />
|-<br />
| 3 WAY ; removed node<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC33.png|thumb]]<br />
|-<br />
| 3 WAY ; moved node (remote)<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC34.png|thumb | both nodes are marked]]<br />
|-<br />
| 3 WAY ; moved node (local)<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC35.png|thumb | both nodes are marked]]<br />
|-<br />
| 3 WAY ; modified label<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC36.png|thumb]]<br />
|-<br />
| 3 WAY ; remotely hidden node<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC37.png|thumb]]<br />
|-<br />
| 3 WAY ; locally hidden node<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC38.png|thumb]]<br />
|-<br />
| 3 WAY ; remotely revealed node<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC39.png|thumb]]<br />
|-<br />
| 3 WAY ; locally revealed node<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC40.png|thumb]]<br />
|-<br />
| Multiple diagram ; Added node in sub-diagram<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC50.png|thumb]]<br />
|-<br />
| Multiple diagram ; Removed node in sub-diagram<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC51.png|thumb]]<br />
|-<br />
| Multiple diagram ; Mix of Added and Removed node in sub-diagram<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC52.png|thumb]] [[Image:TC52b.png|thumb]]<br />
|-<br />
| 3 WAY and Multiple diagram ; Modified labels in sub-diagram<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC53a.png|thumb]] [[Image:TC53b.png|thumb]]<br />
|-<br />
| Multiple diagram ; Mix of Added and Removed node and edges in sub-diagram<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC54a.png|thumb]] [[Image:TC54b.png|thumb]]<br />
|}</div>Stephane.bouchet.obeo.frhttp://wiki.eclipse.org/index.php?title=File:TC54b.png&diff=271962File:TC54b.png2011-10-11T13:59:20Z<p>Stephane.bouchet.obeo.fr: </p>
<hr />
<div></div>Stephane.bouchet.obeo.frhttp://wiki.eclipse.org/index.php?title=File:TC54a.png&diff=271961File:TC54a.png2011-10-11T13:59:10Z<p>Stephane.bouchet.obeo.fr: </p>
<hr />
<div></div>Stephane.bouchet.obeo.frhttp://wiki.eclipse.org/index.php?title=EMF_Compare/GMF_Notation_model_Comparison&diff=271959EMF Compare/GMF Notation model Comparison2011-10-11T13:50:48Z<p>Stephane.bouchet.obeo.fr: /* Implementation */</p>
<hr />
<div>The GMF diagram comparison task can be splitted into four parts. First, we must be able to compare GMF Notation models, then we have to know how we handle the link with the comparison of the semantic model (i.e. the elements represented by the diagram). Third, we have to know how to integrate existing GMF editor within the EMF Compare editor. Finally, we have to know how to create generic markers on the diagram to give a feedback of the computed differences to the user.<br />
<br />
== Notation model comparison ==<br />
<br />
Notation model comparison need its own MatchEngine and DiffEngine. The whole notation metamodel will not be taken into account. The difference computation will only occur on a subpart as depicted below:<br />
<br />
[[Image:gmf_notation_compare.png]]<br />
<br />
The nodes and edges will be matched by their XMI IDs. Containment between nodes will be handled in a generic way (i.e. by the super class GenericMatchEngine). <br />
<br />
Only following differences will be computed:<br />
<br />
* Addition / Removal of a node<br />
* Addition / Removal of an edge<br />
* Change of a Label on an edge or on a node<br />
* Move of a node within the diagram (with a configurable translation threshold for the move its location x/y).<br />
* Move of an edge within the diagram (total number of bendpoints, change of bendpoints - sourceX, sourceY, targetX, targetY - and positions of the anchors).<br />
<br />
== Link with the semantic comparison ==<br />
<br />
For many cases, we need the semantic comparison to be done before the graphical one. The work on logical model integration should give us this facility by computing the differences of a whole resource set instead of just the current resource containing the notation model.<br />
<br />
The link with the semantic comparison had to be provided for the labels. For each element , we have to get the text of the label and compare them. They are not stored directly into the notation model.<br />
<br />
Move operations of Edge and Node never correspond to semantic change.<br />
<br />
For addition and removal of nodes and edges, graphical differences may or may not corresponds to a semantic change. For instance, a graphical element may be removed because it has been hidden or deleted from the diagram. It does not correspond to a change in the semantic model. This graphical change does not have to be linked to a semantic change. In the other case, the addition or the removal of a node or an edge must match an addition or a deletion in the semantic model.<br />
<br />
=== Merge ===<br />
<br />
As a we don't know from the notation model how labels are build and from which feature(s) of the semantic model, the merge operation of labels modification must be applied on the notation model to trigger the appropriate underlying commands on the semantic model. This merger operation can be triggered only if the label is editable (=&gt; ask to the editpart of the view '''isEditModeEnabled()''')<br />
<br />
The merge of a move a node or an edge never triggers a merge on the semantic model, only on the graphical notation. The merge is a simple copy of values of bendpoints/layout constraints.<br />
<br />
Addition/Removal of node or edge trigger the merge of the semantic difference if it is associated to one, and the merge operation of the graphical difference otherwise. This merge operation consist of re-create the element if it has been deleted from the diagram, or to restor the hidden status of this view (View.isVisible())<br />
<br />
== Use of Difference Extensions and Hiding mechanism ==<br />
<br />
To detect the differences related to functional cases of diagram comparison, new kinds of differences (extensions) are created to complete the DiffModel.<br />
<br />
These extensions lean on the generic differences to be build and they are able to hide them.<br />
<br />
Here is the list of the generic differences which are managed and, for each of them, what are the extensions which are created and the differences which are hidden:<br />
<br />
* A '''ModelElementChangeLeftTarget''' difference, related to a ''View'', will involve the creation of a '''''DiagramModelElementChangeLeftTarget''''' difference extension. This extension will hide the '''ModelElementChangeLeftTarget''' input difference which was used to build it.<br />
<br />
* In the same way, a '''ModelElementChangeRightTarget''' difference, related to a ''View'', will involve the creation of a '''''DiagramModelElementChangeRightTarget''''' difference extension. This extension will hide the '''ModelElementChangeRightTarget''' input difference which was used to build it.<br />
<br />
* An '''UpdateAttribute''' on the ''EAttribute'' &quot;''View_visible''&quot;, where the right view is not visible and it is not a remotely change OR the right view is visible but it is a remotely change, will involve the creation of a '''''DiagramShowElement''''' difference extension. This one will hide the '''UpdateAttribute''' input difference which was used to build it.<br />
<br />
* In the same way, an '''UpdateAttribute''' on the ''EAttribute'' &quot;''View_visible''&quot;, where the left view is not visible and it is not a remotely change or the left view is visible but it is a remotely change, will involve the creation of a '''''DiagramHideElement''''' difference extension. This one will hide the '''UpdateAttribute''' input difference which was used to build it.<br />
<br />
* An '''UpdateAttribute''', where the container of its ''EAttribute'' is a ''Location'' and the related compared elements are not edges and the move is over the threshold specified in the page preferences, will involve the creation of a '''''DiagramMoveNode''''' difference extension. This extension will hide the '''UpdateAttribute''' input difference which was used to build it.<br />
<br />
* On each matched object, it is checked (in the same time as the attributes checking) if the GMF labels are different to create a '''''DiagramLabelChange''''' difference extension. This one hides no existing difference. To check the labels, the ''ITextAwareEditPart'' edit parts are retrieved and their GMF parser to get the print string and to compare them.<br />
<br />
* An '''UpdateAttribute''', where the container of its ''EAttribute'' is a ''RelativeBendpoints'' OR the ''EAttribute'' is ''IdentityAnchor_Id'', will involve the creation of a '''''DiagramEdgeChange''''' difference extension. Besides, an '''ModelElementChange''', where the related element is an ''IdentityAnchor'', will involve the creation of a '''''DiagramEdgeChange''''' difference extension too. For a same ''Edge'', it is possible to have several combined generic differences (several '''UpdateAttribute''' and '''ModelElementChange'''). To create only one extension for these ones, it is checked if there already exists a '''''DiagramEdgeChange''''' for this ''Edge'' in the building ''DiffModel''. This extension will hide the '''UpdateAttribute''' and/or '''ModelElementChange''' input differences which were used to build it.<br />
<br />
=== Mergers ===<br />
<br />
* For every difference extensions which lean on diagram changes only (no semantic changes), a single merger is used to merge these ones: ''DiagramDiffExtensionMerger''.<br />
It is the case of ''DiagramShowElement'', ''DiagramHideElement'', ''DiagramMoveNode'' and ''DiagramEdgeChange'' difference extensions. The merger retrieves all the hidden differences of the extension and call the related merger for each of them.<br />
<br />
* For ''DiagramLabelChange'', a ''DiagramlabelChangeMerger'' is used to set the new label from the GMF Command. This command allows to deploy changes on the semantic model.<br />
<br />
* For ''DiagramModelElementChangeLeftTarget'' and ''DiagramModelElementChangeRightTarget'', a respectively ''DiagramModelElementChangeLeftTargetMerger'' and ''DiagramModelElementChangeRightTargetMerger'' are used. They have the same behavior as ''DiagramDiffExtensionMerger'' unless for the merge of the delete of a ''View''. Indeed, for the add of a View, the generic merger is able to merge the ''View'' and the semantic object together. But, for the delete, it does not manage to merge the semantic difference. These 2 mergers retrieve the semantic difference to merge it before the merge of the delete of the View.<br />
<br />
== GMF editor integration within Comparison editor ==<br />
<br />
The integration of GMF editor within the comparison editor has to be done through specific contentMergeViewer (org.eclipse.compare.contentMergeViewers extension point) and maybe a specific structureMergerViewer (org.eclipse.compare.structureMergeViewers extension point) to provide the separation between graphical differences and semantic differences.<br />
<br />
The content merge viewer has to instantiate DiagramGraphicalViewer inside its '''createControls()''' method:<br />
<br />
viewer = new DiagramGraphicalViewer();<br />
viewer.createControl(composite);<br />
viewer.getControl().setBackground(ColorConstants.listBackground);<br />
<br />
The resize of the left/right/ancestor panes has to be handled gracefully like this:<br />
<br />
viewer_left.getControl().setBounds(x, y, leftWidth, height);<br />
viewer_right.getControl().setBounds(x + leftWidth + centerWidth, y, rightWidth, height);<br />
<br />
=== Initialization ===<br />
<br />
The left/right/ancestor viewers has to be initialized with a proper editing domain. This creation takes the resourceSet as input:<br />
<br />
DiagramEditingDomainFactory.getInstance().createEditingDomain(resourceset);<br />
<br />
Then, the viewers has to be configured like this: <br />
<br />
viewer.setEditDomain(new DefaultEditDomain(null)); // GEF editDomain<br />
viewer.setEditPartFactory(EditPartService.getInstance());<br />
viewer.setRootEditPart(new DiagramRootEditPart(diag.getMeasurementUnit()));<br />
viewer.setContents(diag); // the diagram from the notation model<br />
<br />
It is also possible to make the viewer uneditable by browsing all children of the rootEditPart of each viewer, but then, we will not be able to ask for the '''editability''' of views. It should be better to add a top layer that forbid the editing.<br />
<br />
== Markers for GMF diagrams ==<br />
<br />
Difference marker on notation model are provided by using the '''org.eclipse.gmf.runtime.diagram.ui.decoratorProviders''' extension point.<br />
<br />
The provided IDecoratorProvider will create a decorator based on the proposed IDecoratorTarget. This IDecoratorTarget can be adapted to a Notation View like this :<br />
<br />
View view = (View) decoratorTarget.getAdapter(View.class);<br />
<br />
The decorator should be created if, and only if, there is a graphical difference associated with the given View. The graphical difference model will be retrieved from the owning EditPart.<br />
<br />
Provided decorators has to implement IDecorator interface. <br />
<br />
The issue with specific decorator is to define the locator. Each Figure has its own bounds and we will start from the assumption that:<br />
<br />
* Marker of decorated figure will be rectangle following their bounds (smallest rectangle completely enclosing the IFigure)<br />
* Marker of decorated edges will be handled for polylines only and bounds of the decoration will be the bounds of the decorated<br />
* Marker of move will be an icon (picture not yet defined) located:<br />
** in the middle of the edge if the edge has moved<br />
** in the top right of the bounds of the figure if it is a node.<br />
<br />
See samples of first annotation prototypes (on Ecore diagram):<br />
<br />
Class added:<br />
[[Image:markedAdded.png]]<br />
<br />
Class removed:<br />
[[Image:markedRemoved.png]]<br />
<br />
Label of class changed:<br />
[[Image:markedLabel.png]]<br />
<br />
Edge marked (added)<br />
[[Image:markedEdge.png]]<br />
<br />
Edge marked (moved)<br />
[[Image:markedMovedEdge.png]]<br />
<br />
=== Implementation ===<br />
<br />
Here are some screenshots of the current development under the ericsson_integration branch of the following repository https://github.com/mbarbero/emfcompare <br />
<br />
{| cellspacing=&quot;1&quot; cellpadding=&quot;1&quot; border=&quot;1&quot;<br />
|-<br />
! align=&quot;center&quot;| Description<br />
! align=&quot;center&quot;| State<br />
! align=&quot;center&quot;| Screenshot<br />
|-<br />
| Added nodes<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC1.png|thumb]]<br />
|-<br />
| Deleted nodes<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC2.png|thumb]]<br />
|-<br />
| Mix of added and deleted nodes<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC3.png|thumb]]<br />
|-<br />
| Added node inside a node<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC04.png|thumb]]<br />
|-<br />
| Removed node inside a node<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC05.png|thumb]]<br />
|-<br />
| Moved node<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC6.png|thumb]]<br />
| [[Image:preference.png|thumb|A move threshold can be set in the preference page to detect this change]]<br />
|-<br />
| Modified bounds of a node<br />
! style=&quot;color:red&quot; | ko<br />
| [[Image:TC7.png|thumb|not implemented]]<br />
|-<br />
| Hidden node<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC09.png|thumb]]<br />
|-<br />
| Revealed node<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC08.png|thumb]]<br />
|-<br />
| Modified label<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC10.png|thumb]]<br />
|-<br />
| Added label<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC11.png|thumb]]<br />
|-<br />
| Removed label<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC12.png|thumb]]<br />
|-<br />
| Mix of added and removed label<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC13.png|thumb]]<br />
|-<br />
| Hidden label<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC15.png|thumb]]<br />
|-<br />
| Revealed label<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC14.png|thumb]]<br />
|-<br />
| Modified label<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC16.png|thumb]]<br />
|-<br />
| Modified label<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC17.png|thumb]]<br />
|-<br />
| Added edge<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC18.png|thumb|no highlight on labels]]<br />
|-<br />
| Removed edge<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC19.png|thumb|no highlight on labels]]<br />
|-<br />
| Mix of added and removed edges<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC20.png|thumb|no highlight on labels]]<br />
|-<br />
| Moved edge<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC21.png|thumb]]<br />
|-<br />
| Modified edge label<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC23.png|thumb]]<br />
|-<br />
| Modified edge label<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC24.png|thumb]]<br />
|-<br />
| Revealed edge<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC25.png|thumb]]<br />
|-<br />
| Hidden edge<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC26.png|thumb]]<br />
|-<br />
| Revealed edge label<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC27.png|thumb]]<br />
|-<br />
| Hidden edge label<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC28.png|thumb]]<br />
|-<br />
| Removed node with edge<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC29.png|thumb| no highlight on labels]]<br />
|-<br />
| Removed node with edge ( delete from diagram )<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC30.png|thumb| no highlight on labels]]<br />
|-<br />
| Removed edge ( delete from diagram )<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC31.png|thumb| no highlight on labels]]<br />
|-<br />
| 3 WAY ; added node<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC32.png|thumb]]<br />
|-<br />
| 3 WAY ; removed node<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC33.png|thumb]]<br />
|-<br />
| 3 WAY ; moved node (remote)<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC34.png|thumb | both nodes are marked]]<br />
|-<br />
| 3 WAY ; moved node (local)<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC35.png|thumb | both nodes are marked]]<br />
|-<br />
| 3 WAY ; modified label<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC36.png|thumb]]<br />
|-<br />
| 3 WAY ; remotely hidden node<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC37.png|thumb]]<br />
|-<br />
| 3 WAY ; locally hidden node<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC38.png|thumb]]<br />
|-<br />
| 3 WAY ; remotely revealed node<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC39.png|thumb]]<br />
|-<br />
| 3 WAY ; locally revealed node<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC40.png|thumb]]<br />
|-<br />
| Multiple diagram ; Added node in sub-diagram<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC50.png|thumb]]<br />
|-<br />
| Multiple diagram ; Removed node in sub-diagram<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC51.png|thumb]]<br />
|-<br />
| Multiple diagram ; Mix of Added and Removed node in sub-diagram<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC52.png|thumb]] [[Image:TC52b.png|thumb]]<br />
|-<br />
| 3 WAY and Multiple diagram ; Modified labels in sub-diagram<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC53a.png|thumb]] [[Image:TC53b.png|thumb]]<br />
<br />
|}</div>Stephane.bouchet.obeo.frhttp://wiki.eclipse.org/index.php?title=File:TC53b.png&diff=271958File:TC53b.png2011-10-11T13:48:49Z<p>Stephane.bouchet.obeo.fr: </p>
<hr />
<div></div>Stephane.bouchet.obeo.frhttp://wiki.eclipse.org/index.php?title=File:TC53a.png&diff=271957File:TC53a.png2011-10-11T13:48:38Z<p>Stephane.bouchet.obeo.fr: </p>
<hr />
<div></div>Stephane.bouchet.obeo.frhttp://wiki.eclipse.org/index.php?title=File:TC52b.png&diff=271956File:TC52b.png2011-10-11T13:43:36Z<p>Stephane.bouchet.obeo.fr: </p>
<hr />
<div></div>Stephane.bouchet.obeo.frhttp://wiki.eclipse.org/index.php?title=EMF_Compare/GMF_Notation_model_Comparison&diff=271955EMF Compare/GMF Notation model Comparison2011-10-11T13:43:05Z<p>Stephane.bouchet.obeo.fr: /* Implementation */</p>
<hr />
<div>The GMF diagram comparison task can be splitted into four parts. First, we must be able to compare GMF Notation models, then we have to know how we handle the link with the comparison of the semantic model (i.e. the elements represented by the diagram). Third, we have to know how to integrate existing GMF editor within the EMF Compare editor. Finally, we have to know how to create generic markers on the diagram to give a feedback of the computed differences to the user.<br />
<br />
== Notation model comparison ==<br />
<br />
Notation model comparison need its own MatchEngine and DiffEngine. The whole notation metamodel will not be taken into account. The difference computation will only occur on a subpart as depicted below:<br />
<br />
[[Image:gmf_notation_compare.png]]<br />
<br />
The nodes and edges will be matched by their XMI IDs. Containment between nodes will be handled in a generic way (i.e. by the super class GenericMatchEngine). <br />
<br />
Only following differences will be computed:<br />
<br />
* Addition / Removal of a node<br />
* Addition / Removal of an edge<br />
* Change of a Label on an edge or on a node<br />
* Move of a node within the diagram (with a configurable translation threshold for the move its location x/y).<br />
* Move of an edge within the diagram (total number of bendpoints, change of bendpoints - sourceX, sourceY, targetX, targetY - and positions of the anchors).<br />
<br />
== Link with the semantic comparison ==<br />
<br />
For many cases, we need the semantic comparison to be done before the graphical one. The work on logical model integration should give us this facility by computing the differences of a whole resource set instead of just the current resource containing the notation model.<br />
<br />
The link with the semantic comparison had to be provided for the labels. For each element , we have to get the text of the label and compare them. They are not stored directly into the notation model.<br />
<br />
Move operations of Edge and Node never correspond to semantic change.<br />
<br />
For addition and removal of nodes and edges, graphical differences may or may not corresponds to a semantic change. For instance, a graphical element may be removed because it has been hidden or deleted from the diagram. It does not correspond to a change in the semantic model. This graphical change does not have to be linked to a semantic change. In the other case, the addition or the removal of a node or an edge must match an addition or a deletion in the semantic model.<br />
<br />
=== Merge ===<br />
<br />
As a we don't know from the notation model how labels are build and from which feature(s) of the semantic model, the merge operation of labels modification must be applied on the notation model to trigger the appropriate underlying commands on the semantic model. This merger operation can be triggered only if the label is editable (=&gt; ask to the editpart of the view '''isEditModeEnabled()''')<br />
<br />
The merge of a move a node or an edge never triggers a merge on the semantic model, only on the graphical notation. The merge is a simple copy of values of bendpoints/layout constraints.<br />
<br />
Addition/Removal of node or edge trigger the merge of the semantic difference if it is associated to one, and the merge operation of the graphical difference otherwise. This merge operation consist of re-create the element if it has been deleted from the diagram, or to restor the hidden status of this view (View.isVisible())<br />
<br />
== Use of Difference Extensions and Hiding mechanism ==<br />
<br />
To detect the differences related to functional cases of diagram comparison, new kinds of differences (extensions) are created to complete the DiffModel.<br />
<br />
These extensions lean on the generic differences to be build and they are able to hide them.<br />
<br />
Here is the list of the generic differences which are managed and, for each of them, what are the extensions which are created and the differences which are hidden:<br />
<br />
* A '''ModelElementChangeLeftTarget''' difference, related to a ''View'', will involve the creation of a '''''DiagramModelElementChangeLeftTarget''''' difference extension. This extension will hide the '''ModelElementChangeLeftTarget''' input difference which was used to build it.<br />
<br />
* In the same way, a '''ModelElementChangeRightTarget''' difference, related to a ''View'', will involve the creation of a '''''DiagramModelElementChangeRightTarget''''' difference extension. This extension will hide the '''ModelElementChangeRightTarget''' input difference which was used to build it.<br />
<br />
* An '''UpdateAttribute''' on the ''EAttribute'' &quot;''View_visible''&quot;, where the right view is not visible and it is not a remotely change OR the right view is visible but it is a remotely change, will involve the creation of a '''''DiagramShowElement''''' difference extension. This one will hide the '''UpdateAttribute''' input difference which was used to build it.<br />
<br />
* In the same way, an '''UpdateAttribute''' on the ''EAttribute'' &quot;''View_visible''&quot;, where the left view is not visible and it is not a remotely change or the left view is visible but it is a remotely change, will involve the creation of a '''''DiagramHideElement''''' difference extension. This one will hide the '''UpdateAttribute''' input difference which was used to build it.<br />
<br />
* An '''UpdateAttribute''', where the container of its ''EAttribute'' is a ''Location'' and the related compared elements are not edges and the move is over the threshold specified in the page preferences, will involve the creation of a '''''DiagramMoveNode''''' difference extension. This extension will hide the '''UpdateAttribute''' input difference which was used to build it.<br />
<br />
* On each matched object, it is checked (in the same time as the attributes checking) if the GMF labels are different to create a '''''DiagramLabelChange''''' difference extension. This one hides no existing difference. To check the labels, the ''ITextAwareEditPart'' edit parts are retrieved and their GMF parser to get the print string and to compare them.<br />
<br />
* An '''UpdateAttribute''', where the container of its ''EAttribute'' is a ''RelativeBendpoints'' OR the ''EAttribute'' is ''IdentityAnchor_Id'', will involve the creation of a '''''DiagramEdgeChange''''' difference extension. Besides, an '''ModelElementChange''', where the related element is an ''IdentityAnchor'', will involve the creation of a '''''DiagramEdgeChange''''' difference extension too. For a same ''Edge'', it is possible to have several combined generic differences (several '''UpdateAttribute''' and '''ModelElementChange'''). To create only one extension for these ones, it is checked if there already exists a '''''DiagramEdgeChange''''' for this ''Edge'' in the building ''DiffModel''. This extension will hide the '''UpdateAttribute''' and/or '''ModelElementChange''' input differences which were used to build it.<br />
<br />
=== Mergers ===<br />
<br />
* For every difference extensions which lean on diagram changes only (no semantic changes), a single merger is used to merge these ones: ''DiagramDiffExtensionMerger''.<br />
It is the case of ''DiagramShowElement'', ''DiagramHideElement'', ''DiagramMoveNode'' and ''DiagramEdgeChange'' difference extensions. The merger retrieves all the hidden differences of the extension and call the related merger for each of them.<br />
<br />
* For ''DiagramLabelChange'', a ''DiagramlabelChangeMerger'' is used to set the new label from the GMF Command. This command allows to deploy changes on the semantic model.<br />
<br />
* For ''DiagramModelElementChangeLeftTarget'' and ''DiagramModelElementChangeRightTarget'', a respectively ''DiagramModelElementChangeLeftTargetMerger'' and ''DiagramModelElementChangeRightTargetMerger'' are used. They have the same behavior as ''DiagramDiffExtensionMerger'' unless for the merge of the delete of a ''View''. Indeed, for the add of a View, the generic merger is able to merge the ''View'' and the semantic object together. But, for the delete, it does not manage to merge the semantic difference. These 2 mergers retrieve the semantic difference to merge it before the merge of the delete of the View.<br />
<br />
== GMF editor integration within Comparison editor ==<br />
<br />
The integration of GMF editor within the comparison editor has to be done through specific contentMergeViewer (org.eclipse.compare.contentMergeViewers extension point) and maybe a specific structureMergerViewer (org.eclipse.compare.structureMergeViewers extension point) to provide the separation between graphical differences and semantic differences.<br />
<br />
The content merge viewer has to instantiate DiagramGraphicalViewer inside its '''createControls()''' method:<br />
<br />
viewer = new DiagramGraphicalViewer();<br />
viewer.createControl(composite);<br />
viewer.getControl().setBackground(ColorConstants.listBackground);<br />
<br />
The resize of the left/right/ancestor panes has to be handled gracefully like this:<br />
<br />
viewer_left.getControl().setBounds(x, y, leftWidth, height);<br />
viewer_right.getControl().setBounds(x + leftWidth + centerWidth, y, rightWidth, height);<br />
<br />
=== Initialization ===<br />
<br />
The left/right/ancestor viewers has to be initialized with a proper editing domain. This creation takes the resourceSet as input:<br />
<br />
DiagramEditingDomainFactory.getInstance().createEditingDomain(resourceset);<br />
<br />
Then, the viewers has to be configured like this: <br />
<br />
viewer.setEditDomain(new DefaultEditDomain(null)); // GEF editDomain<br />
viewer.setEditPartFactory(EditPartService.getInstance());<br />
viewer.setRootEditPart(new DiagramRootEditPart(diag.getMeasurementUnit()));<br />
viewer.setContents(diag); // the diagram from the notation model<br />
<br />
It is also possible to make the viewer uneditable by browsing all children of the rootEditPart of each viewer, but then, we will not be able to ask for the '''editability''' of views. It should be better to add a top layer that forbid the editing.<br />
<br />
== Markers for GMF diagrams ==<br />
<br />
Difference marker on notation model are provided by using the '''org.eclipse.gmf.runtime.diagram.ui.decoratorProviders''' extension point.<br />
<br />
The provided IDecoratorProvider will create a decorator based on the proposed IDecoratorTarget. This IDecoratorTarget can be adapted to a Notation View like this :<br />
<br />
View view = (View) decoratorTarget.getAdapter(View.class);<br />
<br />
The decorator should be created if, and only if, there is a graphical difference associated with the given View. The graphical difference model will be retrieved from the owning EditPart.<br />
<br />
Provided decorators has to implement IDecorator interface. <br />
<br />
The issue with specific decorator is to define the locator. Each Figure has its own bounds and we will start from the assumption that:<br />
<br />
* Marker of decorated figure will be rectangle following their bounds (smallest rectangle completely enclosing the IFigure)<br />
* Marker of decorated edges will be handled for polylines only and bounds of the decoration will be the bounds of the decorated<br />
* Marker of move will be an icon (picture not yet defined) located:<br />
** in the middle of the edge if the edge has moved<br />
** in the top right of the bounds of the figure if it is a node.<br />
<br />
See samples of first annotation prototypes (on Ecore diagram):<br />
<br />
Class added:<br />
[[Image:markedAdded.png]]<br />
<br />
Class removed:<br />
[[Image:markedRemoved.png]]<br />
<br />
Label of class changed:<br />
[[Image:markedLabel.png]]<br />
<br />
Edge marked (added)<br />
[[Image:markedEdge.png]]<br />
<br />
Edge marked (moved)<br />
[[Image:markedMovedEdge.png]]<br />
<br />
=== Implementation ===<br />
<br />
Here are some screenshots of the current development under the ericsson_integration branch of the following repository https://github.com/mbarbero/emfcompare <br />
<br />
{| cellspacing=&quot;1&quot; cellpadding=&quot;1&quot; border=&quot;1&quot;<br />
|-<br />
! align=&quot;center&quot;| Description<br />
! align=&quot;center&quot;| State<br />
! align=&quot;center&quot;| Screenshot<br />
|-<br />
| Added nodes<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC1.png|thumb]]<br />
|-<br />
| Deleted nodes<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC2.png|thumb]]<br />
|-<br />
| Mix of added and deleted nodes<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC3.png|thumb]]<br />
|-<br />
| Added node inside a node<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC04.png|thumb]]<br />
|-<br />
| Removed node inside a node<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC05.png|thumb]]<br />
|-<br />
| Moved node<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC6.png|thumb]]<br />
| [[Image:preference.png|thumb|A move threshold can be set in the preference page to detect this change]]<br />
|-<br />
| Modified bounds of a node<br />
! style=&quot;color:red&quot; | ko<br />
| [[Image:TC7.png|thumb|not implemented]]<br />
|-<br />
| Hidden node<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC09.png|thumb]]<br />
|-<br />
| Revealed node<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC08.png|thumb]]<br />
|-<br />
| Modified label<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC10.png|thumb]]<br />
|-<br />
| Added label<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC11.png|thumb]]<br />
|-<br />
| Removed label<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC12.png|thumb]]<br />
|-<br />
| Mix of added and removed label<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC13.png|thumb]]<br />
|-<br />
| Hidden label<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC15.png|thumb]]<br />
|-<br />
| Revealed label<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC14.png|thumb]]<br />
|-<br />
| Modified label<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC16.png|thumb]]<br />
|-<br />
| Modified label<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC17.png|thumb]]<br />
|-<br />
| Added edge<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC18.png|thumb|no highlight on labels]]<br />
|-<br />
| Removed edge<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC19.png|thumb|no highlight on labels]]<br />
|-<br />
| Mix of added and removed edges<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC20.png|thumb|no highlight on labels]]<br />
|-<br />
| Moved edge<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC21.png|thumb]]<br />
|-<br />
| Modified edge label<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC23.png|thumb]]<br />
|-<br />
| Modified edge label<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC24.png|thumb]]<br />
|-<br />
| Revealed edge<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC25.png|thumb]]<br />
|-<br />
| Hidden edge<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC26.png|thumb]]<br />
|-<br />
| Revealed edge label<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC27.png|thumb]]<br />
|-<br />
| Hidden edge label<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC28.png|thumb]]<br />
|-<br />
| Removed node with edge<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC29.png|thumb| no highlight on labels]]<br />
|-<br />
| Removed node with edge ( delete from diagram )<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC30.png|thumb| no highlight on labels]]<br />
|-<br />
| Removed edge ( delete from diagram )<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC31.png|thumb| no highlight on labels]]<br />
|-<br />
| 3 WAY ; added node<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC32.png|thumb]]<br />
|-<br />
| 3 WAY ; removed node<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC33.png|thumb]]<br />
|-<br />
| 3 WAY ; moved node (remote)<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC34.png|thumb | both nodes are marked]]<br />
|-<br />
| 3 WAY ; moved node (local)<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC35.png|thumb | both nodes are marked]]<br />
|-<br />
| 3 WAY ; modified label<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC36.png|thumb]]<br />
|-<br />
| 3 WAY ; remotely hidden node<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC37.png|thumb]]<br />
|-<br />
| 3 WAY ; locally hidden node<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC38.png|thumb]]<br />
|-<br />
| 3 WAY ; remotely revealed node<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC39.png|thumb]]<br />
|-<br />
| 3 WAY ; locally revealed node<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC40.png|thumb]]<br />
|-<br />
| Multiple diagram ; Added node in sub-diagram<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC50.png|thumb]]<br />
|-<br />
| Multiple diagram ; Removed node in sub-diagram<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC51.png|thumb]]<br />
|-<br />
| Multiple diagram ; Mix of Added and Removed node in sub-diagram<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC52.png|thumb]] [[Image:TC52b.png|thumb]]<br />
<br />
|}</div>Stephane.bouchet.obeo.frhttp://wiki.eclipse.org/index.php?title=EMF_Compare/GMF_Notation_model_Comparison&diff=271952EMF Compare/GMF Notation model Comparison2011-10-11T13:32:26Z<p>Stephane.bouchet.obeo.fr: /* Implementation */</p>
<hr />
<div>The GMF diagram comparison task can be splitted into four parts. First, we must be able to compare GMF Notation models, then we have to know how we handle the link with the comparison of the semantic model (i.e. the elements represented by the diagram). Third, we have to know how to integrate existing GMF editor within the EMF Compare editor. Finally, we have to know how to create generic markers on the diagram to give a feedback of the computed differences to the user.<br />
<br />
== Notation model comparison ==<br />
<br />
Notation model comparison need its own MatchEngine and DiffEngine. The whole notation metamodel will not be taken into account. The difference computation will only occur on a subpart as depicted below:<br />
<br />
[[Image:gmf_notation_compare.png]]<br />
<br />
The nodes and edges will be matched by their XMI IDs. Containment between nodes will be handled in a generic way (i.e. by the super class GenericMatchEngine). <br />
<br />
Only following differences will be computed:<br />
<br />
* Addition / Removal of a node<br />
* Addition / Removal of an edge<br />
* Change of a Label on an edge or on a node<br />
* Move of a node within the diagram (with a configurable translation threshold for the move its location x/y).<br />
* Move of an edge within the diagram (total number of bendpoints, change of bendpoints - sourceX, sourceY, targetX, targetY - and positions of the anchors).<br />
<br />
== Link with the semantic comparison ==<br />
<br />
For many cases, we need the semantic comparison to be done before the graphical one. The work on logical model integration should give us this facility by computing the differences of a whole resource set instead of just the current resource containing the notation model.<br />
<br />
The link with the semantic comparison had to be provided for the labels. For each element , we have to get the text of the label and compare them. They are not stored directly into the notation model.<br />
<br />
Move operations of Edge and Node never correspond to semantic change.<br />
<br />
For addition and removal of nodes and edges, graphical differences may or may not corresponds to a semantic change. For instance, a graphical element may be removed because it has been hidden or deleted from the diagram. It does not correspond to a change in the semantic model. This graphical change does not have to be linked to a semantic change. In the other case, the addition or the removal of a node or an edge must match an addition or a deletion in the semantic model.<br />
<br />
=== Merge ===<br />
<br />
As a we don't know from the notation model how labels are build and from which feature(s) of the semantic model, the merge operation of labels modification must be applied on the notation model to trigger the appropriate underlying commands on the semantic model. This merger operation can be triggered only if the label is editable (=&gt; ask to the editpart of the view '''isEditModeEnabled()''')<br />
<br />
The merge of a move a node or an edge never triggers a merge on the semantic model, only on the graphical notation. The merge is a simple copy of values of bendpoints/layout constraints.<br />
<br />
Addition/Removal of node or edge trigger the merge of the semantic difference if it is associated to one, and the merge operation of the graphical difference otherwise. This merge operation consist of re-create the element if it has been deleted from the diagram, or to restor the hidden status of this view (View.isVisible())<br />
<br />
== Use of Difference Extensions and Hiding mechanism ==<br />
<br />
To detect the differences related to functional cases of diagram comparison, new kinds of differences (extensions) are created to complete the DiffModel.<br />
<br />
These extensions lean on the generic differences to be build and they are able to hide them.<br />
<br />
Here is the list of the generic differences which are managed and, for each of them, what are the extensions which are created and the differences which are hidden:<br />
<br />
* A '''ModelElementChangeLeftTarget''' difference, related to a ''View'', will involve the creation of a '''''DiagramModelElementChangeLeftTarget''''' difference extension. This extension will hide the '''ModelElementChangeLeftTarget''' input difference which was used to build it.<br />
<br />
* In the same way, a '''ModelElementChangeRightTarget''' difference, related to a ''View'', will involve the creation of a '''''DiagramModelElementChangeRightTarget''''' difference extension. This extension will hide the '''ModelElementChangeRightTarget''' input difference which was used to build it.<br />
<br />
* An '''UpdateAttribute''' on the ''EAttribute'' &quot;''View_visible''&quot;, where the right view is not visible and it is not a remotely change OR the right view is visible but it is a remotely change, will involve the creation of a '''''DiagramShowElement''''' difference extension. This one will hide the '''UpdateAttribute''' input difference which was used to build it.<br />
<br />
* In the same way, an '''UpdateAttribute''' on the ''EAttribute'' &quot;''View_visible''&quot;, where the left view is not visible and it is not a remotely change or the left view is visible but it is a remotely change, will involve the creation of a '''''DiagramHideElement''''' difference extension. This one will hide the '''UpdateAttribute''' input difference which was used to build it.<br />
<br />
* An '''UpdateAttribute''', where the container of its ''EAttribute'' is a ''Location'' and the related compared elements are not edges and the move is over the threshold specified in the page preferences, will involve the creation of a '''''DiagramMoveNode''''' difference extension. This extension will hide the '''UpdateAttribute''' input difference which was used to build it.<br />
<br />
* On each matched object, it is checked (in the same time as the attributes checking) if the GMF labels are different to create a '''''DiagramLabelChange''''' difference extension. This one hides no existing difference. To check the labels, the ''ITextAwareEditPart'' edit parts are retrieved and their GMF parser to get the print string and to compare them.<br />
<br />
* An '''UpdateAttribute''', where the container of its ''EAttribute'' is a ''RelativeBendpoints'' OR the ''EAttribute'' is ''IdentityAnchor_Id'', will involve the creation of a '''''DiagramEdgeChange''''' difference extension. Besides, an '''ModelElementChange''', where the related element is an ''IdentityAnchor'', will involve the creation of a '''''DiagramEdgeChange''''' difference extension too. For a same ''Edge'', it is possible to have several combined generic differences (several '''UpdateAttribute''' and '''ModelElementChange'''). To create only one extension for these ones, it is checked if there already exists a '''''DiagramEdgeChange''''' for this ''Edge'' in the building ''DiffModel''. This extension will hide the '''UpdateAttribute''' and/or '''ModelElementChange''' input differences which were used to build it.<br />
<br />
=== Mergers ===<br />
<br />
* For every difference extensions which lean on diagram changes only (no semantic changes), a single merger is used to merge these ones: ''DiagramDiffExtensionMerger''.<br />
It is the case of ''DiagramShowElement'', ''DiagramHideElement'', ''DiagramMoveNode'' and ''DiagramEdgeChange'' difference extensions. The merger retrieves all the hidden differences of the extension and call the related merger for each of them.<br />
<br />
* For ''DiagramLabelChange'', a ''DiagramlabelChangeMerger'' is used to set the new label from the GMF Command. This command allows to deploy changes on the semantic model.<br />
<br />
* For ''DiagramModelElementChangeLeftTarget'' and ''DiagramModelElementChangeRightTarget'', a respectively ''DiagramModelElementChangeLeftTargetMerger'' and ''DiagramModelElementChangeRightTargetMerger'' are used. They have the same behavior as ''DiagramDiffExtensionMerger'' unless for the merge of the delete of a ''View''. Indeed, for the add of a View, the generic merger is able to merge the ''View'' and the semantic object together. But, for the delete, it does not manage to merge the semantic difference. These 2 mergers retrieve the semantic difference to merge it before the merge of the delete of the View.<br />
<br />
== GMF editor integration within Comparison editor ==<br />
<br />
The integration of GMF editor within the comparison editor has to be done through specific contentMergeViewer (org.eclipse.compare.contentMergeViewers extension point) and maybe a specific structureMergerViewer (org.eclipse.compare.structureMergeViewers extension point) to provide the separation between graphical differences and semantic differences.<br />
<br />
The content merge viewer has to instantiate DiagramGraphicalViewer inside its '''createControls()''' method:<br />
<br />
viewer = new DiagramGraphicalViewer();<br />
viewer.createControl(composite);<br />
viewer.getControl().setBackground(ColorConstants.listBackground);<br />
<br />
The resize of the left/right/ancestor panes has to be handled gracefully like this:<br />
<br />
viewer_left.getControl().setBounds(x, y, leftWidth, height);<br />
viewer_right.getControl().setBounds(x + leftWidth + centerWidth, y, rightWidth, height);<br />
<br />
=== Initialization ===<br />
<br />
The left/right/ancestor viewers has to be initialized with a proper editing domain. This creation takes the resourceSet as input:<br />
<br />
DiagramEditingDomainFactory.getInstance().createEditingDomain(resourceset);<br />
<br />
Then, the viewers has to be configured like this: <br />
<br />
viewer.setEditDomain(new DefaultEditDomain(null)); // GEF editDomain<br />
viewer.setEditPartFactory(EditPartService.getInstance());<br />
viewer.setRootEditPart(new DiagramRootEditPart(diag.getMeasurementUnit()));<br />
viewer.setContents(diag); // the diagram from the notation model<br />
<br />
It is also possible to make the viewer uneditable by browsing all children of the rootEditPart of each viewer, but then, we will not be able to ask for the '''editability''' of views. It should be better to add a top layer that forbid the editing.<br />
<br />
== Markers for GMF diagrams ==<br />
<br />
Difference marker on notation model are provided by using the '''org.eclipse.gmf.runtime.diagram.ui.decoratorProviders''' extension point.<br />
<br />
The provided IDecoratorProvider will create a decorator based on the proposed IDecoratorTarget. This IDecoratorTarget can be adapted to a Notation View like this :<br />
<br />
View view = (View) decoratorTarget.getAdapter(View.class);<br />
<br />
The decorator should be created if, and only if, there is a graphical difference associated with the given View. The graphical difference model will be retrieved from the owning EditPart.<br />
<br />
Provided decorators has to implement IDecorator interface. <br />
<br />
The issue with specific decorator is to define the locator. Each Figure has its own bounds and we will start from the assumption that:<br />
<br />
* Marker of decorated figure will be rectangle following their bounds (smallest rectangle completely enclosing the IFigure)<br />
* Marker of decorated edges will be handled for polylines only and bounds of the decoration will be the bounds of the decorated<br />
* Marker of move will be an icon (picture not yet defined) located:<br />
** in the middle of the edge if the edge has moved<br />
** in the top right of the bounds of the figure if it is a node.<br />
<br />
See samples of first annotation prototypes (on Ecore diagram):<br />
<br />
Class added:<br />
[[Image:markedAdded.png]]<br />
<br />
Class removed:<br />
[[Image:markedRemoved.png]]<br />
<br />
Label of class changed:<br />
[[Image:markedLabel.png]]<br />
<br />
Edge marked (added)<br />
[[Image:markedEdge.png]]<br />
<br />
Edge marked (moved)<br />
[[Image:markedMovedEdge.png]]<br />
<br />
=== Implementation ===<br />
<br />
Here are some screenshots of the current development under the ericsson_integration branch of the following repository https://github.com/mbarbero/emfcompare <br />
<br />
{| cellspacing=&quot;1&quot; cellpadding=&quot;1&quot; border=&quot;1&quot;<br />
|-<br />
! align=&quot;center&quot;| Description<br />
! align=&quot;center&quot;| State<br />
! align=&quot;center&quot;| Screenshot<br />
|-<br />
| Added nodes<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC1.png|thumb]]<br />
|-<br />
| Deleted nodes<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC2.png|thumb]]<br />
|-<br />
| Mix of added and deleted nodes<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC3.png|thumb]]<br />
|-<br />
| Added node inside a node<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC04.png|thumb]]<br />
|-<br />
| Removed node inside a node<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC05.png|thumb]]<br />
|-<br />
| Moved node<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC6.png|thumb]]<br />
| [[Image:preference.png|thumb|A move threshold can be set in the preference page to detect this change]]<br />
|-<br />
| Modified bounds of a node<br />
! style=&quot;color:red&quot; | ko<br />
| [[Image:TC7.png|thumb|not implemented]]<br />
|-<br />
| Hidden node<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC09.png|thumb]]<br />
|-<br />
| Revealed node<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC08.png|thumb]]<br />
|-<br />
| Modified label<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC10.png|thumb]]<br />
|-<br />
| Added label<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC11.png|thumb]]<br />
|-<br />
| Removed label<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC12.png|thumb]]<br />
|-<br />
| Mix of added and removed label<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC13.png|thumb]]<br />
|-<br />
| Hidden label<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC15.png|thumb]]<br />
|-<br />
| Revealed label<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC14.png|thumb]]<br />
|-<br />
| Modified label<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC16.png|thumb]]<br />
|-<br />
| Modified label<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC17.png|thumb]]<br />
|-<br />
| Added edge<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC18.png|thumb|no highlight on labels]]<br />
|-<br />
| Removed edge<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC19.png|thumb|no highlight on labels]]<br />
|-<br />
| Mix of added and removed edges<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC20.png|thumb|no highlight on labels]]<br />
|-<br />
| Moved edge<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC21.png|thumb]]<br />
|-<br />
| Modified edge label<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC23.png|thumb]]<br />
|-<br />
| Modified edge label<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC24.png|thumb]]<br />
|-<br />
| Revealed edge<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC25.png|thumb]]<br />
|-<br />
| Hidden edge<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC26.png|thumb]]<br />
|-<br />
| Revealed edge label<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC27.png|thumb]]<br />
|-<br />
| Hidden edge label<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC28.png|thumb]]<br />
|-<br />
| Removed node with edge<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC29.png|thumb| no highlight on labels]]<br />
|-<br />
| Removed node with edge ( delete from diagram )<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC30.png|thumb| no highlight on labels]]<br />
|-<br />
| Removed edge ( delete from diagram )<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC31.png|thumb| no highlight on labels]]<br />
|-<br />
| 3 WAY ; added node<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC32.png|thumb]]<br />
|-<br />
| 3 WAY ; removed node<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC33.png|thumb]]<br />
|-<br />
| 3 WAY ; moved node (remote)<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC34.png|thumb | both nodes are marked]]<br />
|-<br />
| 3 WAY ; moved node (local)<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC35.png|thumb | both nodes are marked]]<br />
|-<br />
| 3 WAY ; modified label<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC36.png|thumb]]<br />
|-<br />
| 3 WAY ; remotely hidden node<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC37.png|thumb]]<br />
|-<br />
| 3 WAY ; locally hidden node<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC38.png|thumb]]<br />
|-<br />
| 3 WAY ; remotely revealed node<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC39.png|thumb]]<br />
|-<br />
| 3 WAY ; locally revealed node<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC40.png|thumb]]<br />
|-<br />
| Multiple diagram ; Added node in sub-diagram<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC50.png|thumb]]<br />
|-<br />
| Multiple diagram ; Removed node in sub-diagram<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC51.png|thumb]]<br />
|-<br />
| Multiple diagram ; Mix of Added and Removed node in sub-diagram<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC52.png|thumb]]<br />
<br />
|}</div>Stephane.bouchet.obeo.frhttp://wiki.eclipse.org/index.php?title=File:TC40.png&diff=271951File:TC40.png2011-10-11T13:32:14Z<p>Stephane.bouchet.obeo.fr: </p>
<hr />
<div></div>Stephane.bouchet.obeo.frhttp://wiki.eclipse.org/index.php?title=EEF/Installation_Guide&diff=271442EEF/Installation Guide2011-10-06T14:19:02Z<p>Stephane.bouchet.obeo.fr: /* EEF Installation */</p>
<hr />
<div>== EEF Installation ==<br />
=== Using update sites ===<br />
<br />
* Add the [[Acceleo]] update site :<br />
<br />
http://download.eclipse.org/modeling/m2t/acceleo/updates/releases/3.1<br />
<br />
* Add the EEF update site ( it contains all the releases from 0.8 )<br />
<br />
http://download.eclipse.org/modeling/emft/eef/updates/releases<br />
<br />
* Looking for an older version ? <br />
<br />
EEF 1.0 is located here : http://download.eclipse.org/modeling/emft/eef/updates/releases/1.0<br />
<br />
EEF 0.9 is located here : http://download.eclipse.org/modeling/emft/eef/updates/releases/0.9<br />
<br />
EEF 0.8 is located here : http://download.eclipse.org/modeling/emft/eef/updates/releases/0.8<br />
<br />
EEF 0.7 does not provides an update site.<br />
<br />
* looking for development builds ? (WARNING, some builds are not qualified, [http://www.eclipse.org/modeling/downloads/build-types.php explanation of the different build types here]):<br />
** Stables ( includes Milestones and Releases Candidates ) : http://download.eclipse.org/modeling/emft/eef/updates/milestones/1.1<br />
** Interim ( includes Integration and Maintenance ) : http://download.eclipse.org/modeling/emft/eef/updates/interim/1.1<br />
** Nightly : http://download.eclipse.org/modeling/emft/eef/updates/nightly/1.1<br />
<br />
<br />
=== From Annual release train ===<br />
<br />
*EEF is integrated in the annual eclipse release train ! Just find it in the installable softwares.<br />
<br />
=== From Eclipse modeling package ===<br />
<br />
*Use the modeling discovery Ui and choose EEF !<br />
<br />
=== Directly from eclipse.org ===<br />
<br />
You can also access to the archived EEF update site and SDK here : http://www.eclipse.org/modeling/emft/downloads/?project=eef<br />
<br />
== Third Parties ==<br />
<br />
EEF extension requires the RichText plugin of the EPF project. We aren't able to provide a P2 artifact for this plugin, you download it on the EPF website. Here is the download page where you can found the RichText feature : http://www.eclipse.org/epf/downloads/tool/epf1.5.0_downloads.php .<br />
<br />
You only need the RichText feature, so you have to download the RichText specific feature like http://www.eclipse.org/downloads/download.php?file=/technology/epf/composer/release/epfc-richtext-1.5.1.1-win32.zip or http://www.eclipse.org/downloads/download.php?file=/technology/epf/composer/release/epfc-richtext-1.5.1.1-linux.zip.<br />
<br />
[[Category:EEF]]</div>Stephane.bouchet.obeo.frhttp://wiki.eclipse.org/index.php?title=CBI/aggregator/manual&diff=263981CBI/aggregator/manual2011-08-09T12:55:26Z<p>Stephane.bouchet.obeo.fr: /* Running from the command line */</p>
<hr />
<div>=Introduction=<br />
The Aggregator is based on and part of the ''Eclipse b3'' project. b3 provides a versatile and adaptable framework supporting build, assembly and deployment processes. It supports a rich set of use cases. One of those - the aggregation of repositories - is the focus of the ''b3 Aggregator'' tool.<br />
<br />
The Aggregator combines repositories from various sources into a new aggregated p2 repository. It can also be configured to produce a hybrid p2/Maven2 repository. <br />
There are many situations where using aggregated repositories is a good solution. The reasons vary from licensing issues to organizational requirements:<br />
#'''Owners of a p2 repo for a given project may not be in position to host all required or recommended components due to licensing issues''' - Buckminster's SVN support can serve as an example here, as it requires components available through the main Eclipse p2 repo as well as third-party components. Hence users have to visit several repos for a complete install. <br />
#'''Projects want to provide convenient access to their products''' - Installation instructions requiring the user to visit several repos for a complete install are not uncommon. An aggregated repo for all those locations provides a convenient one-stop strategy. The aggregation may support mirroring all consumed p2 repos or simply providing an indirection via a composite repo.<br />
#'''Organizations or teams want control over internally used components''' - It may be necessary to have gated access to relevant p2 repos and do an organizational &quot;healthcheck&quot; of those before internal distribution. Furthermore, internally used aggregated repos can provide a common basis for all organizational users.<br />
#'''Increase repository availability''' - by aggregating and mirroring what is used from multiple update sites into an internally controlled server (or several).<br />
#'''Distributed Development Support''' - an overall product repository is produced by aggregating contributions from multiple teams.<br />
<br />
The Aggregator tool is focused on supporting these specific requirements, and it plays an important role in the full scope of the b3 project. The Aggregator is however used in scenarios outside of the traditional &quot;build domain&quot; and this has been reflected in the user interface which does not delve into the details of &quot;building&quot; and should therefore be easy to use by non build experts.<br />
<br />
Furthermore, it is worth noting that:<br />
* the Aggregator is based on EMF models<br />
* headless execution of aggregation definitions (once they have been created) is possible using a command line packaging of the Aggregator<br />
<br />
=Functional Overview=<br />
The b3 Aggregator performs aggregation and validation of repositories. The input to the aggregator engine (that tells it what to do) is a ''b3aggr'' EMF model. Such a model is most conveniently created by using the b3 Aggregator editor. This editor provides both editing and interactive execution of aggregation commands. The editor is based on a standard EMF &quot;tree and properties view&quot; style editor where nodes are added and removed to from a tree, and the details of nodes are edited in a separate properties view. Once a b3aggr model has been created it is possible to use the command line / headless aggregator to perform aggregation (and other related commands). (Note that since the b3aggr is &quot;just an EMF model&quot;, it can be produced via EMF APIs, transformation tools, etc., and thus support advanced use cases).<br />
<br />
The model mainly consists of ''Contributions'' - specifications of what to include from different repositories, and ''Validation Repositories'' - repositories that are used when validating, but which are not included in the produced aggregation (i.e., they are not copied). The model also contains specification of various processing rules (exclusions, transformation of names, etc.), and specification of ''Contacts'' - individuals/mailing-lists to inform when processing fails.<br />
<br />
Here are some of the important features supported by the b3 Aggregator:<br />
* '''p2''' and '''maven2''' support — the aggregator can aggregate from and to both p2 and maven2 repositories.<br />
* '''Maven2 name mapping support''' — names in the p2 domain are automatically mapped to maven2 names using built-in rules. Custom rules are also supported.<br />
* '''Mirroring''' — artifacts from repositories are mirrored/downloaded/copied to a single location.<br />
* '''Selective mirroring''' — an aggregation can produce an aggregate consisting of a mix of references to repositories and mirrored repositories.<br />
* '''Cherry picking''' — it is possible to pick individual items when the entire content of a repository is not wanted. Detailed picking is supported as well as picking transitive closures like a product, or a category to get everything it contains/requires.<br />
* '''Pruning''' — it is possible to specify mirroring based on version ranges. This can be used to reduce the size of the produced result when historical versions are not needed in the aggregated result.<br />
* '''Categorization''' — categorization of installable units is important to the consumers of the aggregated repository. Categories are often choosen by repository publishers in a fashion that makes sense when looking at a particular repository in isolation, but when they are combined with others it can be very difficult for the user to understand what they relate to. An important task for the constructor of an aggregation is to be able to organize the aggregated material in an easily consumable fashion. The b3 aggregator has support for category prefixing, category renaming, addition of custom categories, as well as adding and removing features in categories. <br />
* '''Validation''' — the b3 aggregator validates the aggregated result to ensure that everything in the repository is installable. <br />
* '''Blame Email''' — when issues are found during validation, the aggregator supports sending emails describing the issue. This is very useful when aggregating the result of many different projects. Advanced features include specifying contacts for parts of the aggregation, which is useful in large multi-layer project structures where issues may be related to the combination of a group of projects rather than one individual project - someone responsible for the aggregation itself should be informed about these cross-project issues. The aggregator supports detailed control over email generation, including handling of mock emails when testing aggregation scripts.<br />
<br />
=Installation=<br />
Start by installing a fresh Eclipse 3.7 SDK from http://download.eclipse.org/eclipse/downloads<br />
<br />
The b3 aggregator can either be integrated in your Eclipse SDK or it can be installed as a standalone headless product (i.e. pure command line, without any graphical UI).<br />
<br />
The instructions below show the current URLs (when this document was written). Always check the latest information on the [http://eclipse.org/modeling/emft/b3/download/ b3 download page] before installing. <br />
<br />
== Eclipse SDK installation ==<br />
<br />
{|<br />
|-<br />
| colspan=&quot;2&quot; | <br />
*Start your Eclipse installation and open the '''''Install New Software wizard'''''. You'll find in under the top menu ''Help'' <br />
[[Image:B3 Install New Software.png|thumb|center|580x492px|Install New Software wizard]] <br />
*Click the ''Add...'' button and enter the URL '''''&lt;nowiki&gt;http://download.eclipse.org/modeling/emft/b3/updates-3.7/&lt;/nowiki&gt;''''' in the ''Location'' field. Or alternatively, if you feel adventurous and want to use the latest build, '''''&lt;nowiki&gt;https://hudson.eclipse.org/hudson/job/emft-b3-build/lastSuccessfulBuild/artifact/b3.p2.repository/&lt;/nowiki&gt;'''''.<br />
*Select the '''''b3 Aggregator Editor''''' and click ''Next'' twice. <br />
[[Image:B3 Install Aggregator.png|thumb|center|580x492px|b3 Aggregator Editor selection]]<br />
*Accept the Eclipse Public License and click ''Finish'' <br />
*Restart the IDE once the installation is finished.<br />
|-<br />
|}<br />
<br />
==Headless installation==<br />
Installation of the headless version of the Aggregator is similar to a typical headless b3 installation. The following steps focus on the installation of the headless Aggregator feature.<br />
<br />
#Start by '''Downloading the (headless) director''' which can be found [http://www.eclipse.org/downloads/download.php?file=/tools/buckminster/products/director_latest.zip here].<br />
#Next '''unpack the director''' to a location of your choice. You may want to set the &lt;code&gt;PATH&lt;/code&gt; to include the install location and make the director accessible for additional use.<br />
#'''Install b3''' with the following command: <br />
#*&lt;code&gt;director -r &lt;HEADLESS_REPO&gt; -d &lt;INSTALL_DIR&gt; -p b3 -i org.eclipse.b3.cli.product -i org.eclipse.b3.aggregator.engine.feature.feature.group&lt;/code&gt; where<br />
#**'''''-r &lt;HEADLESS_REPO&gt;''''' is the headless p2 update site: Current stable version is: '''''&lt;nowiki&gt;http://download.eclipse.org/modeling/emft/b3/headless-3.7&lt;/nowiki&gt;''''', and our latest build can be found at '''''&lt;nowiki&gt;https://hudson.eclipse.org/hudson/job/emft-b3-build/lastSuccessfulBuild/artifact/b3.headless.p2.repository&lt;/nowiki&gt;'''''<br />
#**'''''-d &lt;INSTALL_DIR&gt;''''' is the chosen install location of the headless b3<br />
#**'''''-p b3''''' is the name of the p2 profile<br />
#**'''''-i org.eclipse.b3.cli.product''''' is the name of the headless b3 base<br />
#**'''''-i org.eclipse.b3.aggregator.engine.feature.feature.group''''' is the name of the aggregator feature<br />
<br />
=Getting started with standard examples=<br />
In the following sections we provide two simple examples that are easy to replicate and should highlight the most important features of the Aggregator. <br />
The first example deals with the creation of two variations of a p2 repo. The second shows the Aggregator's Maven support.<br />
<br />
==Aggregating a p2 repo==<br />
The first sample aggregation is build around Buckminster and its support for Subversive. The objective of this aggregated repo is to:<br />
*provide a &quot;one-stop shop&quot; experience<br />
*conveniently pull in third-party components that are not hosted at Eclipse<br />
*provide this repo as an indirection mechanism if required<br />
<br />
=== Mirroring contributions ===<br />
<br />
(This example aggregation can be downloaded via the b3 project SVN and opened in an appropriately set up workbench: [http://dev.eclipse.org/svnroot/modeling/org.eclipse.emft.b3/trunk/org.eclipse.b3.aggregator.samples/buckminster_indigo.b3aggr buckminster_indigo.b3aggr]). <br />
<br />
The background is that Buckminster provides support for Subclipse. In addition to all components hosted at Eclipse, a complete installation will also require Subclipse components from Tigris.org (http://subclipse.tigris.org/update_1.6.x). We want to create a repo that combines these components and makes them accessible from one location. We want to make several platform configurations available. <br />
<br />
[[Image:B3 aggregator sample 1.png|thumb|center|800x750px|b3 Aggregator - Sample 1]] <br />
<br />
This example already includes some of the more advanced aggregation features. Stepping through the model view from the top node the following components can be identified: <br />
<br />
#The top node '''''Aggregation''''' groups all model definitions regarding '''''ValidationSet'''''s and '''''Contribution'''''s. Looking at the properties section at the bottom we see that: <br />
#*the top node has been provided with a mandatory ''Label'' with the value &quot;Indigo + Buckminster for Subclipse&quot;; this is also the label that is shown to users when accessing the aggregated repo via the p2 update manager <br />
#*the ''Build Root'' identifies the location to which the artifacts of the aggregated repo will be deployed <br />
#The aggregation is defined for three configurations (i.e. os=win32, ws=win32, arch=x86; etc) <br />
#*any number of configurations can be defined<br />
#*during the aggregation process all dependencies of the ''contributed'' components will be verified for all provided configurations, unless exceptions are defined (see below) <br />
#We have one ValidationSet labeled &quot;main&quot;. A ValidationSet constitutes everything that will be validated as one unit by the p2 planner.<br />
#The ''main'' ValidationSet contains three different contributions.<br />
#The first '''''Contribution''''' to the aggregation is labeled &quot;Indigo&quot;. This contribution includes binary configuration-specific artifacts which are only available for linux. If a simple contribution would be defined the aggregation would fail for all non-linux configurations, and hence the aggregation would fail as a whole. <br />
#*this requires a definition of '''''Valid Configurations Rule'''''s that state exceptions <br />
#*the rules defined for the the three components in question essentially state that the verification process for those components should only be performed for linux-based configurations<br />
#*one '''''Mapped Repository''''' is defined for this contribution (it can have multiple); all that is needed is a user-defined label and the URL of the repository that should be included <br />
#*the result of this definition is that all categories, products, and features from Indigo p2 repo will be included in the aggregated repo.<br />
#The second '''''Contribution''''' is labeled &quot;Subclipse&quot; and deals with the inclusion of bundles provided from the Subclipse project. #*this contribution represents the simplest example of a contribution <br />
#The third '''''Contribution''''' is labeled &quot;Buckminster (latest)&quot;. It shows another advanced feature - an '''''Exclusion Rule'''''. <br />
#*remember that the objective of the sample repo is to provide convenient setup of Buckminster with Subclipse support, and since Buckminster's Subclipse and Subversive support are mutually exclusive, we want to exclude the features for Subversive from the aggregated repo to make it easier for the user. <br />
#*this is done using an '''''Exclusion Rule''''' defined for each Installable Unit that should be excluded <br />
#A list of all included repos is displayed at the bottom of the model editor view <br />
#*this list allows browsing the contents of all repos <br />
#*this part of the model is not editable<br />
<br />
The aggregation can be run by right-clicking any node in the model and selecting '''''Build Aggregation'''''. This example was setup to use a mirroring approach for all contributed repos. Hence, the complete contents of all included can be found in the aggregated repos target location specified under '''''Build Root'''''. <br />
<br />
Check the next section for a slightly different approach.<br />
<br />
===Providing a repo indirection===<br />
{|- width=&quot;100%&quot;<br />
|- valign=&quot;top&quot;<br />
|<br />
Mirroring all repo artifacts of your aggregated contributions is a very valuable and important feature when performing aggregation, but there are also many cases where this is not necessary. It is possible to turn off artifact mirroring/copying by changing one property for a defined contribution.<br />
Each '''''Mapped Repository''''' has a boolean property called ''Mirror Artifacts'' which can be set to &lt;code&gt;false&lt;/code&gt; in order to prevent copying all artifacts of the contributed repo to the aggregated repo.<br />
<br />
The following [http://dev.eclipse.org/svnroot/modeling/org.eclipse.emft.b3/trunk/org.eclipse.b3.aggregator.samples/buckminster_helios_redirect.b3aggr buckminster_indigo_redirect.b3aggr] is a variation of the first example with the ''Mirror Artifacts'' property set to &lt;code&gt;false&lt;/code&gt; for all contributed repos. Running this aggregation will result in a composite repository that provides indirection to the contributed repos.<br />
<br />
==Creating a Maven-conformant p2 repo==<br />
{|- width=&quot;100%&quot;<br />
|- valign=&quot;top&quot;<br />
|<br />
A powerful feature of the Aggregator is the ability to create aggregated repos that can be consumed as Maven repos, (i.e. providing the directory/file structure and artifacts required by Maven). An aggregated repository that supports Maven can be consumed both as a p2 and a Maven repo (at the same time). This flexibility is possible thanks to p2's separation of dependency meta-data and the actual location of the referenced artifacts.<br />
<br />
In order to create a Maven-conformant aggregate repo all that is required is to set the property '''''Maven Result''''' property of the '''''Aggregator''''' to &lt;code&gt;true&lt;/code&gt;. The aggregation deployed to the '''''Build Root''''' location will be a Maven repo.<br />
<br />
The sample [http://dev.eclipse.org/svnroot/modeling/org.eclipse.emft.b3/trunk/org.eclipse.b3.aggregator.samples/buckminster_helios_maven.b3aggr buckminster_helios_maven.b3aggr] is a variation of the previous aggregations configured to produce a Maven repo.<br />
<br />
=Headless support=<br />
You will need a [[#Headless installation|headless installation of b3]] with the Aggregator feature installed.<br />
<br />
==Running from the command line==<br />
Just type:&lt;pre&gt;b3 validationSet &lt;options&gt;&lt;/pre&gt; ( if you use version 0.1, just type ''b3 aggregate &lt;options&gt;'' )<br />
<br />
For a detailed listing of the available options consult the next section.<br />
<br />
==Command line options==<br />
{| {{Greytable}} <br />
|-<br />
! Option<br />
! Value<br />
! Default<br />
! Description<br />
<br />
|- valign=&quot;top&quot;<br />
| '''--buildModel'''<br />
| &lt;path to build model&gt;<br />
| This value is required<br />
| Appoints the aggregation definition that drives the execution. The value must be a valid path to a file (absolute or relative to current directory).<br />
<br />
|- valign=&quot;top&quot;<br />
| '''--action'''<br />
| VERIFY<br />
<br />
BUILD<br />
<br />
CLEAN<br />
<br />
CLEAN_BUILD<br />
<br />
| BUILD<br />
| Specifies the type of the execution.<br />
*'''VERIFY''' - verifies model validity and resolves dependencies; no artifacts are copied or created<br />
*'''BUILD''' - performs the aggregation and creates the aggregated repository in the target location<br />
*'''CLEAN''' - cleans all traces of previous aggregations in the specified target location<br />
*'''CLEAN_BUILD''' - performs a CLEAN followed by a BUILD <br />
<br />
|- valign=&quot;top&quot;<br />
| '''--buildId'''<br />
| &lt;string&gt;<br />
| build-&lt;timestamp in the format yyyyMMddHHmm&gt;<br />
| Assigns a build identifier to the aggregation. The identifier is used to identify the build in notification emails. Defaults to: build-&lt;timestamp&gt; where &lt;timestamp&gt; is formatted according as yyyyMMddHHmm, i.e. build-200911031527<br />
<br />
|- valign=&quot;top&quot;<br />
| '''--buildRoot'''<br />
| &lt;path to directory&gt;<br />
| ''buildRoot'' declared in the aggregation model<br />
| Controls the output. Defaults to the build root defined in the aggregation definition. The value must be a valid path to a directory (absolute or relative to current folder). If the desired directory structure does not exist then it is created.<br />
<br />
|- valign=&quot;top&quot;<br />
| '''--production'''<br />
| N/A<br />
| N/A<br />
| Indicates that the build is running in real production. That means that no mock emails will be sent. Instead, the contacts listed for each contribution will get emails when things go wrong.<br />
'''CAUTION: Use this option only if you are absolutely sure that you know what you are doing, especially when using models &quot;borrowed&quot; from other production builds without changing the emails first.'''<br />
<br />
|- valign=&quot;top&quot;<br />
| '''--emailFrom'''<br />
| &lt;email&gt;<br />
| Address of build master<br />
| Becomes the sender of the emails sent from the aggregator.<br />
<br />
|- valign=&quot;top&quot;<br />
| '''--emailFromName'''<br />
| &lt;name&gt;<br />
| If --emailFrom is set then this option sets the real name of the email sender.<br />
<br />
|- valign=&quot;top&quot;<br />
| '''--mockEmailTo'''<br />
| &lt;email&gt;<br />
| ''no value''<br />
| Becomes the receiver of the mock-emails sent from the aggregator. If not set, no mock emails are sent.<br />
<br />
|- valign=&quot;top&quot;<br />
| '''--mockEmailCC'''<br />
| &lt;email&gt;<br />
| ''no value''<br />
| Becomes the CC receiver of the mock-emails sent from the aggregator. If not set, no mock CC address is used.<br />
<br />
|- valign=&quot;top&quot;<br />
| '''--logURL'''<br />
| &lt;url&gt;<br />
| N/A<br />
| The URL that will be pasted into the emails. Should normally point to the a public URL for output log for the aggregator so that the receiver can browse the log for details on failures.<br />
<br />
|- valign=&quot;top&quot;<br />
| '''--logLevel'''<br />
| DEBUG<br />
<br />
INFO<br />
<br />
WARNING<br />
<br />
ERROR<br />
| INFO<br />
| Controls the verbosity of the console trace output. Defaults to global b3 settings.<br />
<br />
|- valign=&quot;top&quot;<br />
| '''--eclipseLogLevel'''<br />
| DEBUG<br />
<br />
INFO<br />
<br />
WARNING<br />
<br />
ERROR<br />
| INFO<br />
| Controls the verbosity of the eclipse log trace output. Defaults to global b3 settings.<br />
<br />
|- valign=&quot;top&quot;<br />
| '''--stacktrace'''<br />
| ---<br />
| ''no value''<br />
| Display stack trace on uncaught error.<br />
<br />
|- valign=&quot;top&quot;<br />
| '''--subjectPrefix'''<br />
| &lt;string&gt;<br />
| ?<br />
| The prefix to use for the subject when sending emails. Defaults to the label defined in the aggregation definition. The subject is formatted as: &quot;[&lt;subjectPrefix&gt;] Failed for build &lt;buildId&gt;&quot;<br />
<br />
|- valign=&quot;top&quot;<br />
| '''--smtpHost'''<br />
| &lt;host name&gt;<br />
| ''localhost''<br />
| The SMTP host to talk to when sending emails. Defaults to &quot;localhost&quot;.<br />
<br />
|- valign=&quot;top&quot;<br />
| '''--smtpPort'''<br />
| &lt;port number&gt;<br />
| ''25''<br />
| The SMTP port number to use when talking to the SMTP host. Default is 25.<br />
<br />
|- valign=&quot;top&quot;<br />
| '''--packedStrategy'''<br />
| COPY<br />
<br />
VERIFY<br />
<br />
UNPACK_AS_SIBLING<br />
<br />
UNPACK<br />
<br />
SKIP<br />
| ''value from the model''<br />
| ''Deprecated (Use only with on-the-fly transformation from deprecated build models)''<br />
Controls how mirroring is done of packed artifacts found in the source repository. Defaults to the setting in the aggregation definition.<br />
<br />
|- valign=&quot;top&quot;<br />
| '''--trustedContributions'''<br />
| &lt;comma separated list&gt;<br />
| ''no value''<br />
| ''Deprecated (Use only with on-the-fly transformation from deprecated build models)''<br />
A comma separated list of contributions with repositories that will be referenced directly (through a composite repository) rather than mirrored into the final repository (even if the repository is set to mirror artifacts by default).<br />
<br />
''Note: this option is mutually exclusive with option --mavenResult (see below)''<br />
<br />
|- valign=&quot;top&quot;<br />
| '''--validationContributions'''<br />
| &lt;comma separated list&gt;<br />
| ''no value''<br />
| ''Deprecated (Use only with on-the-fly transformation from deprecated build models)''<br />
A comma separated list of contributions with repositories that will be used for aggregation validation only rather than mirrored or referenced into the final repository.<br />
<br />
|- valign=&quot;top&quot;<br />
| '''--mavenResult'''<br />
| ---<br />
| ''no value''<br />
| ''Deprecated (Use only with on-the-fly transformation from deprecated build models)''<br />
Tells the aggregator to generate a hybrid repository that is compatible with p2 and maven2.<br />
''Note: this option is mutually exclusive with option --trustedContributions (see above)''<br />
<br />
|- valign=&quot;top&quot;<br />
| '''--mirrorReferences'''<br />
| ---<br />
| ''no value''<br />
| ''Deprecated (Use only with on-the-fly transformation from deprecated build models)''<br />
Mirror meta-data repository references from the contributed repositories<br />
<br />
|- valign=&quot;top&quot;<br />
| '''--referenceIncludePattern'''<br />
| &lt;regexp&gt;<br />
| ''no value''<br />
| ''Deprecated (Use only with on-the-fly transformation from deprecated build models)''<br />
Include only those references that matches the given regular expression pattern.<br />
<br />
|- valign=&quot;top&quot;<br />
| '''--referenceExcludePattern'''<br />
| &lt;regexp&gt;<br />
| ''no value''<br />
| ''Deprecated (Use only with on-the-fly transformation from deprecated build models)''<br />
Exclude all references that matches the given regular expression pattern. An exclusion takes precedence over an inclusion in case both patterns match a reference.<br />
|}<br />
<br />
==Hudson integration==<br />
Currently there is no support for Hudson.<br />
<br />
=Aggregation model components and specific actions=<br />
This section provides an in-depth description and reference of the Aggregation model, listing all model components, properties and available actions.<br />
<br />
==Global actions==<br />
The following aggregator-specific actions are available via the context menu that can be invoked on any node in the Aggregation model editor:<br />
*'''Clean Aggregation''' - cleans all traces of previous aggregations in the specified target location (''Build Root'')<br />
*'''Validate Aggregation''' - verifies model validity and resolves dependencies; no artifacts are copied or created<br />
*'''Build Aggregation''' - performs the aggregation and creates the aggregated repository in the target location (''Build Root'')<br />
*'''Clean then Build Aggregation''' - performs a ''Clean'' followed by a ''Build''<br />
<br />
==Aggregation==<br />
The root node of any aggregation model is the Aggregation node. It specifies a number of global properties including the ''Build Root'' (the target location of the aggregated repository) as well as the repo structure (maven-conformant or classic p2 setup). <br />
There are several child components some of which can be reference in other parts of the model: [[#Configuration|Configuration]], [[#Contact|Contact]],[[#Validation Set|Validation Set]], [[#Custom Category|Custom Category]], [[#Maven Mapping|Maven Mapping]].<br />
<br />
{| {{Greytable}}<br />
|-<br />
!Property<br />
!Value(s)<br />
!Default Value<br />
!Comment<br />
<br />
|- valign=&quot;top&quot;<br />
|Buildmaster<br />
| &lt;[[#Contact|Contact]]&gt;?<br />
| -<br />
| Specifies an optional build master that will be notified of progress and problems if sending of mail is enabled. This is a reference to any [[#Contact|Contact]] that has been added to this Aggregation model.<br />
<br />
|- valign=&quot;top&quot;<br />
|Build Root<br />
| &lt;urn&gt;<br />
| -<br />
| This is a required property specifying the target location of the aggregated repository.<br />
<br />
|- valign=&quot;top&quot;<br />
|Description<br />
| &lt;string&gt;<br />
| -<br />
| An optional description of the aggregated repository that will be shown when accessing the aggregated repository via the p2 update manager.<br />
<br />
|- valign=&quot;top&quot;<br />
|Label<br />
| &lt;string&gt;<br />
| -<br />
| A required label that will be used for the aggregated repository. This will be shown as the repo label when accessing the aggregated repository via the p2 update manager.<br />
<br />
|- valign=&quot;top&quot;<br />
|Maven Mappings<br />
| &lt;[[#Maven Mapping|Maven Mapping]]&gt;*<br />
| -<br />
| References [[#Maven Mapping|Maven Mapping]]s added as children to the Aggregation model root node. See [[#Maven Mapping|Maven Mapping]] for details.<br />
<br />
|- valign=&quot;top&quot;<br />
|Maven Result<br />
| '''true'''<br />
'''false'''<br />
| false<br />
| Controls the output structure of the aggregated repo. If '''true''', the aggregated repo will be Maven-conformant. Both the structure and meta-data of the aggregated repository will follow the conventions required by Maven. <br />
NOTE that due to the flexibility of p2 (separation of meta-data about dependencies and location of artifacts) the aggregated repo will at the same time also function as a valid p2 repository. <br />
<br />
|- valign=&quot;top&quot;<br />
|Packed Strategy<br />
| '''Copy'''<br />
'''Verify'''<br />
<br />
'''Unpack as Sibling'''<br />
<br />
'''Unpack'''<br />
<br />
'''Skip'''<br />
<br />
| Copy<br />
| This property controls how packed artifacts found in contributed repositories are handled when building the Aggregation:<br />
*'''Copy''' - if the source contains packed artifacts, copy and store them verbatim. No further action<br />
*'''Verify''' - same as ''copy'' but unpack the artifact and then discard the result<br />
*'''Unpack as Sibling''' - same as ''copy'' but unpack the artifact and store the result as a sibling<br />
*'''Unpack''' - use the packed artifact for data transfer but store it in unpacked form<br />
*'''Skip''' - do not consider packed artifacts. This option will require unpacked artifacts in the source<br />
<br />
|- valign=&quot;top&quot;<br />
|Sendmail<br />
| '''false'''<br />
'''true'''<br />
| false<br />
| Controls whether or not emails are sent when errors are detected during the aggregation process. A value of &lt;code&gt;false&lt;/code&gt; disables sending of emails (including mock emails).<br />
<br />
|- valign=&quot;top&quot;<br />
|Type<br />
| '''S'''<br />
'''I'''<br />
<br />
'''N'''<br />
<br />
'''M'''<br />
<br />
'''C'''<br />
<br />
'''R'''<br />
| S<br />
| Indicates the Aggregation type. This is an annotation merely for the benefit of the build master. It is not visible in the resulting repo.<br />
*'''S''' - stable<br />
*'''I''' - integration<br />
*'''N''' - nightly<br />
*'''M''' - milestone<br />
*'''C''' - continuous<br />
*'''R''' - release<br />
<br />
|}<br />
<br />
===Configuration===<br />
An Aggregation may have one or more Configuration definitions. The aggregated repo will be verified for all added configurations. If dependencies for any of the given configurations fails the aggregation as a whole fails. It is however possible to specify exceptions for individual [[#Contribution|Contribution]]s.<br />
<br />
A Configuration is a combination of the following properties:<br />
<br />
{| {{Greytable}}<br />
|-<br />
!Property<br />
!Value(s)<br />
!Default Value<br />
!Comment<br />
<br />
|- valign=&quot;top&quot;<br />
|Architecture<br />
|'''X86'''<br />
<br />
'''PPC'''<br />
<br />
'''X86_64'''<br />
<br />
'''IA64'''<br />
<br />
'''IA64_32'''<br />
<br />
'''Sparc'''<br />
| -<br />
|Specifies the architecture for which this configuration should be verified.<br />
<br />
|- valign=&quot;top&quot;<br />
|Enabled<br />
| '''true'''<br />
'''false'''<br />
| true<br />
| Disables (false) or enables (true) the configuration for the aggregation process.<br />
<br />
|- valign=&quot;top&quot;<br />
|Operating System<br />
|'''Win32'''<br />
<br />
'''Linux'''<br />
<br />
'''MacOSX'''<br />
<br />
'''AIX'''<br />
<br />
'''HPUX'''<br />
<br />
'''Solaris'''<br />
| -<br />
|Specifies the operating system for which this configuration should be verified.<br />
<br />
|- valign=&quot;top&quot;<br />
|Window System<br />
|'''Win32'''<br />
<br />
'''GTK'''<br />
<br />
'''Carbon'''<br />
<br />
'''Cocoa'''<br />
<br />
'''Motif'''<br />
| -<br />
|Specifies the windowing system for which this configuration should be verified.<br />
<br />
|}<br />
<br />
===Validation Set===<br />
The aggregator uses the p2 planner tool to determine what needs to be copied. The validation set determines the scope of one such planning session per valid configuration. This vouches for that everything that is contained within a validation set will be installable into the same target. Sometimes it is desirable to have more than one version of a feature in a repository even though multiple versions cannot be installed. This can be done using one validation set for each version.<br />
<br />
A validation set can extend other validation set and thereby provide a convenient way for sharing common things that multiple validation sets will make use of. An extended validation set will not be validated by its own. It will only be validated as part of the sets that extend it.<br />
<br />
A validation set can have two types of children: [[#Contribution|Contribution]] and [[#Validation Repository|Validation Repository]].<br />
<br />
Versions prior to 0.2.0 did not have the validation set node. Older b3aggr files will therefore be converted and given one validation set called ''main''<br />
<br />
{| {{Greytable}}<br />
|-<br />
!Property<br />
!Value(s)<br />
!Default Value<br />
!Comment<br />
<br />
|- valign=&quot;top&quot;<br />
|Description<br />
| &lt;string&gt;<br />
| -<br />
| An optional description of the validation set. For documentation purposes only.<br />
<br />
|- valign=&quot;top&quot;<br />
|Enabled<br />
| '''true'''<br />
'''false'''<br />
| true<br />
| Disables (false) or enables (true) the validation set to be considered in the aggregation process. Note that this may lead to missing dependencies and hence verification errors.<br />
<br />
|- valign=&quot;top&quot;<br />
<br />
|Extends<br />
| '''&lt;[[#Validation Set|Validation Set]]&gt;'''*<br />
| -<br />
| Zero or more references to [[#Validation Set|Validation Set]]s defined in the given Aggregation model that this validation set extends.<br />
<br />
|- valign=&quot;top&quot;<br />
|Label<br />
| &lt;string&gt;<br />
| -<br />
| Mandatory label for this validation set.<br />
|}<br />
<br />
===Contribution===<br />
Contributions are the key element of any aggregation. Contributions specify which repositories (or parts thereof (category, feature, product, IU)) to include, and the constraints controlling their inclusion in the aggregated repository. <br />
A contribution definition may consist of several [[#Mapped Repository|Mapped Repository]] and [[#Maven Mapping|Maven Mapping]] components.<br />
<br />
{| {{Greytable}}<br />
|-<br />
!Property<br />
!Value(s)<br />
!Default Value<br />
!Comment<br />
<br />
|- valign=&quot;top&quot;<br />
|Contacts<br />
| '''&lt;[[#Contact|Contact]]&gt;'''*<br />
| -<br />
| Zero or more references to [[#Contact|Contact]]s defined in the given Aggregation model. The referenced contacts will be notified if aggregation errors related to the contribution as a whole occur. <br />
<br />
|- valign=&quot;top&quot;<br />
|Description<br />
| &lt;string&gt;<br />
| -<br />
| Optional description of the contribution. This is for documentation purposes only and will not end up in the aggregated repository.<br />
<br />
|- valign=&quot;top&quot;<br />
|Enabled<br />
| '''true'''<br />
'''false'''<br />
| true<br />
| Disables (false) or enables (true) the contribution to be considered in the aggregation process. Note that this may lead to missing dependencies and hence verification errors.<br />
<br />
|- valign=&quot;top&quot;<br />
|Label<br />
| &lt;string&gt;<br />
| -<br />
| Mandatory label for this contribution.<br />
<br />
|- valign=&quot;top&quot;<br />
|Maven Mappings<br />
| '''&lt;[[#Maven Mapping|Maven Mapping]]&gt;'''*<br />
| -<br />
| See [[#Maven Mapping|Maven Mapping]] for details ...<br />
<br />
|}<br />
<br />
<br />
====Mapped Repository====<br />
A [[#Contribution|Contribution]] may define several Mapped Repositories defining the actual content of the contribution. The Aggregator provides fine-grained control over the contribution from each Mapped Repository through references to [[#Product|Product]]s, [[#Bundle|Bundle]]s, [[#Feature|Feature]]s, [[#Category|Categories]], [[#Exclusion Rule|Exclusion Rule]]s, [[#Valid Configuration Rule|Valid Configuration Rule]]s.<br />
<br />
{| {{Greytable}}<br />
|-<br />
!Property<br />
!Value(s)<br />
!Default Value<br />
!Comment<br />
<br />
|- valign=&quot;top&quot;<br />
|Category Prefix<br />
| &lt;string&gt;<br />
| -<br />
| A prefix added to the label of this repository when displayed in the p2 update manager. In the absence of custom categories this allows a useful grouping of repositories in an aggregated repository to be specified.<br />
<br />
|- valign=&quot;top&quot;<br />
|Description<br />
| &lt;string&gt;<br />
| -<br />
| Description of the Mapped Repository. For documentation purposes only.<br />
<br />
|- valign=&quot;top&quot;<br />
|Enabled<br />
| '''true'''<br />
'''false'''<br />
| true<br />
| Controls whether a Mapped Repository is considered as part of the Contribution. Setting this property to &lt;code&gt;false&lt;/code&gt; excludes the repository from the verification and aggregation process.<br />
<br />
|- valign=&quot;top&quot;<br />
|Location<br />
| &lt;URL&gt;<br />
| <br />
| This (required property) specifies the location of the repository that should be added to the enclosing Contribution.<br />
<br />
|- valign=&quot;top&quot;<br />
|Mirror Artifacts<br />
| '''true'''<br />
'''false'''<br />
| true<br />
| Controls whether the contents (artifacts) of the specified repository will be copied to the target location of the aggregated repository.<br />
<br />
|- valign=&quot;top&quot;<br />
|Nature<br />
| &lt;nature&gt;<br />
| p2<br />
| This specifies the nature of the repository, i.e. which loader should be used for loading the repository. The number of available repository loaders depends on installed extensions. By default, '''p2''' and '''maven2''' loaders are present in the installation.<br />
<br />
|}<br />
<br />
<br />
=====Product=====<br />
Defining Product components allows the addition of individual Eclipse products to the aggregation to be specified (as opposed to mapping the complete contents of a given [[#Mapped Repository|Mapped Repository]]. This naturally requires that products are present in the repositories being mapped.<br />
<br />
{| {{Greytable}}<br />
|-<br />
!Property<br />
!Value(s)<br />
!Default Value<br />
!Comment<br />
<br />
|- valign=&quot;top&quot;<br />
|Description<br />
| &lt;description&gt;<br />
| -<br />
| Optional description of the mapping.<br />
<br />
|- valign=&quot;top&quot;<br />
|Enabled<br />
| '''true'''<br />
'''false'''<br />
| true<br />
| Controls whether a Product is considered as part of the Contribution. Setting this property to &lt;code&gt;false&lt;/code&gt; excludes the product from the verification and aggregation process.<br />
<br />
|- valign=&quot;top&quot;<br />
|Name<br />
| &lt;product IU's id&gt;<br />
| -<br />
| The id of the product to be included in the aggregation. A drop-down of available names is provided.<br />
<br />
|- valign=&quot;top&quot;<br />
|Valid Configurations<br />
| &lt;[[#Configuration|Configuration]]&gt;'''*'''<br />
| -<br />
| References to zero or more configurations for which this product should be verified. If no references are given the product is verified for all [[#Configuration|Configuration]]s defined for the aggregation.<br />
<br />
|- valign=&quot;top&quot;<br />
|Version Range<br />
| &lt;version range&gt;<br />
| 0.0.0<br />
| A version range that specifies acceptable versions for this installable unit. A pop-up editor is available.<br />
<br />
|}<br />
<br />
=====Category=====<br />
Defining Category components allows the addition of the content in specific categories (provided by the contributed repository) rather than the complete contents of a given [[#Mapped Repository|Mapped Repository]]. <br />
<br />
{| {{Greytable}}<br />
|-<br />
!Property<br />
!Value(s)<br />
!Default Value<br />
!Comment<br />
<br />
|- valign=&quot;top&quot;<br />
|Description<br />
| &lt;description&gt;<br />
| ''no value''<br />
| Optional description of the mapping.<br />
<br />
|- valign=&quot;top&quot;<br />
|Enabled<br />
|'''true'''<br />
'''false'''<br />
| true<br />
| Controls whether a repository Category is considered as part of the Contribution. Setting this property to &lt;code&gt;false&lt;/code&gt; excludes the category from the verification and aggregation process.<br />
<br />
|- valign=&quot;top&quot;<br />
|Name<br />
| &lt;category IU id&gt;<br />
| -<br />
| The id of the category to be included in the aggregation. A drop-down of available names is provided. <br />
<br />
|- valign=&quot;top&quot;<br />
|Label Override<br />
| &lt;string&gt;<br />
| -<br />
| New category name used instead of the default name.<br />
<br />
|- valign=&quot;top&quot;<br />
|Valid Configurations<br />
| &lt;[[#Configuration|Configuration]]&gt;*<br />
| -<br />
| References to zero or more configurations for which the category contents should be verified. If no references are given the category is verified for all [[#Configuration|Configuration]]s defined for the aggregation.<br />
<br />
|- valign=&quot;top&quot;<br />
|Version Range<br />
| &lt;version range&gt;<br />
| 0.0.0<br />
| A version range that specifies acceptable versions for this installable unit. A pop-up editor is available.<br />
<br />
|}<br />
<br />
=====Bundle=====<br />
Defining Bundle components allows addition of individual Eclipse bundles to the aggregation to be specified (rather than the complete contents of a given [[#Mapped Repository|Mapped Repository]]). <br />
<br />
{| {{Greytable}}<br />
|-<br />
!Property<br />
!Value(s)<br />
!Default Value<br />
!Comment<br />
<br />
|- valign=&quot;top&quot;<br />
|Description<br />
| &lt;description&gt;<br />
| ''no value''<br />
| Optional description of the mapping.<br />
<br />
|- valign=&quot;top&quot;<br />
|Enabled<br />
|'''true'''<br />
'''false'''<br />
| true<br />
| Controls whether a referenced bundle is considered as part of the Contribution. Setting this property to &lt;code&gt;false&lt;/code&gt; excludes the bundle from the verification and aggregation process.<br />
<br />
|- valign=&quot;top&quot;<br />
|Name<br />
| &lt;bundle IU id&gt;<br />
| -<br />
| The id of the bundle to be included in the aggregation. A drop-down of available names is provided.<br />
<br />
|- valign=&quot;top&quot;<br />
|Valid Configurations<br />
|&lt;[[#Configuration|Configuration]]&gt;*<br />
| -<br />
| References to zero or more configurations for which the referenced bundle has to be verified. If no references are given the bundle has to be verified for all [[#Configuration|Configuration]]s defined for the aggregation.<br />
<br />
|- valign=&quot;top&quot;<br />
|Version Range<br />
| &lt;version range&gt;<br />
| 0.0.0<br />
| A version range that specifies acceptable versions for this installable unit. A pop-up editor is available.<br />
<br />
|}<br />
<br />
=====Feature=====<br />
Defining Feature components allows the addition of individual Eclipse features to the aggregation to be specified (rather than the complete contents of a given [[#Mapped Repository|Mapped Repository]]). The features to include must be present in the mapped repository.<br />
<br />
Furthermore, this component provides the means to group features implicitly into [[#Custom Category|Custom Categories]]. <br />
<br />
{| {{Greytable}}<br />
|-<br />
!Property<br />
!Value(s)<br />
!Default Value<br />
!Comment<br />
<br />
|- valign=&quot;top&quot;<br />
|Categories<br />
| &lt;[[#Custom Category|Custom Category]]&gt;*<br />
| -<br />
| Optionally references the [[#Custom Category|Custom Category]] definitions into which the feature should be placed upon aggregation. The relationship to the custom category is bi-directional so adding the feature to a custom category will update this property automatically in the [[#Custom Category|Custom Category]] definition, and vice versa. <br />
<br />
|- valign=&quot;top&quot;<br />
|Description<br />
| &lt;description&gt;<br />
| ''no value''<br />
| Optional description of the mapping.<br />
<br />
|- valign=&quot;top&quot;<br />
|Enabled<br />
|'''true'''<br />
'''false'''<br />
| true<br />
| Controls whether a referenced feature is considered as part of the Contribution. Setting this property to &lt;code&gt;false&lt;/code&gt; excludes the feature from the verification and aggregation process.<br />
<br />
|- valign=&quot;top&quot;<br />
|Name<br />
| &lt;feature IU id&gt;<br />
| -<br />
| The id of the feature to be included in the aggregation. A drop-down of available names is provided. <br />
<br />
|- valign=&quot;top&quot;<br />
|Valid Configurations<br />
| &lt;[[#Configuration|Configuration]]&gt;*<br />
| -<br />
| References to zero or more configurations for which the referenced feature should be verified. If no references are given the feature is verified for all [[#Configuration|Configuration]]s defined for the aggregation.<br />
<br />
|- valign=&quot;top&quot;<br />
|Version Range<br />
| &lt;version range&gt;<br />
| 0.0.0<br />
| A version range that specifies acceptable versions for this installable unit. A pop-up editor is available.<br />
<br />
|}<br />
<br />
=====Exclusion Rule=====<br />
The Exclusion Rules provides an alternative way to control the content of the aggregated repository. An exclusion rule may specify exclusion of any bundle, feature or product. The excluded IU will not be considered in the aggregation and verification process. Each exclusion rule can only reference one IU id.<br />
<br />
{| {{Greytable}}<br />
|-<br />
!Property<br />
!Value(s)<br />
!Default Value<br />
!Comment<br />
<br />
|- valign=&quot;top&quot;<br />
|Description<br />
| &lt;string&gt;<br />
| -<br />
| Description for documentation purposes.<br />
<br />
|- valign=&quot;top&quot;<br />
|Name<br />
| &lt;IU id&gt;<br />
| -<br />
| The id of the installable unit to be excluded from the aggregation. A drop-down of available names is provided.<br />
<br />
|- valign=&quot;top&quot;<br />
|Version Range<br />
| &lt;version range&gt;<br />
| 0.0.0<br />
| A version range that specifies versions of this IU to be excluded. A pop-up editor is available.<br />
<br />
|}<br />
<br />
=====Valid Configuration Rule=====<br />
By default all contributed contents of a [[#Mapped Repository|Mapped Repository]] will be verified for all [[#Configuration|Configuration]]s defined for the aggregation. A [[#Valid_Configuration_Rule|Valid Configuration Rule]] provides more control over validation. When using a Valid Configuration Rule, the referenced IUs (product, feature, or bundle) will only be verified and aggregated for the configurations specified in the rule. The rule only applies if the whole repository is mapped (i.e. when no explicit features, products, bundles or categories are mapped, regardless if they are enabled or disabled).<br />
<br />
{| {{Greytable}}<br />
|-<br />
!Property<br />
!Value(s)<br />
!Default Value<br />
!Comment<br />
<br />
|- valign=&quot;top&quot;<br />
|Description<br />
| &lt;string&gt;<br />
| -<br />
| Description for documentation purposes.<br />
<br />
|- valign=&quot;top&quot;<br />
|Name<br />
| &lt;IU id&gt;<br />
| -<br />
| The id of the IU to be included in the verification process. A drop-down of available names is provided.<br />
<br />
|- valign=&quot;top&quot;<br />
|Valid Configurations<br />
| &lt;[[#Configuration|Configuration]]&gt;*<br />
| -<br />
| References to one or more configurations for which the referenced IU should be verified. This implicitly excludes verification and aggregation for all other [[#Configuration|Configuration]]s defined as part of the aggregation model.<br />
<br />
|- valign=&quot;top&quot;<br />
|Version Range<br />
| &lt;version range&gt;<br />
| 0.0.0<br />
| A version range that specifies versions of this installable unit for which the rule should apply. A pop-up editor is available.<br />
<br />
|}<br />
<br />
====Maven Mapping (Contribution)====<br />
See [[#Maven Mapping|Maven Mapping]] for a detailed description and list of properties.<br />
<br />
===Contact===<br />
Defines a resuseable contact element which can be referenced in other parts of the model and may be used to send notifications about the aggregation process.<br />
<br />
{| {{Greytable}}<br />
|-<br />
!Property<br />
!Value(s)<br />
!Default Value<br />
!Comment<br />
<br />
|- valign=&quot;top&quot;<br />
|Email<br />
| &lt;email&gt;<br />
| -<br />
| The email to be used when notifying the contact.<br />
<br />
|- valign=&quot;top&quot;<br />
|Name<br />
| &lt;string&gt;<br />
| -<br />
| Full name of the contact. May be displayed as label when referenced in other parts of the model.<br />
<br />
|}<br />
<br />
===Custom Category===<br />
A Custom Category provides a grouping mechanism for features in the aggregated repository. A custom category can be referenced by [[#Feature|Feature]]s defined for inclusion from a [[#Mapped Repository|Mapped Repository]]. <br />
The relationship to between Custom Category and a [[#Feature|Feature]] is bi-directional. Thus, adding the feature to a custom category will update this property automatically in the [[#Feature|Feature]] definition, and vice versa. <br />
<br />
{| {{Greytable}}<br />
|-<br />
!Property<br />
!Value(s)<br />
!Default Value<br />
!Comment<br />
<br />
|- valign=&quot;top&quot;<br />
|Description<br />
| &lt;string&gt;<br />
| -<br />
| Description of the category as displayed when accessing the aggregated repository.<br />
<br />
|- valign=&quot;top&quot;<br />
|Features<br />
| &lt;[[#Feature|Feature]]&gt;*<br />
| -<br />
| [[#Feature|Feature]]s included in this category by reference.<br />
<br />
|- valign=&quot;top&quot;<br />
|Identifier<br />
| &lt;string&gt;<br />
| -<br />
| Category id. Required Eclipse category property. <br />
<br />
|- valign=&quot;top&quot;<br />
|Label<br />
| &lt;string&gt;<br />
| -<br />
| Label displayed for the category when accessing the aggregated repository via the p2 update manager.<br />
<br />
|}<br />
<br />
===Validation Repository===<br />
A Validation Repository is used to define that a repository should be used when validating dependencies for the aggregation but whose contents should not be included in the aggregated repository.<br />
It supports the cases where the objective is to create a repository that is not self sufficient, but rather a complement to something else (typical use case is an aggregation of everything produced by an organization with validation against the main Eclipse repository).<br />
<br />
{| {{Greytable}}<br />
|-<br />
!Property<br />
!Value(s)<br />
!Default Value<br />
!Comment<br />
<br />
|- valign=&quot;top&quot;<br />
|Enabled<br />
| '''true'''<br />
'''false'''<br />
| true<br />
| Controls whether a Validation Repository is considered during the verification and aggregation process. Setting this property to &lt;code&gt;false&lt;/code&gt; excludes the repository from the verification and aggregation process.<br />
<br />
|- valign=&quot;top&quot;<br />
|Location<br />
| &lt;URL&gt;<br />
| <br />
| Specifies the location of the repository.<br />
<br />
|- valign=&quot;top&quot;<br />
|Nature<br />
| &lt;nature&gt;<br />
| p2<br />
| This specifies the nature of the repository, i.e. which loader should be used for loading the repository. The number of available repository loaders depends on installed extensions. By default, '''p2''' and '''maven2''' loaders are present in the installation.<br />
<br />
|}<br />
<br />
===Maven Mapping===<br />
The Aggregator supports the creation of Maven-conformant repositories. A Maven repository requires a structure and use of naming conventions that may have to be achieved by a transformation of the Bundle-SymbolicName (BSN) when working with Eclipse bundles. There is a default translation from BSN naming standard to Maven naming. If that is not satisfactory, <br />
custom transformations are supported by the definition of one or more Maven Mappings which can be defined at the [[#Aggregator|Aggregator]] and the [[#Contribution|Contribution]] level. <br />
<br />
This only applies when the ''Maven Result'' property of the [[#Aggregator|Aggregator]] model is set to true. In that case all defined Maven Mappings are applied in the order in which they appear in the model starting from the most specific to the most generic. That means for each artifact that a [[#Contribution|Contribution]] adds to the aggregated repository:<br />
#first Maven Mappings defined as children of a [[#Contribution|Contribution]] are applied in the order in which they appear as children of the parent [[#Contribution|Contribution]] node<br />
#second Maven Mappings defined as children of the [[#Aggregator|Aggregator]] model are applied in the order in which they appear as children of the parent [[#Aggregator|Aggregator]] node<br />
#finally the default Maven Mapping is applied<br />
<br />
The most generic mapping is a default pattern that is applied whenever a Maven is created. It does not need to be added explicitly to the model. <br />
A mapping is specified using a regular expression that is applied to each BSN. The regular expression must specify two replacements; one for the maven groupId, and one for the maven artifactId. The group and artifact ids have an effect on the resulting Maven repo structure. The default pattern is:<br />
<br />
&lt;pre&gt;<br />
^([^.]+(?:\.[^.]+(?:\.[^.]+)?)?)(?:\.[^.]+)*$<br />
&lt;/pre&gt;<br />
<br />
The default maven mapping use the replacement &lt;code&gt;'''$1'''&lt;/code&gt; for groupId and &lt;code&gt;'''$0'''&lt;/code&gt; for artifactId. Hence, when applying the default maven mapping regular expression to a BSN, up to 3 segments (with dots as segment delimiters) are taken as the group id, and the entire BSN is taken as the artifact name. If this is a applied to something like &lt;code&gt;org.eclipse.b3.aggregator&lt;/code&gt; the groupId would be &lt;code&gt;org.eclipse.b3&lt;/code&gt; and the artifactId &lt;code&gt;org.eclipse.b3.aggregator&lt;/code&gt;. The resulting Maven repo will have the folder structure:<br />
<br />
&lt;pre&gt;<br />
org<br />
|<br />
eclipse<br />
|<br />
b3 <br />
|<br />
org.eclipse.b3.aggregator<br />
|<br />
&lt;folder name after version&gt;<br />
|<br />
org.eclipse.b3.aggregator-&lt;version&gt;.jar<br />
...<br />
&lt;/pre&gt;<br />
<br />
<br />
<br />
{| {{Greytable}}<br />
|-<br />
!Property<br />
!Value(s)<br />
!Default Value<br />
!Comment<br />
<br />
|- valign=&quot;top&quot;<br />
|Name Pattern<br />
| regex<br />
| -<br />
| A regular expression which is applied to the Bundle-SymbolicName (BSN). Pattern groups may be referenced in the replacement properties.<br />
<br />
|- valign=&quot;top&quot;<br />
|Group Id<br />
| &lt;string&gt; (may contain pattern group references (i.e. $1, ...))<br />
| -<br />
| Group Id applied in a maven mapping structure (groupId/artifactId). The Group Id replacement may contain pattern group references (i.e. $1, ...).<br />
<br />
|- valign=&quot;top&quot;<br />
|Artifact Id<br />
| &lt;string&gt; (may contain pattern group references (i.e. $1, ...))<br />
| -<br />
| Artifact Id applied in a maven mapping structure (groupId/artifactId). The Artifact Id replacement may contain pattern group references (i.e. $1, ...).<br />
<br />
|}<br />
<br />
=What else should be documented=<br />
<br />
# version editor (version formats...)<br />
# how enable/disable on the context menu works<br />
# drag&amp;drop support<br />
# 'available versions' tree<br />
# context menu actions (mapping IUs from repository view, searching for IUs from 'available version' tree...)<br />
# legacy format support (transformation wizard in the UI, on-the-fly transformation in the headless mode) - see [[Eclipse_b3/aggregator/Migration_From_buckminster]]<br />
<br />
==Questions==<br />
* How is blame-mail handled when running in the UI? Are the options &quot;production&quot; etc. available then?<br />
''When launched from IDE, only --buildModel and --action options are set (all other options have default values). Perhaps it's worth adding a launching dialog which would enable setting all options that are available in headless mode.''<br />
* How do you know what the &quot;log output url&quot; is? How can it be set?<br />
''You can, for example, redirect a copy of the console output to a publicly available resource (a text file served by a http server). The public URL should be passed in the --logURL option so that a link to it would appear in the informational email.''<br />
* Why is there a section that says &quot;there is no hudson support&quot; - is hudson support needed/required in any way??<br />
''The Hudson Support article was copied from the old buckminster documentation. It can be removed.''<br />
* Some configurations seems to be missing - or is the list open ended? (Sparc, Motif, etc..) - I assume user can put anything there? <br />
''Only listed configurations are supported (they are a part of the model). Adding an option means changing the model and creation of a new aggregator build.''<br />
* It seems that it is possible to load maven repositories. I suppose the result of aggregation is a valid p2 repository (or a combination of p2/maven)??<br />
''Yes, it is possible to load p2 and maven2 repositories by default (if someone adds a custom loader then he can load any type of repository). The output is always p2 compatible, optionally combined with maven2 (with no extensibility - at least now). However, if a maven2 repo is loaded and the result is also maven2 compatible, it is not identical to the original (not all attributes loaded from maven are stored in the p2 model).''<br />
<br />
[[Category:Eclipse b3]]</div>Stephane.bouchet.obeo.frhttp://wiki.eclipse.org/index.php?title=EMF_Compare/GMF_Notation_model_Comparison&diff=263755EMF Compare/GMF Notation model Comparison2011-08-05T12:34:27Z<p>Stephane.bouchet.obeo.fr: /* Implementation */</p>
<hr />
<div>The GMF diagram comparison task can be splitted into four parts. First, we must be able to compare GMF Notation models, then we have to know how we handle the link with the comparison of the semantic model (i.e. the elements represented by the diagram). Third, we have to know how to integrate existing GMF editor within the EMF Compare editor. Finally, we have to know how to create generic markers on the diagram to give a feedback of the computed differences to the user.<br />
<br />
== Notation model comparison ==<br />
<br />
Notation model comparison need its own MatchEngine and DiffEngine. The whole notation metamodel will not be taken into account. The difference computation will only occur on a subpart as depicted below:<br />
<br />
[[Image:gmf_notation_compare.png]]<br />
<br />
The nodes and edges will be matched by their XMI IDs. Containment between nodes will be handled in a generic way (i.e. by the super class GenericMatchEngine). <br />
<br />
Only following differences will be computed:<br />
<br />
* Addition / Removal of a node<br />
* Addition / Removal of an edge<br />
* Change of a Label on an edge or on a node<br />
* Move of a node within the diagram (with a configurable translation threshold for the move its location x/y).<br />
* Move of an edge within the diagram (total number of bendpoints, change of bendpoints - sourceX, sourceY, targetX, targetY - and positions of the anchors).<br />
<br />
== Link with the semantic comparison ==<br />
<br />
For many cases, we need the semantic comparison to be done before the graphical one. The work on logical model integration should give us this facility by computing the differences of a whole resource set instead of just the current resource containing the notation model.<br />
<br />
The link with the semantic comparison had to be provided for the labels. For each element , we have to get the text of the label and compare them. They are not stored directly into the notation model.<br />
<br />
Move operations of Edge and Node never correspond to semantic change.<br />
<br />
For addition and removal of nodes and edges, graphical differences may or may not corresponds to a semantic change. For instance, a graphical element may be removed because it has been hidden or deleted from the diagram. It does not correspond to a change in the semantic model. This graphical change does not have to be linked to a semantic change. In the other case, the addition or the removal of a node or an edge must match an addition or a deletion in the semantic model.<br />
<br />
=== Merge ===<br />
<br />
As a we don't know from the notation model how labels are build and from which feature(s) of the semantic model, the merge operation of labels modification must be applied on the notation model to trigger the appropriate underlying commands on the semantic model. This merger operation can be triggered only if the label is editable (=&gt; ask to the editpart of the view '''isEditModeEnabled()''')<br />
<br />
The merge of a move a node or an edge never triggers a merge on the semantic model, only on the graphical notation. The merge is a simple copy of values of bendpoints/layout constraints.<br />
<br />
Addition/Removal of node or edge trigger the merge of the semantic difference if it is associated to one, and the merge operation of the graphical difference otherwise. This merge operation consist of re-create the element if it has been deleted from the diagram, or to restor the hidden status of this view (View.isVisible())<br />
<br />
== Use of Difference Extensions and Hiding mechanism ==<br />
<br />
To detect the differences related to functional cases of diagram comparison, new kinds of differences (extensions) are created to complete the DiffModel.<br />
<br />
These extensions lean on the generic differences to be build and they are able to hide them.<br />
<br />
Here is the list of the generic differences which are managed and, for each of them, what are the extensions which are created and the differences which are hidden:<br />
<br />
* A '''ModelElementChangeLeftTarget''' difference, related to a ''View'', will involve the creation of a '''''DiagramModelElementChangeLeftTarget''''' difference extension. This extension will hide the '''ModelElementChangeLeftTarget''' input difference which was used to build it.<br />
<br />
* In the same way, a '''ModelElementChangeRightTarget''' difference, related to a ''View'', will involve the creation of a '''''DiagramModelElementChangeRightTarget''''' difference extension. This extension will hide the '''ModelElementChangeRightTarget''' input difference which was used to build it.<br />
<br />
* An '''UpdateAttribute''' on the ''EAttribute'' &quot;''View_visible''&quot;, where the right view is not visible and it is not a remotely change OR the right view is visible but it is a remotely change, will involve the creation of a '''''DiagramShowElement''''' difference extension. This one will hide the '''UpdateAttribute''' input difference which was used to build it.<br />
<br />
* In the same way, an '''UpdateAttribute''' on the ''EAttribute'' &quot;''View_visible''&quot;, where the left view is not visible and it is not a remotely change or the left view is visible but it is a remotely change, will involve the creation of a '''''DiagramHideElement''''' difference extension. This one will hide the '''UpdateAttribute''' input difference which was used to build it.<br />
<br />
* An '''UpdateAttribute''', where the container of its ''EAttribute'' is a ''Location'' and the related compared elements are not edges and the move is over the threshold specified in the page preferences, will involve the creation of a '''''DiagramMoveNode''''' difference extension. This extension will hide the '''UpdateAttribute''' input difference which was used to build it.<br />
<br />
* On each matched object, it is checked (in the same time as the attributes checking) if the GMF labels are different to create a '''''DiagramLabelChange''''' difference extension. This one hides no existing difference. To check the labels, the ''ITextAwareEditPart'' edit parts are retrieved and their GMF parser to get the print string and to compare them.<br />
<br />
* An '''UpdateAttribute''', where the container of its ''EAttribute'' is a ''RelativeBendpoints'' OR the ''EAttribute'' is ''IdentityAnchor_Id'', will involve the creation of a '''''DiagramEdgeChange''''' difference extension. Besides, an '''ModelElementChange''', where the related element is an ''IdentityAnchor'', will involve the creation of a '''''DiagramEdgeChange''''' difference extension too. For a same ''Edge'', it is possible to have several combined generic differences (several '''UpdateAttribute''' and '''ModelElementChange'''). To create only one extension for these ones, it is checked if there already exists a '''''DiagramEdgeChange''''' for this ''Edge'' in the building ''DiffModel''. This extension will hide the '''UpdateAttribute''' and/or '''ModelElementChange''' input differences which were used to build it.<br />
<br />
=== Mergers ===<br />
<br />
* For every difference extensions which lean on diagram changes only (no semantic changes), a single merger is used to merge these ones: ''DiagramDiffExtensionMerger''.<br />
It is the case of ''DiagramShowElement'', ''DiagramHideElement'', ''DiagramMoveNode'' and ''DiagramEdgeChange'' difference extensions. The merger retrieves all the hidden differences of the extension and call the related merger for each of them.<br />
<br />
* For ''DiagramLabelChange'', a ''DiagramlabelChangeMerger'' is used to set the new label from the GMF Command. This command allows to deploy changes on the semantic model.<br />
<br />
* For ''DiagramModelElementChangeLeftTarget'' and ''DiagramModelElementChangeRightTarget'', a respectively ''DiagramModelElementChangeLeftTargetMerger'' and ''DiagramModelElementChangeRightTargetMerger'' are used. They have the same behavior as ''DiagramDiffExtensionMerger'' unless for the merge of the delete of a ''View''. Indeed, for the add of a View, the generic merger is able to merge the ''View'' and the semantic object together. But, for the delete, it does not manage to merge the semantic difference. These 2 mergers retrieve the semantic difference to merge it before the merge of the delete of the View.<br />
<br />
== GMF editor integration within Comparison editor ==<br />
<br />
The integration of GMF editor within the comparison editor has to be done through specific contentMergeViewer (org.eclipse.compare.contentMergeViewers extension point) and maybe a specific structureMergerViewer (org.eclipse.compare.structureMergeViewers extension point) to provide the separation between graphical differences and semantic differences.<br />
<br />
The content merge viewer has to instantiate DiagramGraphicalViewer inside its '''createControls()''' method:<br />
<br />
viewer = new DiagramGraphicalViewer();<br />
viewer.createControl(composite);<br />
viewer.getControl().setBackground(ColorConstants.listBackground);<br />
<br />
The resize of the left/right/ancestor panes has to be handled gracefully like this:<br />
<br />
viewer_left.getControl().setBounds(x, y, leftWidth, height);<br />
viewer_right.getControl().setBounds(x + leftWidth + centerWidth, y, rightWidth, height);<br />
<br />
=== Initialization ===<br />
<br />
The left/right/ancestor viewers has to be initialized with a proper editing domain. This creation takes the resourceSet as input:<br />
<br />
DiagramEditingDomainFactory.getInstance().createEditingDomain(resourceset);<br />
<br />
Then, the viewers has to be configured like this: <br />
<br />
viewer.setEditDomain(new DefaultEditDomain(null)); // GEF editDomain<br />
viewer.setEditPartFactory(EditPartService.getInstance());<br />
viewer.setRootEditPart(new DiagramRootEditPart(diag.getMeasurementUnit()));<br />
viewer.setContents(diag); // the diagram from the notation model<br />
<br />
It is also possible to make the viewer uneditable by browsing all children of the rootEditPart of each viewer, but then, we will not be able to ask for the '''editability''' of views. It should be better to add a top layer that forbid the editing.<br />
<br />
== Markers for GMF diagrams ==<br />
<br />
Difference marker on notation model are provided by using the '''org.eclipse.gmf.runtime.diagram.ui.decoratorProviders''' extension point.<br />
<br />
The provided IDecoratorProvider will create a decorator based on the proposed IDecoratorTarget. This IDecoratorTarget can be adapted to a Notation View like this :<br />
<br />
View view = (View) decoratorTarget.getAdapter(View.class);<br />
<br />
The decorator should be created if, and only if, there is a graphical difference associated with the given View. The graphical difference model will be retrieved from the owning EditPart.<br />
<br />
Provided decorators has to implement IDecorator interface. <br />
<br />
The issue with specific decorator is to define the locator. Each Figure has its own bounds and we will start from the assumption that:<br />
<br />
* Marker of decorated figure will be rectangle following their bounds (smallest rectangle completely enclosing the IFigure)<br />
* Marker of decorated edges will be handled for polylines only and bounds of the decoration will be the bounds of the decorated<br />
* Marker of move will be an icon (picture not yet defined) located:<br />
** in the middle of the edge if the edge has moved<br />
** in the top right of the bounds of the figure if it is a node.<br />
<br />
See samples of first annotation prototypes (on Ecore diagram):<br />
<br />
Class added:<br />
[[Image:markedAdded.png]]<br />
<br />
Class removed:<br />
[[Image:markedRemoved.png]]<br />
<br />
Label of class changed:<br />
[[Image:markedLabel.png]]<br />
<br />
Edge marked (added)<br />
[[Image:markedEdge.png]]<br />
<br />
Edge marked (moved)<br />
[[Image:markedMovedEdge.png]]<br />
<br />
=== Implementation ===<br />
<br />
Here are some screenshots of the current development under the ericsson_integration branch of the following repository https://github.com/mbarbero/emfcompare <br />
<br />
{| cellspacing=&quot;1&quot; cellpadding=&quot;1&quot; border=&quot;1&quot;<br />
|-<br />
! align=&quot;center&quot;| Description<br />
! align=&quot;center&quot;| State<br />
! align=&quot;center&quot;| Screenshot<br />
|-<br />
| Added nodes<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC1.png|thumb]]<br />
|-<br />
| Deleted nodes<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC2.png|thumb]]<br />
|-<br />
| Mix of added and deleted nodes<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC3.png|thumb]]<br />
|-<br />
| Added node inside a node<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC04.png|thumb]]<br />
|-<br />
| Removed node inside a node<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC05.png|thumb]]<br />
|-<br />
| Moved node<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC6.png|thumb]]<br />
| [[Image:preference.png|thumb|A move threshold can be set in the preference page to detect this change]]<br />
|-<br />
| Modified bounds of a node<br />
! style=&quot;color:red&quot; | ko<br />
| [[Image:TC7.png|thumb|not implemented]]<br />
|-<br />
| Hidden node<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC09.png|thumb]]<br />
|-<br />
| Revealed node<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC08.png|thumb]]<br />
|-<br />
| Modified label<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC10.png|thumb]]<br />
|-<br />
| Added label<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC11.png|thumb]]<br />
|-<br />
| Removed label<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC12.png|thumb]]<br />
|-<br />
| Mix of added and removed label<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC13.png|thumb]]<br />
|-<br />
| Hidden label<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC15.png|thumb]]<br />
|-<br />
| Revealed label<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC14.png|thumb]]<br />
|-<br />
| Modified label<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC16.png|thumb]]<br />
|-<br />
| Modified label<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC17.png|thumb]]<br />
|-<br />
| Added edge<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC18.png|thumb|no highlight on labels]]<br />
|-<br />
| Removed edge<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC19.png|thumb|no highlight on labels]]<br />
|-<br />
| Mix of added and removed edges<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC20.png|thumb|no highlight on labels]]<br />
|-<br />
| Moved edge<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC21.png|thumb]]<br />
|-<br />
| Modified edge label<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC23.png|thumb]]<br />
|-<br />
| Modified edge label<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC24.png|thumb]]<br />
|-<br />
| Revealed edge<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC25.png|thumb]]<br />
|-<br />
| Hidden edge<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC26.png|thumb]]<br />
|-<br />
| Revealed edge label<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC27.png|thumb]]<br />
|-<br />
| Hidden edge label<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC28.png|thumb]]<br />
|-<br />
| Removed node with edge<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC29.png|thumb| no highlight on labels]]<br />
|-<br />
| Removed node with edge ( delete from diagram )<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC30.png|thumb| no highlight on labels]]<br />
|-<br />
| Removed edge ( delete from diagram )<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC31.png|thumb| no highlight on labels]]<br />
|-<br />
| 3 WAY ; added node<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC32.png|thumb]]<br />
|-<br />
| 3 WAY ; removed node<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC33.png|thumb]]<br />
|-<br />
| 3 WAY ; moved node (remote)<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC34.png|thumb | both nodes are marked]]<br />
|-<br />
| 3 WAY ; moved node (local)<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC35.png|thumb | both nodes are marked]]<br />
|-<br />
| 3 WAY ; modified label<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC36.png|thumb]]<br />
|-<br />
| 3 WAY ; remotely hidden node<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC37.png|thumb]]<br />
|-<br />
| 3 WAY ; locally hidden node<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC38.png|thumb]]<br />
|-<br />
| Multiple diagram ; Added node in sub-diagram<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC50.png|thumb]]<br />
|-<br />
| Multiple diagram ; Removed node in sub-diagram<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC51.png|thumb]]<br />
|-<br />
| Multiple diagram ; Mix of Added and Removed node in sub-diagram<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC52.png|thumb]]<br />
<br />
|}</div>Stephane.bouchet.obeo.frhttp://wiki.eclipse.org/index.php?title=File:TC38.png&diff=263754File:TC38.png2011-08-05T12:31:39Z<p>Stephane.bouchet.obeo.fr: uploaded a new version of &quot;Image:TC38.png&quot;</p>
<hr />
<div></div>Stephane.bouchet.obeo.frhttp://wiki.eclipse.org/index.php?title=File:TC37.png&diff=263753File:TC37.png2011-08-05T12:31:19Z<p>Stephane.bouchet.obeo.fr: uploaded a new version of &quot;Image:TC37.png&quot;</p>
<hr />
<div></div>Stephane.bouchet.obeo.frhttp://wiki.eclipse.org/index.php?title=File:TC52.png&diff=263548File:TC52.png2011-08-03T14:18:20Z<p>Stephane.bouchet.obeo.fr: </p>
<hr />
<div></div>Stephane.bouchet.obeo.frhttp://wiki.eclipse.org/index.php?title=File:TC51.png&diff=263547File:TC51.png2011-08-03T14:18:08Z<p>Stephane.bouchet.obeo.fr: </p>
<hr />
<div></div>Stephane.bouchet.obeo.frhttp://wiki.eclipse.org/index.php?title=File:TC35.png&diff=263546File:TC35.png2011-08-03T14:17:55Z<p>Stephane.bouchet.obeo.fr: </p>
<hr />
<div></div>Stephane.bouchet.obeo.frhttp://wiki.eclipse.org/index.php?title=File:TC34.png&diff=263545File:TC34.png2011-08-03T14:17:44Z<p>Stephane.bouchet.obeo.fr: </p>
<hr />
<div></div>Stephane.bouchet.obeo.frhttp://wiki.eclipse.org/index.php?title=File:TC50.png&diff=263544File:TC50.png2011-08-03T14:17:26Z<p>Stephane.bouchet.obeo.fr: </p>
<hr />
<div></div>Stephane.bouchet.obeo.frhttp://wiki.eclipse.org/index.php?title=EMF_Compare/GMF_Notation_model_Comparison&diff=263543EMF Compare/GMF Notation model Comparison2011-08-03T14:17:14Z<p>Stephane.bouchet.obeo.fr: /* Implementation */</p>
<hr />
<div>The GMF diagram comparison task can be splitted into four parts. First, we must be able to compare GMF Notation models, then we have to know how we handle the link with the comparison of the semantic model (i.e. the elements represented by the diagram). Third, we have to know how to integrate existing GMF editor within the EMF Compare editor. Finally, we have to know how to create generic markers on the diagram to give a feedback of the computed differences to the user.<br />
<br />
== Notation model comparison ==<br />
<br />
Notation model comparison need its own MatchEngine and DiffEngine. The whole notation metamodel will not be taken into account. The difference computation will only occur on a subpart as depicted below:<br />
<br />
[[Image:gmf_notation_compare.png]]<br />
<br />
The nodes and edges will be matched by their XMI IDs. Containment between nodes will be handled in a generic way (i.e. by the super class GenericMatchEngine). <br />
<br />
Only following differences will be computed:<br />
<br />
* Addition / Removal of a node<br />
* Addition / Removal of an edge<br />
* Change of a Label on an edge or on a node<br />
* Move of a node within the diagram (with a configurable translation threshold for the move its location x/y).<br />
* Move of an edge within the diagram (total number of bendpoints, change of bendpoints - sourceX, sourceY, targetX, targetY - and positions of the anchors).<br />
<br />
== Link with the semantic comparison ==<br />
<br />
For many cases, we need the semantic comparison to be done before the graphical one. The work on logical model integration should give us this facility by computing the differences of a whole resource set instead of just the current resource containing the notation model.<br />
<br />
The link with the semantic comparison had to be provided for the labels. For each element , we have to get the text of the label and compare them. They are not stored directly into the notation model.<br />
<br />
Move operations of Edge and Node never correspond to semantic change.<br />
<br />
For addition and removal of nodes and edges, graphical differences may or may not corresponds to a semantic change. For instance, a graphical element may be removed because it has been hidden or deleted from the diagram. It does not correspond to a change in the semantic model. This graphical change does not have to be linked to a semantic change. In the other case, the addition or the removal of a node or an edge must match an addition or a deletion in the semantic model.<br />
<br />
=== Merge ===<br />
<br />
As a we don't know from the notation model how labels are build and from which feature(s) of the semantic model, the merge operation of labels modification must be applied on the notation model to trigger the appropriate underlying commands on the semantic model. This merger operation can be triggered only if the label is editable (=&gt; ask to the editpart of the view '''isEditModeEnabled()''')<br />
<br />
The merge of a move a node or an edge never triggers a merge on the semantic model, only on the graphical notation. The merge is a simple copy of values of bendpoints/layout constraints.<br />
<br />
Addition/Removal of node or edge trigger the merge of the semantic difference if it is associated to one, and the merge operation of the graphical difference otherwise. This merge operation consist of re-create the element if it has been deleted from the diagram, or to restor the hidden status of this view (View.isVisible())<br />
<br />
== GMF editor integration within Comparison editor ==<br />
<br />
The integration of GMF editor within the comparison editor has to be done through specific contentMergeViewer (org.eclipse.compare.contentMergeViewers extension point) and maybe a specific structureMergerViewer (org.eclipse.compare.structureMergeViewers extension point) to provide the separation between graphical differences and semantic differences.<br />
<br />
The content merge viewer has to instantiate DiagramGraphicalViewer inside its '''createControls()''' method:<br />
<br />
viewer = new DiagramGraphicalViewer();<br />
viewer.createControl(composite);<br />
viewer.getControl().setBackground(ColorConstants.listBackground);<br />
<br />
The resize of the left/right/ancestor panes has to be handled gracefully like this:<br />
<br />
viewer_left.getControl().setBounds(x, y, leftWidth, height);<br />
viewer_right.getControl().setBounds(x + leftWidth + centerWidth, y, rightWidth, height);<br />
<br />
=== Initialization ===<br />
<br />
The left/right/ancestor viewers has to be initialized with a proper editing domain. This creation takes the resourceSet as input:<br />
<br />
DiagramEditingDomainFactory.getInstance().createEditingDomain(resourceset);<br />
<br />
Then, the viewers has to be configured like this: <br />
<br />
viewer.setEditDomain(new DefaultEditDomain(null)); // GEF editDomain<br />
viewer.setEditPartFactory(EditPartService.getInstance());<br />
viewer.setRootEditPart(new DiagramRootEditPart(diag.getMeasurementUnit()));<br />
viewer.setContents(diag); // the diagram from the notation model<br />
<br />
It is also possible to make the viewer uneditable by browsing all children of the rootEditPart of each viewer, but then, we will not be able to ask for the '''editability''' of views. It should be better to add a top layer that forbid the editing.<br />
<br />
== Markers for GMF diagrams ==<br />
<br />
Difference marker on notation model are provided by using the '''org.eclipse.gmf.runtime.diagram.ui.decoratorProviders''' extension point.<br />
<br />
The provided IDecoratorProvider will create a decorator based on the proposed IDecoratorTarget. This IDecoratorTarget can be adapted to a Notation View like this :<br />
<br />
View view = (View) decoratorTarget.getAdapter(View.class);<br />
<br />
The decorator should be created if, and only if, there is a graphical difference associated with the given View. The graphical difference model will be retrieved from the owning EditPart.<br />
<br />
Provided decorators has to implement IDecorator interface. <br />
<br />
The issue with specific decorator is to define the locator. Each Figure has its own bounds and we will start from the assumption that:<br />
<br />
* Marker of decorated figure will be rectangle following their bounds (smallest rectangle completely enclosing the IFigure)<br />
* Marker of decorated edges will be handled for polylines only and bounds of the decoration will be the bounds of the decorated<br />
* Marker of move will be an icon (picture not yet defined) located:<br />
** in the middle of the edge if the edge has moved<br />
** in the top right of the bounds of the figure if it is a node.<br />
<br />
See samples of first annotation prototypes (on Ecore diagram):<br />
<br />
Class added:<br />
[[Image:markedAdded.png]]<br />
<br />
Class removed:<br />
[[Image:markedRemoved.png]]<br />
<br />
Label of class changed:<br />
[[Image:markedLabel.png]]<br />
<br />
Edge marked (added)<br />
[[Image:markedEdge.png]]<br />
<br />
Edge marked (moved)<br />
[[Image:markedMovedEdge.png]]<br />
<br />
=== Implementation ===<br />
<br />
Here are some screenshots of the current development under the ericsson_integration branch of the following repository https://github.com/mbarbero/emfcompare <br />
<br />
{| cellspacing=&quot;1&quot; cellpadding=&quot;1&quot; border=&quot;1&quot;<br />
|-<br />
! align=&quot;center&quot;| Description<br />
! align=&quot;center&quot;| State<br />
! align=&quot;center&quot;| Screenshot<br />
|-<br />
| Added nodes<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC1.png|thumb]]<br />
|-<br />
| Deleted nodes<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC2.png|thumb]]<br />
|-<br />
| Mix of added and deleted nodes<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC3.png|thumb]]<br />
|-<br />
| Added node inside a node<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC04.png|thumb]]<br />
|-<br />
| Removed node inside a node<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC05.png|thumb]]<br />
|-<br />
| Moved node<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC6.png|thumb]]<br />
|-<br />
| Modified bounds of a node<br />
! style=&quot;color:red&quot; | ko<br />
| [[Image:TC7.png|thumb|not implemented]]<br />
|-<br />
| Hidden node<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC09.png|thumb]]<br />
|-<br />
| Revealed node<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC08.png|thumb]]<br />
|-<br />
| Modified label<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC10.png|thumb]]<br />
|-<br />
| Added label<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC11.png|thumb]]<br />
|-<br />
| Removed label<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC12.png|thumb]]<br />
|-<br />
| Mix of added and removed label<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC13.png|thumb]]<br />
|-<br />
| Hidden label<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC15.png|thumb]]<br />
|-<br />
| Revealed label<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC14.png|thumb]]<br />
|-<br />
| Modified label<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC16.png|thumb]]<br />
|-<br />
| Modified label<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC17.png|thumb]]<br />
|-<br />
| Added edge<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC18.png|thumb|no highlight on labels]]<br />
|-<br />
| Removed edge<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC19.png|thumb|no highlight on labels]]<br />
|-<br />
| Mix of added and removed edges<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC20.png|thumb|no highlight on labels]]<br />
|-<br />
| Moved edge<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC21.png|thumb]]<br />
|-<br />
| Modified edge label<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC23.png|thumb]]<br />
|-<br />
| Modified edge label<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC24.png|thumb]]<br />
|-<br />
| Revealed edge<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC25.png|thumb]]<br />
|-<br />
| Hidden edge<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC26.png|thumb]]<br />
|-<br />
| Revealed edge label<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC27.png|thumb]]<br />
|-<br />
| Hidden edge label<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC28.png|thumb]]<br />
|-<br />
| Removed node with edge<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC29.png|thumb| no highlight on labels]]<br />
|-<br />
| Removed node with edge ( delete from diagram )<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC30.png|thumb| no highlight on labels]]<br />
|-<br />
| Removed edge ( delete from diagram )<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC31.png|thumb| no highlight on labels]]<br />
|-<br />
| 3 WAY ; added node<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC32.png|thumb]]<br />
|-<br />
| 3 WAY ; removed node<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC33.png|thumb]]<br />
|-<br />
| 3 WAY ; moved node (remote)<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC34.png|thumb | both nodes are marked]]<br />
|-<br />
| 3 WAY ; moved node (local)<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC35.png|thumb | both nodes are marked]]<br />
|-<br />
| 3 WAY ; modified label<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC36.png|thumb]]<br />
|-<br />
| Multiple diagram ; Added node in sub-diagram<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC50.png|thumb]]<br />
|-<br />
| Multiple diagram ; Removed node in sub-diagram<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC51.png|thumb]]<br />
|-<br />
| Multiple diagram ; Mix of Added and Removed node in sub-diagram<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC52.png|thumb]]<br />
<br />
|}</div>Stephane.bouchet.obeo.frhttp://wiki.eclipse.org/index.php?title=File:TC32.png&diff=263536File:TC32.png2011-08-03T13:25:13Z<p>Stephane.bouchet.obeo.fr: uploaded a new version of &quot;Image:TC32.png&quot;</p>
<hr />
<div></div>Stephane.bouchet.obeo.frhttp://wiki.eclipse.org/index.php?title=File:TC33.png&diff=263535File:TC33.png2011-08-03T13:24:35Z<p>Stephane.bouchet.obeo.fr: uploaded a new version of &quot;Image:TC33.png&quot;</p>
<hr />
<div></div>Stephane.bouchet.obeo.frhttp://wiki.eclipse.org/index.php?title=EMF_Compare/GMF_Notation_model_Comparison&diff=263525EMF Compare/GMF Notation model Comparison2011-08-03T10:08:38Z<p>Stephane.bouchet.obeo.fr: /* Implementation */</p>
<hr />
<div>The GMF diagram comparison task can be splitted into four parts. First, we must be able to compare GMF Notation models, then we have to know how we handle the link with the comparison of the semantic model (i.e. the elements represented by the diagram). Third, we have to know how to integrate existing GMF editor within the EMF Compare editor. Finally, we have to know how to create generic markers on the diagram to give a feedback of the computed differences to the user.<br />
<br />
== Notation model comparison ==<br />
<br />
Notation model comparison need its own MatchEngine and DiffEngine. The whole notation metamodel will not be taken into account. The difference computation will only occur on a subpart as depicted below:<br />
<br />
[[Image:gmf_notation_compare.png]]<br />
<br />
The nodes and edges will be matched by their XMI IDs. Containment between nodes will be handled in a generic way (i.e. by the super class GenericMatchEngine). <br />
<br />
Only following differences will be computed:<br />
<br />
* Addition / Removal of a node<br />
* Addition / Removal of an edge<br />
* Change of a Label on an edge or on a node<br />
* Move of a node within the diagram (with a configurable translation threshold for the move its location x/y).<br />
* Move of an edge within the diagram (total number of bendpoints, change of bendpoints - sourceX, sourceY, targetX, targetY - and positions of the anchors).<br />
<br />
== Link with the semantic comparison ==<br />
<br />
For many cases, we need the semantic comparison to be done before the graphical one. The work on logical model integration should give us this facility by computing the differences of a whole resource set instead of just the current resource containing the notation model.<br />
<br />
The link with the semantic comparison had to be provided for the labels. For each element , we have to get the text of the label and compare them. They are not stored directly into the notation model.<br />
<br />
Move operations of Edge and Node never correspond to semantic change.<br />
<br />
For addition and removal of nodes and edges, graphical differences may or may not corresponds to a semantic change. For instance, a graphical element may be removed because it has been hidden or deleted from the diagram. It does not correspond to a change in the semantic model. This graphical change does not have to be linked to a semantic change. In the other case, the addition or the removal of a node or an edge must match an addition or a deletion in the semantic model.<br />
<br />
=== Merge ===<br />
<br />
As a we don't know from the notation model how labels are build and from which feature(s) of the semantic model, the merge operation of labels modification must be applied on the notation model to trigger the appropriate underlying commands on the semantic model. This merger operation can be triggered only if the label is editable (=&gt; ask to the editpart of the view '''isEditModeEnabled()''')<br />
<br />
The merge of a move a node or an edge never triggers a merge on the semantic model, only on the graphical notation. The merge is a simple copy of values of bendpoints/layout constraints.<br />
<br />
Addition/Removal of node or edge trigger the merge of the semantic difference if it is associated to one, and the merge operation of the graphical difference otherwise. This merge operation consist of re-create the element if it has been deleted from the diagram, or to restor the hidden status of this view (View.isVisible())<br />
<br />
== GMF editor integration within Comparison editor ==<br />
<br />
The integration of GMF editor within the comparison editor has to be done through specific contentMergeViewer (org.eclipse.compare.contentMergeViewers extension point) and maybe a specific structureMergerViewer (org.eclipse.compare.structureMergeViewers extension point) to provide the separation between graphical differences and semantic differences.<br />
<br />
The content merge viewer has to instantiate DiagramGraphicalViewer inside its '''createControls()''' method:<br />
<br />
viewer = new DiagramGraphicalViewer();<br />
viewer.createControl(composite);<br />
viewer.getControl().setBackground(ColorConstants.listBackground);<br />
<br />
The resize of the left/right/ancestor panes has to be handled gracefully like this:<br />
<br />
viewer_left.getControl().setBounds(x, y, leftWidth, height);<br />
viewer_right.getControl().setBounds(x + leftWidth + centerWidth, y, rightWidth, height);<br />
<br />
=== Initialization ===<br />
<br />
The left/right/ancestor viewers has to be initialized with a proper editing domain. This creation takes the resourceSet as input:<br />
<br />
DiagramEditingDomainFactory.getInstance().createEditingDomain(resourceset);<br />
<br />
Then, the viewers has to be configured like this: <br />
<br />
viewer.setEditDomain(new DefaultEditDomain(null)); // GEF editDomain<br />
viewer.setEditPartFactory(EditPartService.getInstance());<br />
viewer.setRootEditPart(new DiagramRootEditPart(diag.getMeasurementUnit()));<br />
viewer.setContents(diag); // the diagram from the notation model<br />
<br />
It is also possible to make the viewer uneditable by browsing all children of the rootEditPart of each viewer, but then, we will not be able to ask for the '''editability''' of views. It should be better to add a top layer that forbid the editing.<br />
<br />
== Markers for GMF diagrams ==<br />
<br />
Difference marker on notation model are provided by using the '''org.eclipse.gmf.runtime.diagram.ui.decoratorProviders''' extension point.<br />
<br />
The provided IDecoratorProvider will create a decorator based on the proposed IDecoratorTarget. This IDecoratorTarget can be adapted to a Notation View like this :<br />
<br />
View view = (View) decoratorTarget.getAdapter(View.class);<br />
<br />
The decorator should be created if, and only if, there is a graphical difference associated with the given View. The graphical difference model will be retrieved from the owning EditPart.<br />
<br />
Provided decorators has to implement IDecorator interface. <br />
<br />
The issue with specific decorator is to define the locator. Each Figure has its own bounds and we will start from the assumption that:<br />
<br />
* Marker of decorated figure will be rectangle following their bounds (smallest rectangle completely enclosing the IFigure)<br />
* Marker of decorated edges will be handled for polylines only and bounds of the decoration will be the bounds of the decorated<br />
* Marker of move will be an icon (picture not yet defined) located:<br />
** in the middle of the edge if the edge has moved<br />
** in the top right of the bounds of the figure if it is a node.<br />
<br />
See samples of first annotation prototypes (on Ecore diagram):<br />
<br />
Class added:<br />
[[Image:markedAdded.png]]<br />
<br />
Class removed:<br />
[[Image:markedRemoved.png]]<br />
<br />
Label of class changed:<br />
[[Image:markedLabel.png]]<br />
<br />
Edge marked (added)<br />
[[Image:markedEdge.png]]<br />
<br />
Edge marked (moved)<br />
[[Image:markedMovedEdge.png]]<br />
<br />
=== Implementation ===<br />
<br />
Here are some screenshots of the current development under the ericsson_integration branch of the following repository https://github.com/mbarbero/emfcompare <br />
<br />
{| cellspacing=&quot;1&quot; cellpadding=&quot;1&quot; border=&quot;1&quot;<br />
|-<br />
! align=&quot;center&quot;| Description<br />
! align=&quot;center&quot;| State<br />
! align=&quot;center&quot;| Screenshot<br />
|-<br />
| Added nodes<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC1.png|thumb]]<br />
|-<br />
| Deleted nodes<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC2.png|thumb]]<br />
|-<br />
| Mix of added and deleted nodes<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC3.png|thumb]]<br />
|-<br />
| Added node inside a node<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC04.png|thumb]]<br />
|-<br />
| Removed node inside a node<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC05.png|thumb]]<br />
|-<br />
| Moved node<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC6.png|thumb]]<br />
|-<br />
| Modified bounds of a node<br />
! style=&quot;color:red&quot; | ko<br />
| [[Image:TC7.png|thumb|not implemented]]<br />
|-<br />
| Hidden node<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC09.png|thumb]]<br />
|-<br />
| Revealed node<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC08.png|thumb]]<br />
|-<br />
| Modified label<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC10.png|thumb]]<br />
|-<br />
| Added label<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC11.png|thumb]]<br />
|-<br />
| Removed label<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC12.png|thumb]]<br />
|-<br />
| Mix of added and removed label<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC13.png|thumb]]<br />
|-<br />
| Hidden label<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC15.png|thumb]]<br />
|-<br />
| Revealed label<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC14.png|thumb]]<br />
|-<br />
| Modified label<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC16.png|thumb]]<br />
|-<br />
| Modified label<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC17.png|thumb]]<br />
|-<br />
| Added edge<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC18.png|thumb|no highlight on labels]]<br />
|-<br />
| Removed edge<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC19.png|thumb|no highlight on labels]]<br />
|-<br />
| Mix of added and removed edges<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC20.png|thumb|no highlight on labels]]<br />
|-<br />
| Moved edge<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC21.png|thumb]]<br />
|-<br />
| Modified edge label<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC23.png|thumb]]<br />
|-<br />
| Modified edge label<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC24.png|thumb]]<br />
|-<br />
| Revealed edge<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC25.png|thumb]]<br />
|-<br />
| Hidden edge<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC26.png|thumb]]<br />
|-<br />
| Revealed edge label<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC27.png|thumb]]<br />
|-<br />
| Hidden edge label<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC28.png|thumb]]<br />
|-<br />
| Removed node with edge<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC29.png|thumb| no highlight on labels]]<br />
|-<br />
| Removed node with edge ( delete from diagram )<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC30.png|thumb| no highlight on labels]]<br />
|-<br />
| Removed edge ( delete from diagram )<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC31.png|thumb| no highlight on labels]]<br />
|-<br />
| 3 WAY ; added node<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC32.png|thumb]]<br />
|-<br />
| 3 WAY ; removed node<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC33.png|thumb]]<br />
|-<br />
| 3 WAY ; moved node (remote)<br />
! style=&quot;color:red&quot; | ko<br />
| [[Image:TC34.png|thumb | both nodes are marked]]<br />
|-<br />
| 3 WAY ; moved node (local)<br />
! style=&quot;color:red&quot; | ko<br />
| [[Image:TC35.png|thumb | both nodes are marked]]<br />
|-<br />
| 3 WAY ; modified label<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC36.png|thumb]]<br />
|-<br />
| Multiple diagram ; Added node in sub-diagram<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC37.png|thumb]]<br />
|-<br />
| Multiple diagram ; Removed node in sub-diagram<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC38.png|thumb]]<br />
|-<br />
| Multiple diagram ; Mix of Added and Removed node in sub-diagram<br />
! style=&quot;color:green&quot; | ok<br />
| [[Image:TC39.png|thumb]]<br />
<br />
|}</div>Stephane.bouchet.obeo.frhttp://wiki.eclipse.org/index.php?title=File:TC36.png&diff=263524File:TC36.png2011-08-03T10:07:26Z<p>Stephane.bouchet.obeo.fr: </p>
<hr />
<div></div>Stephane.bouchet.obeo.frhttp://wiki.eclipse.org/index.php?title=File:TC39.png&diff=263468File:TC39.png2011-08-02T15:21:39Z<p>Stephane.bouchet.obeo.fr: </p>
<hr />
<div></div>Stephane.bouchet.obeo.frhttp://wiki.eclipse.org/index.php?title=File:TC38.png&diff=263467File:TC38.png2011-08-02T15:21:28Z<p>Stephane.bouchet.obeo.fr: </p>
<hr />
<div></div>Stephane.bouchet.obeo.fr