|
|
| Re: Deserializing a serialized meta model that contains cross references [message #741113 is a reply to message #741073] |
Wed, 19 October 2011 07:33   |
 Ed Merks
Messages: 33133
Registered: July 2009 |
Senior Member |
|
|
Erdal,
Comments below.
On 19/10/2011 8:46 AM, Erdal Karaca wrote:
> I have two EPackages A and B located in two different model files
> (A.ecore and B.ecore).
> Class CA in package A contains a reference to Class CB in package B.
>
> I managed to deserialize both ecore files and generate appropriate
> EPackages (actually , this is done by CDO, but anyways...).
> The problem is that the reference to CB cannot be resolved as I think
> the URI is not constructed properly.
> In A.ecore, I can see that there is an embedded B.ecore file name,
> this is where the reference is made and may look like this:
>
> <eStructuralFeatures xsi:type="ecore:EReference" name="refToCB"
> lowerBound="1" eType="ecore:EClass B.ecore#//CB"
> eKeys="B.ecore#//CB/name"/>
Yes, relative references because that resource is in the same folder
(just as supported by HTML anchors and references).
>
> Now, this makes sense as both ecore files are located locally in my
> workspace in the same directory.
Yep.
> But, I need to load both and resolve all proxies in a "distributed
> environment", i.e. when I only have the ecore files which may be
> obtained from anywhere...
>
> This needs to be done to implement the feature request in bug
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=360940
What would you expect the URI to be?
>
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
|
| Re: Deserializing a serialized meta model that contains cross references [message #741149 is a reply to message #741116] |
Wed, 19 October 2011 08:21 |
Ed Merks
Messages: 33133
Registered: July 2009 |
Senior Member |
|
|
Erdal,
Comments below.
On 19/10/2011 9:39 AM, Erdal Karaca wrote:
> Ed Merks wrote on Wed, 19 October 2011 03:33
>> What would you expect the URI to be?
>
>
>
> I would expect that it would be constructed like this:
> package's namespace URI#Type
It will always use the URI of the containing resource so if you want
that, you should change the URI to be what you expect instead, or
fiddle with this option to swizzle things as you save:
/**
* A {@link URIHandler} value that will be used to control how URIs
are {@link URI#resolve(URI) resolved} during load
* and {@link URI#deresolve(URI) deresolved} during save.
* @see URI
* @see URIHandler
* @see XMLHelper#resolve(URI, URI)
* @see XMLHelper#deresolve(URI)
* @see URIHandlerImpl
*/
String OPTION_URI_HANDLER = "URI_HANDLER";
>
> Example: http://example.com/B#CB
>
> <eStructuralFeatures xsi:type="ecore:EReference" name="refToCB"
> lowerBound="1" eType="ecore:EClass http://example.com/B#//CB"
> eKeys="http://example.com/#B//CB/name"/>
>
> Wouldn't that make sense?
EMF won't generally be able to find that, so it doesn't generally make
sense. But if that's what you need/want, you'll have to take steps to
make it that way.
> At least, the other package is available in the package registry, so,
> the proxies should be resolvable...
But you're not referring to the instance in the package registry, you're
referring to the one in the workspace and they're actually two different
things...
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Powered by
FUDForum. Page generated in 0.02126 seconds
] 
Search
Help
Register
Login
Home
