Community
Participate
Working Groups
Since commit 78e1c324c06816ca50cb2947c7e582103757bd4d "[458349] Consolidate UI" CDOResourceImpl inherits of XMLResource [1]. After talk with Eike, this change has been done for CDO/Papyrus integration, more specifically about GMF integration. In our CDO based application, we use also GMF with CDO and we know that GMF has been designed to work specifically with XMLResource. From this fact we have overriden and/or remplaced XMLResource specific code in GMF by our own generic code to have GMF work with XMLResource and CDOResource. We cannot integrate this change in our products because it is too impacting, indeed we and our customers do often "resource instanceof XMLResource" test to do XML specific staff, like for example XMI migration or parsing. In addition I don't see advantages having CDOResourceImpl implements XMLResource with most default methods implementations throwing UnsupportedOperationException because CDO and XML are not related. This bugzilla is to track this issue and give a solution. [1] https://git.eclipse.org/r/#/c/46583/6/plugins/org.eclipse.emf.cdo/src/org/eclipse/emf/spi/cdo/InternalCDOResource.java
Generally you can't require that any class does not implement a public interface that's meant to be implemented. You could argue that all non-optional methods of that interface be implemented correctly according to the API contract, but that wouldn't help you, either, because you still wouldn't want to use the XML-specific methods on a CDOResource. In your case it would be best to test if the URI of the resource is a file: URI rather than a cdo: URI. But you're not asking to implement all XMLResource method in CDOResourceImpl. The only reason that would justify the removal of the XMLResource interface from CDOResourceImpl is that GMF removes their assumption that all resources are XMLResources and we can't do that through a bugzilla against CDO. (In reply to Esteban DUGUEPEROUX from comment #0) > Since commit 78e1c324c06816ca50cb2947c7e582103757bd4d "[458349] Consolidate > UI" CDOResourceImpl inherits of XMLResource [1]. > > After talk with Eike, this change has been done for CDO/Papyrus integration, > more specifically about GMF integration. > In our CDO based application, we use also GMF with CDO and we know that GMF > has been designed to work specifically with XMLResource. > From this fact we have overriden and/or remplaced XMLResource specific code > in GMF by our own generic code to have GMF work with XMLResource and > CDOResource. I suggest that this be fixed in GMF directly. I think that GMF mostly wants to reuse some ID functionality from XMLResource and that might be done in a more flexible way. Can you point me to a bugzilla against GMF that asks for that? > We cannot integrate this change in our products because it is too impacting, > indeed we and our customers do often "resource instanceof XMLResource" test > to do XML specific staff, like for example XMI migration or parsing. Whether you integrate this change into your product or not is up to you of course, but I think you'd be better off to check the URI and not the implementation class of a resource. Another option is to do the instanceof check against XMLResourceImpl instead of XMLResource. Notice that that would break if we decide in CDO to extend XMLResourceImpl rather than implement XMLResource. > In addition I don't see advantages having CDOResourceImpl implements > XMLResource with most default methods implementations throwing > UnsupportedOperationException because CDO and XML are not related. The advantage of a CDOResourceImpl that implements XMLResource is obvious if you use GMF over CDO. And it's not a question of whether CDO and XML are related or not. People might want to export their CDO models in XML format by virtue of using a non-cdo: URI with their CDOResourceImpl, which I discussed with Ed some time ago. > This bugzilla is to track this issue and give a solution. For this bugzilla a see two options: 1) You change it to an enhancement request in order to implement the XMLResource methods correctly (for example by extending XMLResourceImpl) and make the non-XMLResource methods URI scheme-aware, or 2) You fix the original problem in GMF and mark this bugzilla depending on the respective GMF-bugzilla, or 3) We close this bugzilla as wontfix.
Moving all open bugzillas to 4.5.
Moving all unaddressed bugzillas to 4.6.
Moving all open bugs to 4.7
Moving all unresolved issues to version 4.8-
Moving all unresolved issues to version 4.9
Moving to 4.13.
