Description Cedric Brun 2013-10-15 09:02:51 EDT

When one don't use the semantic candidate expression the expectation is that means : any EObject of the right type in the Session.

Let's say you define a diagram attached to EPackage, and then add a ContainerMapping with domainClass="EPackage" and semanticCandidateExpression=""

You'll be suprised to see that only subEPackages will be displayed, and not the ones which are roots of a Resource

Of course this can be quite easily worked around by writing a dedicated java service.

Looking at the code, it simply ignores the roots when retrievient the semantic candidates, see the following patch fixing the pb:

--- a/plugins/org.eclipse.sirius/src/org/eclipse/sirius/business/internal/experimental/sync/AbstractSynchronizerHelper.java
+++ b/plugins/org.eclipse.sirius/src/org/eclipse/sirius/business/internal/experimental/sync/AbstractSynchronizerHelper.java
@@ -140,6 +140,9 @@ public abstract class AbstractSynchronizerHelper {
             } else {
                 for (final Resource resource : session.getSemanticResources()) {
                     for (final EObject root : resource.getContents()) {
+                       if (this.accessor.eInstanceOf(root, domainClass.get())) {
+                               semantics.add(root);
+                       }
                         semantics.addAll(this.accessor.eAllContents(root, domainClass.get()));
                     }
                 }



The thing is, it's been around for quite a long time and even our tests might rely on this behavior. We need to have a close look at them when integrating this change.