When I try to reopen my diagram after saving, it fails saying there are unresolvable references. These references come from an edge I see in the XML which refers to transientChildren. I am assuming that those children were not persisted, but I wonder why the edge is persisted as it has not been customized in any way.

Now, I have to disclose the special context for this problem. This only happens after a certain element is added to the diagram after having been copied from another model. I call it a template element. I added a tool to the palette which triggers normal CreateElementRequests with an extra parameter containing the template object. I then override the CreateCommand to detect the template parameter and add a copy of the template instead of a new element.

The unresolvable references to transientChildren only happen if a template object (MetadataBlock) is the first element added to the container, Dictionary in this case. If I add a normal new element to the Dictionary first, then add the template element as above, the problem does not occur.

If I add a normal element to the container first, then this edge does not seem to appear in the XML. Is there something I can do to remove this extra decor from notation on save. Not sure why it is being saved in one case and not the other.

I expect your problem likely stems from new EcoreUtil.Copier(false,
true) where you tell it not to resolve proxies. Why are you avoiding
proxy resolution? What's broken if you just let it resolve proxies? I
imagine you'd have a problem if the thing you're copying has proxies
that are supposed to resolve to other things that are also being
copied. In this case, instead of producing a reference to the copied
thing within the copy, the copy will have a reference that's a copy of
the proxy which, when resolved, refers to the original, and I expect you
certainly don't want that.

On 12/01/2013 8:54 PM, Greg Jansen wrote:
> When I try to reopen my diagram after saving, it fails saying there
> are unresolvable references. These references come from an edge I see
> in the XML which refers to transientChildren. I am assuming that those
> children were not persisted, but I wonder why the edge is persisted as
> it has not been customized in any way.
>
> Now, I have to disclose the special context for this problem. This
> only happens after a certain element is added to the diagram after
> having been copied from another model. I call it a template element. I
> added a tool to the palette which triggers normal
> CreateElementRequests with an extra parameter containing the template
> object. I then override the CreateCommand to detect the template
> parameter and add a copy of the template instead of a new element.
> Here is the code for that:
>
> protected CommandResult doExecuteWithResult(IProgressMonitor
> monitor, IAdaptable info) throws ExecutionException {
> CreateElementRequest request = ((CreateElementRequest)
> getRequest());
> MetadataBlock newElement = null;
> if (request.getParameters().containsKey("templateElement")) {
> EObject template = (EObject)
> request.getParameter("templateElement");
> EcoreUtil.Copier copier = new EcoreUtil.Copier(false, true);
> newElement = (MetadataBlock)copier.copy(template);
> copier.copyReferences();
> } else {
> newElement =
> CrosswalkFactory.eINSTANCE.createMetadataBlock();
> }
> Dictionary owner = (Dictionary) getElementToEdit();
> owner.getBlocks().add(newElement);
>
> doConfigure(newElement, monitor, info);
>
> ((CreateElementRequest) getRequest()).setNewElement(newElement);
> return CommandResult.newOKCommandResult(newElement);
> }
>
>
> The unresolvable references to transientChildren only happen if a
> template object (MetadataBlock) is the first element added to the
> container, Dictionary in this case. If I add a normal new element to
> the Dictionary first, then add the template element as above, the
> problem does not occur.
>
> Here is the XML which references transient children:
>
> <edges type="4001"
> source="/1/@children.0/@children.2/@children.0/@children.2/@transientChildren.0/@children.1/@transientChildren.0/@children.1/@children.0"
> target="/1/@children.0/@children.2/@children.0/@children.1/@children.0">
> <styles xsi:type="notation:RoutingStyle"/>
> <styles xsi:type="notation:FontStyle" fontName="Ubuntu"/>
> <element xsi:nil="true"/>
> <bendpoints xsi:type="notation:RelativeBendpoints" points="[0, 0,
> 0, 0]$[0, 0, 0, 0]"/>
> </edges>
>
>
> If I add a normal element to the container first, then this edge does
> not seem to appear in the XML. Is there something I can do to remove
> this extra decor from notation on save. Not sure why it is being saved
> in one case and not the other.
>
> Any help with this mystery is greatly appreciated.
> Greg

I expect your problem likely stems from new EcoreUtil.Copier(false,
true) where you tell it not to resolve proxies. Why are you avoiding
proxy resolution? What's broken if you just let it resolve proxies? I
imagine you'd have a problem if the thing you're copying has proxies
that are supposed to resolve to other things that are also being
copied. In this case, instead of producing a reference to the copied
thing within the copy, the copy will have a reference that's a copy of
the proxy which, when resolved, refers to the original, and I expect you
certainly don't want that.

On 12/01/2013 8:54 PM, Greg Jansen wrote:
> When I try to reopen my diagram after saving, it fails saying there
> are unresolvable references. These references come from an edge I see
> in the XML which refers to transientChildren. I am assuming that those
> children were not persisted, but I wonder why the edge is persisted as
> it has not been customized in any way.
>
> Now, I have to disclose the special context for this problem. This
> only happens after a certain element is added to the diagram after
> having been copied from another model. I call it a template element. I
> added a tool to the palette which triggers normal
> CreateElementRequests with an extra parameter containing the template
> object. I then override the CreateCommand to detect the template
> parameter and add a copy of the template instead of a new element.
> Here is the code for that:
>
> protected CommandResult doExecuteWithResult(IProgressMonitor
> monitor, IAdaptable info) throws ExecutionException {
> CreateElementRequest request = ((CreateElementRequest)
> getRequest());
> MetadataBlock newElement = null;
> if (request.getParameters().containsKey("templateElement")) {
> EObject template = (EObject)
> request.getParameter("templateElement");
> EcoreUtil.Copier copier = new EcoreUtil.Copier(false, true);
> newElement = (MetadataBlock)copier.copy(template);
> copier.copyReferences();
> } else {
> newElement =
> CrosswalkFactory.eINSTANCE.createMetadataBlock();
> }
> Dictionary owner = (Dictionary) getElementToEdit();
> owner.getBlocks().add(newElement);
>
> doConfigure(newElement, monitor, info);
>
> ((CreateElementRequest) getRequest()).setNewElement(newElement);
> return CommandResult.newOKCommandResult(newElement);
> }
>
>
> The unresolvable references to transientChildren only happen if a
> template object (MetadataBlock) is the first element added to the
> container, Dictionary in this case. If I add a normal new element to
> the Dictionary first, then add the template element as above, the
> problem does not occur.
>
> Here is the XML which references transient children:
>
> <edges type="4001"
> source="/1/@children.0/@children.2/@children.0/@children.2/@transientChildren.0/@children.1/@transientChildren.0/@children.1/@children.0"
> target="/1/@children.0/@children.2/@children.0/@children.1/@children.0">
> <styles xsi:type="notation:RoutingStyle"/>
> <styles xsi:type="notation:FontStyle" fontName="Ubuntu"/>
> <element xsi:nil="true"/>
> <bendpoints xsi:type="notation:RelativeBendpoints" points="[0, 0,
> 0, 0]$[0, 0, 0, 0]"/>
> </edges>
>
>
> If I add a normal element to the container first, then this edge does
> not seem to appear in the XML. Is there something I can do to remove
> this extra decor from notation on save. Not sure why it is being saved
> in one case and not the other.
>
> Any help with this mystery is greatly appreciated.
> Greg

I expect your problem likely stems from new EcoreUtil.Copier(false,
true) where you tell it not to resolve proxies. Why are you avoiding
proxy resolution? What's broken if you just let it resolve proxies? I
imagine you'd have a problem if the thing you're copying has proxies
that are supposed to resolve to other things that are also being
copied. In this case, instead of producing a reference to the copied
thing within the copy, the copy will have a reference that's a copy of
the proxy which, when resolved, refers to the original, and I expect you
certainly don't want that.

On 12/01/2013 8:54 PM, Greg Jansen wrote:
> When I try to reopen my diagram after saving, it fails saying there
> are unresolvable references. These references come from an edge I see
> in the XML which refers to transientChildren. I am assuming that those
> children were not persisted, but I wonder why the edge is persisted as
> it has not been customized in any way.
>
> Now, I have to disclose the special context for this problem. This
> only happens after a certain element is added to the diagram after
> having been copied from another model. I call it a template element. I
> added a tool to the palette which triggers normal
> CreateElementRequests with an extra parameter containing the template
> object. I then override the CreateCommand to detect the template
> parameter and add a copy of the template instead of a new element.
> Here is the code for that:
>
> protected CommandResult doExecuteWithResult(IProgressMonitor
> monitor, IAdaptable info) throws ExecutionException {
> CreateElementRequest request = ((CreateElementRequest)
> getRequest());
> MetadataBlock newElement = null;
> if (request.getParameters().containsKey("templateElement")) {
> EObject template = (EObject)
> request.getParameter("templateElement");
> EcoreUtil.Copier copier = new EcoreUtil.Copier(false, true);
> newElement = (MetadataBlock)copier.copy(template);
> copier.copyReferences();
> } else {
> newElement =
> CrosswalkFactory.eINSTANCE.createMetadataBlock();
> }
> Dictionary owner = (Dictionary) getElementToEdit();
> owner.getBlocks().add(newElement);
>
> doConfigure(newElement, monitor, info);
>
> ((CreateElementRequest) getRequest()).setNewElement(newElement);
> return CommandResult.newOKCommandResult(newElement);
> }
>
>
> The unresolvable references to transientChildren only happen if a
> template object (MetadataBlock) is the first element added to the
> container, Dictionary in this case. If I add a normal new element to
> the Dictionary first, then add the template element as above, the
> problem does not occur.
>
> Here is the XML which references transient children:
>
> <edges type="4001"
> source="/1/@children.0/@children.2/@children.0/@children.2/@transientChildren.0/@children.1/@transientChildren.0/@children.1/@children.0"
> target="/1/@children.0/@children.2/@children.0/@children.1/@children.0">
> <styles xsi:type="notation:RoutingStyle"/>
> <styles xsi:type="notation:FontStyle" fontName="Ubuntu"/>
> <element xsi:nil="true"/>
> <bendpoints xsi:type="notation:RelativeBendpoints" points="[0, 0,
> 0, 0]$[0, 0, 0, 0]"/>
> </edges>
>
>
> If I add a normal element to the container first, then this edge does
> not seem to appear in the XML. Is there something I can do to remove
> this extra decor from notation on save. Not sure why it is being saved
> in one case and not the other.
>
> Any help with this mystery is greatly appreciated.
> Greg

I expect your problem likely stems from new EcoreUtil.Copier(false,
true) where you tell it not to resolve proxies. Why are you avoiding
proxy resolution? What's broken if you just let it resolve proxies? I
imagine you'd have a problem if the thing you're copying has proxies
that are supposed to resolve to other things that are also being
copied. In this case, instead of producing a reference to the copied
thing within the copy, the copy will have a reference that's a copy of
the proxy which, when resolved, refers to the original, and I expect you
certainly don't want that.

On 12/01/2013 8:54 PM, Greg Jansen wrote:
> When I try to reopen my diagram after saving, it fails saying there
> are unresolvable references. These references come from an edge I see
> in the XML which refers to transientChildren. I am assuming that those
> children were not persisted, but I wonder why the edge is persisted as
> it has not been customized in any way.
>
> Now, I have to disclose the special context for this problem. This
> only happens after a certain element is added to the diagram after
> having been copied from another model. I call it a template element. I
> added a tool to the palette which triggers normal
> CreateElementRequests with an extra parameter containing the template
> object. I then override the CreateCommand to detect the template
> parameter and add a copy of the template instead of a new element.
> Here is the code for that:
>
> protected CommandResult doExecuteWithResult(IProgressMonitor
> monitor, IAdaptable info) throws ExecutionException {
> CreateElementRequest request = ((CreateElementRequest)
> getRequest());
> MetadataBlock newElement = null;
> if (request.getParameters().containsKey("templateElement")) {
> EObject template = (EObject)
> request.getParameter("templateElement");
> EcoreUtil.Copier copier = new EcoreUtil.Copier(false, true);
> newElement = (MetadataBlock)copier.copy(template);
> copier.copyReferences();
> } else {
> newElement =
> CrosswalkFactory.eINSTANCE.createMetadataBlock();
> }
> Dictionary owner = (Dictionary) getElementToEdit();
> owner.getBlocks().add(newElement);
>
> doConfigure(newElement, monitor, info);
>
> ((CreateElementRequest) getRequest()).setNewElement(newElement);
> return CommandResult.newOKCommandResult(newElement);
> }
>
>
> The unresolvable references to transientChildren only happen if a
> template object (MetadataBlock) is the first element added to the
> container, Dictionary in this case. If I add a normal new element to
> the Dictionary first, then add the template element as above, the
> problem does not occur.
>
> Here is the XML which references transient children:
>
> <edges type="4001"
> source="/1/@children.0/@children.2/@children.0/@children.2/@transientChildren.0/@children.1/@transientChildren.0/@children.1/@children.0"
> target="/1/@children.0/@children.2/@children.0/@children.1/@children.0">
> <styles xsi:type="notation:RoutingStyle"/>
> <styles xsi:type="notation:FontStyle" fontName="Ubuntu"/>
> <element xsi:nil="true"/>
> <bendpoints xsi:type="notation:RelativeBendpoints" points="[0, 0,
> 0, 0]$[0, 0, 0, 0]"/>
> </edges>
>
>
> If I add a normal element to the container first, then this edge does
> not seem to appear in the XML. Is there something I can do to remove
> this extra decor from notation on save. Not sure why it is being saved
> in one case and not the other.
>
> Any help with this mystery is greatly appreciated.
> Greg

I expect your problem likely stems from new EcoreUtil.Copier(false,
true) where you tell it not to resolve proxies. Why are you avoiding
proxy resolution? What's broken if you just let it resolve proxies? I
imagine you'd have a problem if the thing you're copying has proxies
that are supposed to resolve to other things that are also being
copied. In this case, instead of producing a reference to the copied
thing within the copy, the copy will have a reference that's a copy of
the proxy which, when resolved, refers to the original, and I expect you
certainly don't want that.

On 12/01/2013 8:54 PM, Greg Jansen wrote:
> When I try to reopen my diagram after saving, it fails saying there
> are unresolvable references. These references come from an edge I see
> in the XML which refers to transientChildren. I am assuming that those
> children were not persisted, but I wonder why the edge is persisted as
> it has not been customized in any way.
>
> Now, I have to disclose the special context for this problem. This
> only happens after a certain element is added to the diagram after
> having been copied from another model. I call it a template element. I
> added a tool to the palette which triggers normal
> CreateElementRequests with an extra parameter containing the template
> object. I then override the CreateCommand to detect the template
> parameter and add a copy of the template instead of a new element.
> Here is the code for that:
>
> protected CommandResult doExecuteWithResult(IProgressMonitor
> monitor, IAdaptable info) throws ExecutionException {
> CreateElementRequest request = ((CreateElementRequest)
> getRequest());
> MetadataBlock newElement = null;
> if (request.getParameters().containsKey("templateElement")) {
> EObject template = (EObject)
> request.getParameter("templateElement");
> EcoreUtil.Copier copier = new EcoreUtil.Copier(false, true);
> newElement = (MetadataBlock)copier.copy(template);
> copier.copyReferences();
> } else {
> newElement =
> CrosswalkFactory.eINSTANCE.createMetadataBlock();
> }
> Dictionary owner = (Dictionary) getElementToEdit();
> owner.getBlocks().add(newElement);
>
> doConfigure(newElement, monitor, info);
>
> ((CreateElementRequest) getRequest()).setNewElement(newElement);
> return CommandResult.newOKCommandResult(newElement);
> }
>
>
> The unresolvable references to transientChildren only happen if a
> template object (MetadataBlock) is the first element added to the
> container, Dictionary in this case. If I add a normal new element to
> the Dictionary first, then add the template element as above, the
> problem does not occur.
>
> Here is the XML which references transient children:
>
> <edges type="4001"
> source="/1/@children.0/@children.2/@children.0/@children.2/@transientChildren.0/@children.1/@transientChildren.0/@children.1/@children.0"
> target="/1/@children.0/@children.2/@children.0/@children.1/@children.0">
> <styles xsi:type="notation:RoutingStyle"/>
> <styles xsi:type="notation:FontStyle" fontName="Ubuntu"/>
> <element xsi:nil="true"/>
> <bendpoints xsi:type="notation:RelativeBendpoints" points="[0, 0,
> 0, 0]$[0, 0, 0, 0]"/>
> </edges>
>
>
> If I add a normal element to the container first, then this edge does
> not seem to appear in the XML. Is there something I can do to remove
> this extra decor from notation on save. Not sure why it is being saved
> in one case and not the other.
>
> Any help with this mystery is greatly appreciated.
> Greg

I expect your problem likely stems from new EcoreUtil.Copier(false,
true) where you tell it not to resolve proxies. Why are you avoiding
proxy resolution? What's broken if you just let it resolve proxies? I
imagine you'd have a problem if the thing you're copying has proxies
that are supposed to resolve to other things that are also being
copied. In this case, instead of producing a reference to the copied
thing within the copy, the copy will have a reference that's a copy of
the proxy which, when resolved, refers to the original, and I expect you
certainly don't want that.

On 12/01/2013 8:54 PM, Greg Jansen wrote:
> When I try to reopen my diagram after saving, it fails saying there
> are unresolvable references. These references come from an edge I see
> in the XML which refers to transientChildren. I am assuming that those
> children were not persisted, but I wonder why the edge is persisted as
> it has not been customized in any way.
>
> Now, I have to disclose the special context for this problem. This
> only happens after a certain element is added to the diagram after
> having been copied from another model. I call it a template element. I
> added a tool to the palette which triggers normal
> CreateElementRequests with an extra parameter containing the template
> object. I then override the CreateCommand to detect the template
> parameter and add a copy of the template instead of a new element.
> Here is the code for that:
>
> protected CommandResult doExecuteWithResult(IProgressMonitor
> monitor, IAdaptable info) throws ExecutionException {
> CreateElementRequest request = ((CreateElementRequest)
> getRequest());
> MetadataBlock newElement = null;
> if (request.getParameters().containsKey("templateElement")) {
> EObject template = (EObject)
> request.getParameter("templateElement");
> EcoreUtil.Copier copier = new EcoreUtil.Copier(false, true);
> newElement = (MetadataBlock)copier.copy(template);
> copier.copyReferences();
> } else {
> newElement =
> CrosswalkFactory.eINSTANCE.createMetadataBlock();
> }
> Dictionary owner = (Dictionary) getElementToEdit();
> owner.getBlocks().add(newElement);
>
> doConfigure(newElement, monitor, info);
>
> ((CreateElementRequest) getRequest()).setNewElement(newElement);
> return CommandResult.newOKCommandResult(newElement);
> }
>
>
> The unresolvable references to transientChildren only happen if a
> template object (MetadataBlock) is the first element added to the
> container, Dictionary in this case. If I add a normal new element to
> the Dictionary first, then add the template element as above, the
> problem does not occur.
>
> Here is the XML which references transient children:
>
> <edges type="4001"
> source="/1/@children.0/@children.2/@children.0/@children.2/@transientChildren.0/@children.1/@transientChildren.0/@children.1/@children.0"
> target="/1/@children.0/@children.2/@children.0/@children.1/@children.0">
> <styles xsi:type="notation:RoutingStyle"/>
> <styles xsi:type="notation:FontStyle" fontName="Ubuntu"/>
> <element xsi:nil="true"/>
> <bendpoints xsi:type="notation:RelativeBendpoints" points="[0, 0,
> 0, 0]$[0, 0, 0, 0]"/>
> </edges>
>
>
> If I add a normal element to the container first, then this edge does
> not seem to appear in the XML. Is there something I can do to remove
> this extra decor from notation on save. Not sure why it is being saved
> in one case and not the other.
>
> Any help with this mystery is greatly appreciated.
> Greg

I expect your problem likely stems from new EcoreUtil.Copier(false,
true) where you tell it not to resolve proxies. Why are you avoiding
proxy resolution? What's broken if you just let it resolve proxies? I
imagine you'd have a problem if the thing you're copying has proxies
that are supposed to resolve to other things that are also being
copied. In this case, instead of producing a reference to the copied
thing within the copy, the copy will have a reference that's a copy of
the proxy which, when resolved, refers to the original, and I expect you
certainly don't want that.

On 12/01/2013 8:54 PM, Greg Jansen wrote:
> When I try to reopen my diagram after saving, it fails saying there
> are unresolvable references. These references come from an edge I see
> in the XML which refers to transientChildren. I am assuming that those
> children were not persisted, but I wonder why the edge is persisted as
> it has not been customized in any way.
>
> Now, I have to disclose the special context for this problem. This
> only happens after a certain element is added to the diagram after
> having been copied from another model. I call it a template element. I
> added a tool to the palette which triggers normal
> CreateElementRequests with an extra parameter containing the template
> object. I then override the CreateCommand to detect the template
> parameter and add a copy of the template instead of a new element.
> Here is the code for that:
>
> protected CommandResult doExecuteWithResult(IProgressMonitor
> monitor, IAdaptable info) throws ExecutionException {
> CreateElementRequest request = ((CreateElementRequest)
> getRequest());
> MetadataBlock newElement = null;
> if (request.getParameters().containsKey("templateElement")) {
> EObject template = (EObject)
> request.getParameter("templateElement");
> EcoreUtil.Copier copier = new EcoreUtil.Copier(false, true);
> newElement = (MetadataBlock)copier.copy(template);
> copier.copyReferences();
> } else {
> newElement =
> CrosswalkFactory.eINSTANCE.createMetadataBlock();
> }
> Dictionary owner = (Dictionary) getElementToEdit();
> owner.getBlocks().add(newElement);
>
> doConfigure(newElement, monitor, info);
>
> ((CreateElementRequest) getRequest()).setNewElement(newElement);
> return CommandResult.newOKCommandResult(newElement);
> }
>
>
> The unresolvable references to transientChildren only happen if a
> template object (MetadataBlock) is the first element added to the
> container, Dictionary in this case. If I add a normal new element to
> the Dictionary first, then add the template element as above, the
> problem does not occur.
>
> Here is the XML which references transient children:
>
> <edges type="4001"
> source="/1/@children.0/@children.2/@children.0/@children.2/@transientChildren.0/@children.1/@transientChildren.0/@children.1/@children.0"
> target="/1/@children.0/@children.2/@children.0/@children.1/@children.0">
> <styles xsi:type="notation:RoutingStyle"/>
> <styles xsi:type="notation:FontStyle" fontName="Ubuntu"/>
> <element xsi:nil="true"/>
> <bendpoints xsi:type="notation:RelativeBendpoints" points="[0, 0,
> 0, 0]$[0, 0, 0, 0]"/>
> </edges>
>
>
> If I add a normal element to the container first, then this edge does
> not seem to appear in the XML. Is there something I can do to remove
> this extra decor from notation on save. Not sure why it is being saved
> in one case and not the other.
>
> Any help with this mystery is greatly appreciated.
> Greg

I expect your problem likely stems from new EcoreUtil.Copier(false,
true) where you tell it not to resolve proxies. Why are you avoiding
proxy resolution? What's broken if you just let it resolve proxies? I
imagine you'd have a problem if the thing you're copying has proxies
that are supposed to resolve to other things that are also being
copied. In this case, instead of producing a reference to the copied
thing within the copy, the copy will have a reference that's a copy of
the proxy which, when resolved, refers to the original, and I expect you
certainly don't want that.

On 12/01/2013 8:54 PM, Greg Jansen wrote:
> When I try to reopen my diagram after saving, it fails saying there
> are unresolvable references. These references come from an edge I see
> in the XML which refers to transientChildren. I am assuming that those
> children were not persisted, but I wonder why the edge is persisted as
> it has not been customized in any way.
>
> Now, I have to disclose the special context for this problem. This
> only happens after a certain element is added to the diagram after
> having been copied from another model. I call it a template element. I
> added a tool to the palette which triggers normal
> CreateElementRequests with an extra parameter containing the template
> object. I then override the CreateCommand to detect the template
> parameter and add a copy of the template instead of a new element.
> Here is the code for that:
>
> protected CommandResult doExecuteWithResult(IProgressMonitor
> monitor, IAdaptable info) throws ExecutionException {
> CreateElementRequest request = ((CreateElementRequest)
> getRequest());
> MetadataBlock newElement = null;
> if (request.getParameters().containsKey("templateElement")) {
> EObject template = (EObject)
> request.getParameter("templateElement");
> EcoreUtil.Copier copier = new EcoreUtil.Copier(false, true);
> newElement = (MetadataBlock)copier.copy(template);
> copier.copyReferences();
> } else {
> newElement =
> CrosswalkFactory.eINSTANCE.createMetadataBlock();
> }
> Dictionary owner = (Dictionary) getElementToEdit();
> owner.getBlocks().add(newElement);
>
> doConfigure(newElement, monitor, info);
>
> ((CreateElementRequest) getRequest()).setNewElement(newElement);
> return CommandResult.newOKCommandResult(newElement);
> }
>
>
> The unresolvable references to transientChildren only happen if a
> template object (MetadataBlock) is the first element added to the
> container, Dictionary in this case. If I add a normal new element to
> the Dictionary first, then add the template element as above, the
> problem does not occur.
>
> Here is the XML which references transient children:
>
> <edges type="4001"
> source="/1/@children.0/@children.2/@children.0/@children.2/@transientChildren.0/@children.1/@transientChildren.0/@children.1/@children.0"
> target="/1/@children.0/@children.2/@children.0/@children.1/@children.0">
> <styles xsi:type="notation:RoutingStyle"/>
> <styles xsi:type="notation:FontStyle" fontName="Ubuntu"/>
> <element xsi:nil="true"/>
> <bendpoints xsi:type="notation:RelativeBendpoints" points="[0, 0,
> 0, 0]$[0, 0, 0, 0]"/>
> </edges>
>
>
> If I add a normal element to the container first, then this edge does
> not seem to appear in the XML. Is there something I can do to remove
> this extra decor from notation on save. Not sure why it is being saved
> in one case and not the other.
>
> Any help with this mystery is greatly appreciated.
> Greg

I expect your problem likely stems from new EcoreUtil.Copier(false,
true) where you tell it not to resolve proxies. Why are you avoiding
proxy resolution? What's broken if you just let it resolve proxies? I
imagine you'd have a problem if the thing you're copying has proxies
that are supposed to resolve to other things that are also being
copied. In this case, instead of producing a reference to the copied
thing within the copy, the copy will have a reference that's a copy of
the proxy which, when resolved, refers to the original, and I expect you
certainly don't want that.

On 12/01/2013 8:54 PM, Greg Jansen wrote:
> When I try to reopen my diagram after saving, it fails saying there
> are unresolvable references. These references come from an edge I see
> in the XML which refers to transientChildren. I am assuming that those
> children were not persisted, but I wonder why the edge is persisted as
> it has not been customized in any way.
>
> Now, I have to disclose the special context for this problem. This
> only happens after a certain element is added to the diagram after
> having been copied from another model. I call it a template element. I
> added a tool to the palette which triggers normal
> CreateElementRequests with an extra parameter containing the template
> object. I then override the CreateCommand to detect the template
> parameter and add a copy of the template instead of a new element.
> Here is the code for that:
>
> protected CommandResult doExecuteWithResult(IProgressMonitor
> monitor, IAdaptable info) throws ExecutionException {
> CreateElementRequest request = ((CreateElementRequest)
> getRequest());
> MetadataBlock newElement = null;
> if (request.getParameters().containsKey("templateElement")) {
> EObject template = (EObject)
> request.getParameter("templateElement");
> EcoreUtil.Copier copier = new EcoreUtil.Copier(false, true);
> newElement = (MetadataBlock)copier.copy(template);
> copier.copyReferences();
> } else {
> newElement =
> CrosswalkFactory.eINSTANCE.createMetadataBlock();
> }
> Dictionary owner = (Dictionary) getElementToEdit();
> owner.getBlocks().add(newElement);
>
> doConfigure(newElement, monitor, info);
>
> ((CreateElementRequest) getRequest()).setNewElement(newElement);
> return CommandResult.newOKCommandResult(newElement);
> }
>
>
> The unresolvable references to transientChildren only happen if a
> template object (MetadataBlock) is the first element added to the
> container, Dictionary in this case. If I add a normal new element to
> the Dictionary first, then add the template element as above, the
> problem does not occur.
>
> Here is the XML which references transient children:
>
> <edges type="4001"
> source="/1/@children.0/@children.2/@children.0/@children.2/@transientChildren.0/@children.1/@transientChildren.0/@children.1/@children.0"
> target="/1/@children.0/@children.2/@children.0/@children.1/@children.0">
> <styles xsi:type="notation:RoutingStyle"/>
> <styles xsi:type="notation:FontStyle" fontName="Ubuntu"/>
> <element xsi:nil="true"/>
> <bendpoints xsi:type="notation:RelativeBendpoints" points="[0, 0,
> 0, 0]$[0, 0, 0, 0]"/>
> </edges>
>
>
> If I add a normal element to the container first, then this edge does
> not seem to appear in the XML. Is there something I can do to remove
> this extra decor from notation on save. Not sure why it is being saved
> in one case and not the other.
>
> Any help with this mystery is greatly appreciated.
> Greg

I expect your problem likely stems from new EcoreUtil.Copier(false,
true) where you tell it not to resolve proxies. Why are you avoiding
proxy resolution? What's broken if you just let it resolve proxies? I
imagine you'd have a problem if the thing you're copying has proxies
that are supposed to resolve to other things that are also being
copied. In this case, instead of producing a reference to the copied
thing within the copy, the copy will have a reference that's a copy of
the proxy which, when resolved, refers to the original, and I expect you
certainly don't want that.

On 12/01/2013 8:54 PM, Greg Jansen wrote:
> When I try to reopen my diagram after saving, it fails saying there
> are unresolvable references. These references come from an edge I see
> in the XML which refers to transientChildren. I am assuming that those
> children were not persisted, but I wonder why the edge is persisted as
> it has not been customized in any way.
>
> Now, I have to disclose the special context for this problem. This
> only happens after a certain element is added to the diagram after
> having been copied from another model. I call it a template element. I
> added a tool to the palette which triggers normal
> CreateElementRequests with an extra parameter containing the template
> object. I then override the CreateCommand to detect the template
> parameter and add a copy of the template instead of a new element.
> Here is the code for that:
>
> protected CommandResult doExecuteWithResult(IProgressMonitor
> monitor, IAdaptable info) throws ExecutionException {
> CreateElementRequest request = ((CreateElementRequest)
> getRequest());
> MetadataBlock newElement = null;
> if (request.getParameters().containsKey("templateElement")) {
> EObject template = (EObject)
> request.getParameter("templateElement");
> EcoreUtil.Copier copier = new EcoreUtil.Copier(false, true);
> newElement = (MetadataBlock)copier.copy(template);
> copier.copyReferences();
> } else {
> newElement =
> CrosswalkFactory.eINSTANCE.createMetadataBlock();
> }
> Dictionary owner = (Dictionary) getElementToEdit();
> owner.getBlocks().add(newElement);
>
> doConfigure(newElement, monitor, info);
>
> ((CreateElementRequest) getRequest()).setNewElement(newElement);
> return CommandResult.newOKCommandResult(newElement);
> }
>
>
> The unresolvable references to transientChildren only happen if a
> template object (MetadataBlock) is the first element added to the
> container, Dictionary in this case. If I add a normal new element to
> the Dictionary first, then add the template element as above, the
> problem does not occur.
>
> Here is the XML which references transient children:
>
> <edges type="4001"
> source="/1/@children.0/@children.2/@children.0/@children.2/@transientChildren.0/@children.1/@transientChildren.0/@children.1/@children.0"
> target="/1/@children.0/@children.2/@children.0/@children.1/@children.0">
> <styles xsi:type="notation:RoutingStyle"/>
> <styles xsi:type="notation:FontStyle" fontName="Ubuntu"/>
> <element xsi:nil="true"/>
> <bendpoints xsi:type="notation:RelativeBendpoints" points="[0, 0,
> 0, 0]$[0, 0, 0, 0]"/>
> </edges>
>
>
> If I add a normal element to the container first, then this edge does
> not seem to appear in the XML. Is there something I can do to remove
> this extra decor from notation on save. Not sure why it is being saved
> in one case and not the other.
>
> Any help with this mystery is greatly appreciated.
> Greg

I expect your problem likely stems from new EcoreUtil.Copier(false,
true) where you tell it not to resolve proxies. Why are you avoiding
proxy resolution? What's broken if you just let it resolve proxies? I
imagine you'd have a problem if the thing you're copying has proxies
that are supposed to resolve to other things that are also being
copied. In this case, instead of producing a reference to the copied
thing within the copy, the copy will have a reference that's a copy of
the proxy which, when resolved, refers to the original, and I expect you
certainly don't want that.

On 12/01/2013 8:54 PM, Greg Jansen wrote:
> When I try to reopen my diagram after saving, it fails saying there
> are unresolvable references. These references come from an edge I see
> in the XML which refers to transientChildren. I am assuming that those
> children were not persisted, but I wonder why the edge is persisted as
> it has not been customized in any way.
>
> Now, I have to disclose the special context for this problem. This
> only happens after a certain element is added to the diagram after
> having been copied from another model. I call it a template element. I
> added a tool to the palette which triggers normal
> CreateElementRequests with an extra parameter containing the template
> object. I then override the CreateCommand to detect the template
> parameter and add a copy of the template instead of a new element.
> Here is the code for that:
>
> protected CommandResult doExecuteWithResult(IProgressMonitor
> monitor, IAdaptable info) throws ExecutionException {
> CreateElementRequest request = ((CreateElementRequest)
> getRequest());
> MetadataBlock newElement = null;
> if (request.getParameters().containsKey("templateElement")) {
> EObject template = (EObject)
> request.getParameter("templateElement");
> EcoreUtil.Copier copier = new EcoreUtil.Copier(false, true);
> newElement = (MetadataBlock)copier.copy(template);
> copier.copyReferences();
> } else {
> newElement =
> CrosswalkFactory.eINSTANCE.createMetadataBlock();
> }
> Dictionary owner = (Dictionary) getElementToEdit();
> owner.getBlocks().add(newElement);
>
> doConfigure(newElement, monitor, info);
>
> ((CreateElementRequest) getRequest()).setNewElement(newElement);
> return CommandResult.newOKCommandResult(newElement);
> }
>
>
> The unresolvable references to transientChildren only happen if a
> template object (MetadataBlock) is the first element added to the
> container, Dictionary in this case. If I add a normal new element to
> the Dictionary first, then add the template element as above, the
> problem does not occur.
>
> Here is the XML which references transient children:
>
> <edges type="4001"
> source="/1/@children.0/@children.2/@children.0/@children.2/@transientChildren.0/@children.1/@transientChildren.0/@children.1/@children.0"
> target="/1/@children.0/@children.2/@children.0/@children.1/@children.0">
> <styles xsi:type="notation:RoutingStyle"/>
> <styles xsi:type="notation:FontStyle" fontName="Ubuntu"/>
> <element xsi:nil="true"/>
> <bendpoints xsi:type="notation:RelativeBendpoints" points="[0, 0,
> 0, 0]$[0, 0, 0, 0]"/>
> </edges>
>
>
> If I add a normal element to the container first, then this edge does
> not seem to appear in the XML. Is there something I can do to remove
> this extra decor from notation on save. Not sure why it is being saved
> in one case and not the other.
>
> Any help with this mystery is greatly appreciated.
> Greg

I expect your problem likely stems from new EcoreUtil.Copier(false,
true) where you tell it not to resolve proxies. Why are you avoiding
proxy resolution? What's broken if you just let it resolve proxies? I
imagine you'd have a problem if the thing you're copying has proxies
that are supposed to resolve to other things that are also being
copied. In this case, instead of producing a reference to the copied
thing within the copy, the copy will have a reference that's a copy of
the proxy which, when resolved, refers to the original, and I expect you
certainly don't want that.

On 12/01/2013 8:54 PM, Greg Jansen wrote:
> When I try to reopen my diagram after saving, it fails saying there
> are unresolvable references. These references come from an edge I see
> in the XML which refers to transientChildren. I am assuming that those
> children were not persisted, but I wonder why the edge is persisted as
> it has not been customized in any way.
>
> Now, I have to disclose the special context for this problem. This
> only happens after a certain element is added to the diagram after
> having been copied from another model. I call it a template element. I
> added a tool to the palette which triggers normal
> CreateElementRequests with an extra parameter containing the template
> object. I then override the CreateCommand to detect the template
> parameter and add a copy of the template instead of a new element.
> Here is the code for that:
>
> protected CommandResult doExecuteWithResult(IProgressMonitor
> monitor, IAdaptable info) throws ExecutionException {
> CreateElementRequest request = ((CreateElementRequest)
> getRequest());
> MetadataBlock newElement = null;
> if (request.getParameters().containsKey("templateElement")) {
> EObject template = (EObject)
> request.getParameter("templateElement");
> EcoreUtil.Copier copier = new EcoreUtil.Copier(false, true);
> newElement = (MetadataBlock)copier.copy(template);
> copier.copyReferences();
> } else {
> newElement =
> CrosswalkFactory.eINSTANCE.createMetadataBlock();
> }
> Dictionary owner = (Dictionary) getElementToEdit();
> owner.getBlocks().add(newElement);
>
> doConfigure(newElement, monitor, info);
>
> ((CreateElementRequest) getRequest()).setNewElement(newElement);
> return CommandResult.newOKCommandResult(newElement);
> }
>
>
> The unresolvable references to transientChildren only happen if a
> template object (MetadataBlock) is the first element added to the
> container, Dictionary in this case. If I add a normal new element to
> the Dictionary first, then add the template element as above, the
> problem does not occur.
>
> Here is the XML which references transient children:
>
> <edges type="4001"
> source="/1/@children.0/@children.2/@children.0/@children.2/@transientChildren.0/@children.1/@transientChildren.0/@children.1/@children.0"
> target="/1/@children.0/@children.2/@children.0/@children.1/@children.0">
> <styles xsi:type="notation:RoutingStyle"/>
> <styles xsi:type="notation:FontStyle" fontName="Ubuntu"/>
> <element xsi:nil="true"/>
> <bendpoints xsi:type="notation:RelativeBendpoints" points="[0, 0,
> 0, 0]$[0, 0, 0, 0]"/>
> </edges>
>
>
> If I add a normal element to the container first, then this edge does
> not seem to appear in the XML. Is there something I can do to remove
> this extra decor from notation on save. Not sure why it is being saved
> in one case and not the other.
>
> Any help with this mystery is greatly appreciated.
> Greg

I expect your problem likely stems from new EcoreUtil.Copier(false,
true) where you tell it not to resolve proxies. Why are you avoiding
proxy resolution? What's broken if you just let it resolve proxies? I
imagine you'd have a problem if the thing you're copying has proxies
that are supposed to resolve to other things that are also being
copied. In this case, instead of producing a reference to the copied
thing within the copy, the copy will have a reference that's a copy of
the proxy which, when resolved, refers to the original, and I expect you
certainly don't want that.

On 12/01/2013 8:54 PM, Greg Jansen wrote:
> When I try to reopen my diagram after saving, it fails saying there
> are unresolvable references. These references come from an edge I see
> in the XML which refers to transientChildren. I am assuming that those
> children were not persisted, but I wonder why the edge is persisted as
> it has not been customized in any way.
>
> Now, I have to disclose the special context for this problem. This
> only happens after a certain element is added to the diagram after
> having been copied from another model. I call it a template element. I
> added a tool to the palette which triggers normal
> CreateElementRequests with an extra parameter containing the template
> object. I then override the CreateCommand to detect the template
> parameter and add a copy of the template instead of a new element.
> Here is the code for that:
>
> protected CommandResult doExecuteWithResult(IProgressMonitor
> monitor, IAdaptable info) throws ExecutionException {
> CreateElementRequest request = ((CreateElementRequest)
> getRequest());
> MetadataBlock newElement = null;
> if (request.getParameters().containsKey("templateElement")) {
> EObject template = (EObject)
> request.getParameter("templateElement");
> EcoreUtil.Copier copier = new EcoreUtil.Copier(false, true);
> newElement = (MetadataBlock)copier.copy(template);
> copier.copyReferences();
> } else {
> newElement =
> CrosswalkFactory.eINSTANCE.createMetadataBlock();
> }
> Dictionary owner = (Dictionary) getElementToEdit();
> owner.getBlocks().add(newElement);
>
> doConfigure(newElement, monitor, info);
>
> ((CreateElementRequest) getRequest()).setNewElement(newElement);
> return CommandResult.newOKCommandResult(newElement);
> }
>
>
> The unresolvable references to transientChildren only happen if a
> template object (MetadataBlock) is the first element added to the
> container, Dictionary in this case. If I add a normal new element to
> the Dictionary first, then add the template element as above, the
> problem does not occur.
>
> Here is the XML which references transient children:
>
> <edges type="4001"
> source="/1/@children.0/@children.2/@children.0/@children.2/@transientChildren.0/@children.1/@transientChildren.0/@children.1/@children.0"
> target="/1/@children.0/@children.2/@children.0/@children.1/@children.0">
> <styles xsi:type="notation:RoutingStyle"/>
> <styles xsi:type="notation:FontStyle" fontName="Ubuntu"/>
> <element xsi:nil="true"/>
> <bendpoints xsi:type="notation:RelativeBendpoints" points="[0, 0,
> 0, 0]$[0, 0, 0, 0]"/>
> </edges>
>
>
> If I add a normal element to the container first, then this edge does
> not seem to appear in the XML. Is there something I can do to remove
> this extra decor from notation on save. Not sure why it is being saved
> in one case and not the other.
>
> Any help with this mystery is greatly appreciated.
> Greg

Thanks Ed,
I just tried changing the Copier call to also resolve proxies, then created a new diagram and performed the test. Still unable to reopen the model after a save and for the same reason as previously. However, all is well otherwise with the proxies being resolved, so I will keep resolving them. I wish I understood proxies better, so I will probably consult your book when I get back to the office.

Does this thing you're copying have any non-containment references? It
certainly appears to be the case that notation model is creating
notational elements (Edges I suppose) that refer to something that
you've not actually copied. You'll need to track down why it's doing
that and when it's doing that. You might do so by setting a breakpoint
in the setSource method of an Edge (and perhaps make it conditional on
EcoreUtil.getURI(source).toString().contains("transientChildren"). Is it
okay that you switch the element in the CreateElementRequest during
execution as opposed to specializing where the element request itself is
created? I don't know GMF well enough to know the answer to that.

On 14/01/2013 2:48 AM, Greg Jansen wrote:
> Thanks Ed,
> I just tried changing the Copier call to also resolve proxies, then
> created a new diagram and performed the test. Still unable to reopen
> the model after a save and for the same reason as previously. However,
> all is well otherwise with the proxies being resolved, so I will keep
> resolving them. I wish I understood proxies better, so I will probably
> consult your book when I get back to the office.
>
> Many thanks. If you have further suggestions, I am all ears.
> Greg
>

Yes to non-containment references. The element I use as a template contains other elements that reference structural features in another model. (This template is used to build an XML-like structure, based on a schema generated model. It then let's the end user map data into the XML-like structure and generates XML.)

So there are two types of non-containment references within the MetadataBlock, which is what I've been calling the template. One type refers to structural features in a separate model. Another type links a mapped attribute to the TextInputField within the same enclosing MetadataBlock. The attribute-to-input link is an edge that is normally displayed in the diagram.

Since I haven't included it before, here is the error message with the unresolvable path:
Unresolved reference '/1/@children.0/@children.2/@children.0/@children.2/@transientChildren.0/@children.1/@transientChildren.0/@children.1/@children.0'. (platform:/resource/greg/my.form, 50, 234)

I have also attached the contents of my.form after saving and closing the diagram. It contains just the one copied MetadataBlock element in the model. You can see the edge element in the notational model. This is the same one edge visible in the diagram and mentioned above. The transient children it refers to are also part of the notation model.

When I create a diagram with the same structure using only new elements and not any copies, the edge is persisted but only references normal, non-transient, children.

In answer to your question about switching the element in the CreateElementRequest.. I think in GMF that property of the request, i.e. setNewElement(), is meant to be set in this context. It was being set here before I customized the generated class. It is passed along from this point to be used by later commands in the pipeline, including any edit advice.

I do think this is a fairly GMF-specific issue, since I am not directly copying any notation objects that might refer to this template object. I had assumed that all those notation objects were being created when the view was synchronized after the create command had finished. I probably need to know more about that part of the GMF pipeline.

I have discovered a strange workaround for this issue. If I add a newly created MetadataBlock element to the diagram first, then add the copied one, then the edge is persisted without transient child references. So this issue seem to only occur when the copied element is the first element added to the containing ordered list. Note that I have three elements in my model that may contain these copied template objects. The issue occurs in two out of the three. The two containment features in which this occurs are ordered, but the one without issues is not ordered.

Could this have something to do with the useOriginalReferences option, currently set to true? Would that mean the internal reference within the copied object would not be a copy somehow, but instead be the original EReference object? Perhaps that would explain the weird edge?

I have useOriginalReferences set to true b/c without that option I lose my other important references, the ones that refer to structural features in another model.

On 14/01/2013 4:13 PM, Greg Jansen wrote:
> Yes to non-containment references. The element I use as a template contains other elements that reference structural features in another model.
Where do the actual referenced objects reside, i.e., where are they
contained?
> (This template is used to build an XML-like structure, based on a schema generated model. It then let's the end user map data into the XML-like structure and generates XML.)
>
> So here is exactly what is being copied:
>
> MetadataBlock
> 0..* elements (containment)
> MappedElement
> 1 mappedFeature (EReference to EStructuralFeature in separate model)
> 0..* mappedAttributes
> MappedAttribute
> 1 mappedFeature (EReference to EStructuralFeature in separate model)
> ? input (EReference to an InputField as below)
> 0..* inputs
> TextInputField
>
>
> So there are two types of non-containment references within the MetadataBlock, which is what I've been calling the template. One type refers to structural features in a separate model. Another type links a mapped attribute to the TextInputField within the same enclosing MetadataBlock.
That's likely the one that's causing problem...
> The attribute-to-input link is an edge that is normally displayed in the diagram.
>
> Since I haven't included it before, here is the error message with the unresolvable path:
> Unresolved reference '/1/@children.0/@children.2/@children.0/@children.2/@transientChildren.0/@children.1/@transientChildren.0/@children.1/@children.0'. (platform:/resource/greg/my.form, 50, 234)
>
> I have also attached the contents of my.form after saving and closing the diagram. It contains just the one copied MetadataBlock element in the model. You can see the edge element in the notational model. This is the same one edge visible in the diagram and mentioned above. The transient children it refers to are also part of the notation model.
>
> When I create a diagram with the same structure using only new elements and not any copies, the edge is persisted but only references normal, non-transient, children.
>
> In answer to your question about switching the element in the CreateElementRequest.. I think in GMF that property of the request, i.e. setNewElement(), is meant to be set in this context. It was being set here before I customized the generated class. It is passed along from this point to be used by later commands in the pipeline, including any edit advice.
Okay.
>
> I do think this is a fairly GMF-specific issue, since I am not directly copying any notation objects that might refer to this template object. I had assumed that all those notation objects were being created when the view was synchronized after the create command had finished. I probably need to know more about that part of the GMF pipeline.
It doesn't sound like you set breakpoint as suggested. It sounds like
your copy has references to these transient things. That wouldn't
surprise me if you told it not to resolve proxies while copying. I
don't expect such a resolve if you actually resolved the proxies. Have
you looked (with the debugger) at the result of the copy? Does it
contain references to the original objects where you would expect a
reference to the copied thing (specifically for "another type links a
mapped attribute to the TextInputField within the same enclosing
MetadataBlock").
>
> thanks again,
> Greg

You'll really need to look closely at the thing you've copied with the
debugger...

On 14/01/2013 4:29 PM, Greg Jansen wrote:
> I have discovered a strange workaround for this issue. If I add a
> newly created MetadataBlock element to the diagram first, then add the
> copied one, then the edge is persisted without transient child
> references. So this issue seem to only occur when the copied element
> is the first element added to the containing ordered list. Note that I
> have three elements in my model that may contain these copied template
> objects. The issue occurs in two out of the three. The two containment
> features in which this occurs are ordered, but the one without issues
> is not ordered.

On 14/01/2013 5:00 PM, Greg Jansen wrote:
> Could this have something to do with the useOriginalReferences option,
> currently set to true?
Not likely.
> Would that mean the internal reference within the copied object would
> not be a copy somehow, but instead be the original EReference object?
> Perhaps that would explain the weird edge?
Copying walks the containment structure and produces copies for all
these things, building a map at the same time. When copyReferences is
called, it hooks up all the cross references. Before any such reference
is set in the copy, it checks if the referenced object is copied as well
and redirects the reference to that copy, rather than the original.
That should work well for your case...
>
> I have useOriginalReferences set to true b/c without that option I
> lose my other important references, the ones that refer to structural
> features in another model.
Yes, it will drop all references to things not in the copy, which is
definitely not what you want.

I ran the debugger and checked the copied object after the call the Copier.copyReferences(). The expected objects seem to have been copied and the reference between two objects contained there was intact, pointing to the copied object. So I think the result produced by Copier is completely fine. The problem seems to occur after that, when GMF creates the view to represent the cross-reference or perhaps later, when it attempts to persist that view.

<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Greg,<br>
<br>
Did you try this earlier suggestion?<br>
<blockquote>You might do so by setting a breakpoint in the setSource
method of an Edge (and perhaps make it conditional on
EcoreUtil.getURI(source).toString().contains("transientChildren").</blockquote>
<div class="moz-cite-prefix">You know about conditional
breakpoints? You need to find out when and why the edge referring
to an inappropriate thing is being created...<br>
<br>
<br>
On 16/01/2013 3:45 PM, Greg Jansen wrote:<br>
</div>
<blockquote cite="mid:kd6edi$kus$1@xxxxxxxxe.org" type="cite">I
ran the debugger and checked the copied object after the call the
Copier.copyReferences(). The expected objects seem to have been
copied and the reference between two objects contained there was
intact, pointing to the copied object. So I think the result
produced by Copier is completely fine. The problem seems to occur
after that, when GMF creates the view to represent the
cross-reference or perhaps later, when it attempts to persist that
view.
<br>
</blockquote>
<br>
</body>
</html>

Thanks again Ed, other deadlines took me away from this. I will try a breakpoint on Edge as soon as I find the source code plugin. When I import the likely SDK the jars contain no java files (or class files for this matter). I will keep at it and let you know what I discover.