Home » Modeling » EMF » Problem resolving EAnnotation references
| | | |
| Re: Problem resolving EAnnotation references [message #422814 is a reply to message #422811] |
Tue, 16 September 2008 10:09   |
 Ed Merks
Messages: 33138
Registered: July 2009 |
Senior Member |
|
|
Bryan,
I suspect that the only reason it isn't working is that the file you
reference ends up in a different relative location at runtime verses at
the time it's generated. I.e., I expect that if you put it in the same
folder as where the generated/serialized .ecore file is placed, it will
work properly. Anything beyond that maintaining the same relative
references requires more smarts in the builders, i.e., when the .ecore
is copied from the source folder to the bin folder, the relative
references it contains need to be correct also in the bin folder or they
need to be swizzled. Doing such swizzling is beyond the scope of what I
can try to tackle in EMF.
Bryan Hunt wrote:
> I worked around this problem by using strings to identify the model
> URI, and object within the model. I don't really like that solution,
> but it's working.
>
> Would this issue be worthy of a bugzilla? It seems to me that
> references in an EAnnotation should not have any special cases and
> that it should work like any other cross-model reference.
>
> Bryan
>
> On 2008-09-15 14:13:26 -0500, Bryan Hunt <bhunt@mac.com> said:
>
>> Setting Initialize by Loading is now giving me a proxy for the
>> referenced object. Looking in the debugger, the proxy URI is:
>>
>> eProxyURI:
>> bundleresource://2/../junit.source#//@localTables.0/@localCo lumns[name='ID']
>>
>
> From
> here,
>>
>> it tries to find the package using bundleresource://2/../junit.source
>> which doesn't exist in the package registry.
>>
>>
>> The reference in the ecore is:
>> references="../junit.source#//@localTables.0/@localColumns[name='ID'] "
>>
>> Any suggestions on how to get the URI to resolve to the right thing?
>>
>> Bryan
>>
>> On 2008-09-15 13:43:19 -0500, Ed Merks <Ed.Merks@gmail.com> said:
>>
>>> Bryan,
>>>
>>> Comments below.
>>>
>>>
>>> Bryan Hunt wrote:
>>>> I have a model with annotations, and those annotations each have a
>>>> reference to an object in another model (serialized as a file in
>>>> the plugin) that I created. When I load the model with annotations
>>>> and attempt to get the referenced object by calling:
>>>>
>>>> annotation.getReferences.get(0)
>>>>
>>>> I'm getting an index exception because the references list has size
>>>> == 0. Are there any key breakpoints I can set to figure out why
>>>> the references are not getting resolved?
>>> The generated code for building an XyzPackageImpl doesn't handle
>>> EAnnotation's with information beyond just the source and the
>>> details entries. But you can configure the GenPackage to use
>>> "Initialize by Loading" for fancier stuff. Not sure if the relative
>>> references will work properly though. You're again doing something
>>> a little different...
>>>>
>>>>
>>>>
>>>> Bryan
>
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Problem resolving EAnnotation references [message #422831 is a reply to message #422814] |
Tue, 16 September 2008 18:01 |
Bryan Hunt
Messages: 366
Registered: July 2009 |
Senior Member |
|
|
Ed,
I don't think this will work in all cases for me. I will probably have
the model referenced by more than one ecore from different bundles.
How about if I created the model (the one I want to reference in an
EAnnotation), then deployed it in a plugin in my developement
environment that would also get depolyed in my runtime application, I
think I would then have a consistent uri. Does that sound like it
might work? I would then have to decide on the pain of delplying a
runtime model into my development environment vs using non-type-safe
strings to locate the model.
On 2008-09-16 05:09:39 -0500, Ed Merks <Ed.Merks@gmail.com> said:
> Bryan,
>
> I suspect that the only reason it isn't working is that the file you
> reference ends up in a different relative location at runtime verses at
> the time it's generated. I.e., I expect that if you put it in the same
> folder as where the generated/serialized .ecore file is placed, it will
> work properly. Anything beyond that maintaining the same relative
> references requires more smarts in the builders, i.e., when the .ecore
> is copied from the source folder to the bin folder, the relative
> references it contains need to be correct also in the bin folder or
> they need to be swizzled. Doing such swizzling is beyond the scope of
> what I can try to tackle in EMF.
>
>
> Bryan Hunt wrote:
>> I worked around this problem by using strings to identify the model
>> URI, and object within the model. I don't really like that solution,
>> but it's working.
>>
>> Would this issue be worthy of a bugzilla? It seems to me that
>> references in an EAnnotation should not have any special cases and that
>> it should work like any other cross-model reference.
>>
>> Bryan
>>
>> On 2008-09-15 14:13:26 -0500, Bryan Hunt <bhunt@mac.com> said:
>>
>>> Setting Initialize by Loading is now giving me a proxy for the
>>> referenced object. Looking in the debugger, the proxy URI is:
>>>
>>> eProxyURI:
>>> bundleresource://2/../junit.source#//@localTables.0/@localCo lumns[name='ID']
From
here,
it
>>>
>>> tries to find the package using bundleresource://2/../junit.source
>>> which doesn't exist in the package registry.
>>>
>>>
>>> The reference in the ecore is:
>>> references="../junit.source#//@localTables.0/@localColumns[name='ID'] "
>>>
>>> Any suggestions on how to get the URI to resolve to the right thing?
>>>
>>> Bryan
>>>
>>> On 2008-09-15 13:43:19 -0500, Ed Merks <Ed.Merks@gmail.com> said:
>>>
>>>> Bryan,
>>>>
>>>> Comments below.
>>>>
>>>>
>>>> Bryan Hunt wrote:
>>>>> I have a model with annotations, and those annotations each have a
>>>>> reference to an object in another model (serialized as a file in the
>>>>> plugin) that I created. When I load the model with annotations and
>>>>> attempt to get the referenced object by calling:
>>>>>
>>>>> annotation.getReferences.get(0)
>>>>>
>>>>> I'm getting an index exception because the references list has size ==
>>>>> 0. Are there any key breakpoints I can set to figure out why the
>>>>> references are not getting resolved?
>>>> The generated code for building an XyzPackageImpl doesn't handle
>>>> EAnnotation's with information beyond just the source and the details
>>>> entries. But you can configure the GenPackage to use "Initialize by
>>>> Loading" for fancier stuff. Not sure if the relative references will
>>>> work properly though. You're again doing something a little
>>>> different...
>>>>>
>>>>>
>>>>>
>>>>> Bryan
|
|
|
| Re: Problem resolving EAnnotation references [message #422837 is a reply to message #422831] |
Wed, 17 September 2008 05:51 |
Ed Merks
Messages: 33138
Registered: July 2009 |
Senior Member |
|
|
Bryan,
That sounds like it would work...
Bryan Hunt wrote:
> Ed,
>
> I don't think this will work in all cases for me. I will probably
> have the model referenced by more than one ecore from different
> bundles. How about if I created the model (the one I want to
> reference in an EAnnotation), then deployed it in a plugin in my
> developement environment that would also get depolyed in my runtime
> application, I think I would then have a consistent uri. Does that
> sound like it might work? I would then have to decide on the pain of
> delplying a runtime model into my development environment vs using
> non-type-safe strings to locate the model.
>
>
> On 2008-09-16 05:09:39 -0500, Ed Merks <Ed.Merks@gmail.com> said:
>
>> Bryan,
>>
>> I suspect that the only reason it isn't working is that the file you
>> reference ends up in a different relative location at runtime verses
>> at the time it's generated. I.e., I expect that if you put it in the
>> same folder as where the generated/serialized .ecore file is placed,
>> it will work properly. Anything beyond that maintaining the same
>> relative references requires more smarts in the builders, i.e., when
>> the .ecore is copied from the source folder to the bin folder, the
>> relative references it contains need to be correct also in the bin
>> folder or they need to be swizzled. Doing such swizzling is beyond
>> the scope of what I can try to tackle in EMF.
>>
>>
>> Bryan Hunt wrote:
>>> I worked around this problem by using strings to identify the model
>>> URI, and object within the model. I don't really like that
>>> solution, but it's working.
>>>
>>> Would this issue be worthy of a bugzilla? It seems to me that
>>> references in an EAnnotation should not have any special cases and
>>> that it should work like any other cross-model reference.
>>>
>>> Bryan
>>>
>>> On 2008-09-15 14:13:26 -0500, Bryan Hunt <bhunt@mac.com> said:
>>>
>>>> Setting Initialize by Loading is now giving me a proxy for the
>>>> referenced object. Looking in the debugger, the proxy URI is:
>>>>
>>>> eProxyURI:
>>>> bundleresource://2/../junit.source#//@localTables.0/@localCo lumns[name='ID']
>>>>
>
> From
> here,
>
> it
>>>>
>>>> tries to find the package using bundleresource://2/../junit.source
>>>> which doesn't exist in the package registry.
>>>>
>>>>
>>>> The reference in the ecore is:
>>>> references="../junit.source#//@localTables.0/@localColumns[name='ID'] "
>>>>
>>>> Any suggestions on how to get the URI to resolve to the right thing?
>>>>
>>>> Bryan
>>>>
>>>> On 2008-09-15 13:43:19 -0500, Ed Merks <Ed.Merks@gmail.com> said:
>>>>
>>>>> Bryan,
>>>>>
>>>>> Comments below.
>>>>>
>>>>>
>>>>> Bryan Hunt wrote:
>>>>>> I have a model with annotations, and those annotations each have
>>>>>> a reference to an object in another model (serialized as a file
>>>>>> in the plugin) that I created. When I load the model with
>>>>>> annotations and attempt to get the referenced object by calling:
>>>>>>
>>>>>> annotation.getReferences.get(0)
>>>>>>
>>>>>> I'm getting an index exception because the references list has
>>>>>> size == 0. Are there any key breakpoints I can set to figure out
>>>>>> why the references are not getting resolved?
>>>>> The generated code for building an XyzPackageImpl doesn't handle
>>>>> EAnnotation's with information beyond just the source and the
>>>>> details entries. But you can configure the GenPackage to use
>>>>> "Initialize by Loading" for fancier stuff. Not sure if the
>>>>> relative references will work properly though. You're again doing
>>>>> something a little different...
>>>>>>
>>>>>>
>>>>>>
>>>>>> Bryan
>
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Problem resolving EAnnotation references [message #422871 is a reply to message #422837] |
Wed, 17 September 2008 18:53 |
Bryan Hunt
Messages: 366
Registered: July 2009 |
Senior Member |
|
|
Well, it's not working. I think the reason that it's not working is
when EcoreUtil.resolve() gets called, the objectContext is an
EAnnotationImpl. The resource for the EAnnotationImpl is an
EcoreResourcefactoryImpl$1 which has no resourceSet, and since the
proxy is not a reference to a package, the proxy resolution fails. Is
there any way to work around this?
Bryan
On 2008-09-17 00:51:44 -0500, Ed Merks <Ed.Merks@gmail.com> said:
> Bryan,
>
> That sounds like it would work...
>
>
> Bryan Hunt wrote:
>> Ed,
>>
>> I don't think this will work in all cases for me. I will probably have
>> the model referenced by more than one ecore from different bundles.
>> How about if I created the model (the one I want to reference in an
>> EAnnotation), then deployed it in a plugin in my developement
>> environment that would also get depolyed in my runtime application, I
>> think I would then have a consistent uri. Does that sound like it
>> might work? I would then have to decide on the pain of delplying a
>> runtime model into my development environment vs using non-type-safe
>> strings to locate the model.
>>
>>
>> On 2008-09-16 05:09:39 -0500, Ed Merks <Ed.Merks@gmail.com> said:
>>
>>> Bryan,
>>>
>>> I suspect that the only reason it isn't working is that the file you
>>> reference ends up in a different relative location at runtime verses at
>>> the time it's generated. I.e., I expect that if you put it in the same
>>> folder as where the generated/serialized .ecore file is placed, it will
>>> work properly. Anything beyond that maintaining the same relative
>>> references requires more smarts in the builders, i.e., when the .ecore
>>> is copied from the source folder to the bin folder, the relative
>>> references it contains need to be correct also in the bin folder or
>>> they need to be swizzled. Doing such swizzling is beyond the scope of
>>> what I can try to tackle in EMF.
>>>
>>>
>>> Bryan Hunt wrote:
>>>> I worked around this problem by using strings to identify the model
>>>> URI, and object within the model. I don't really like that solution,
>>>> but it's working.
>>>>
>>>> Would this issue be worthy of a bugzilla? It seems to me that
>>>> references in an EAnnotation should not have any special cases and that
>>>> it should work like any other cross-model reference.
>>>>
>>>> Bryan
>>>>
>>>> On 2008-09-15 14:13:26 -0500, Bryan Hunt <bhunt@mac.com> said:
>>>>
>>>>> Setting Initialize by Loading is now giving me a proxy for the
>>>>> referenced object. Looking in the debugger, the proxy URI is:
>>>>>
>>>>> eProxyURI:
>>>>> bundleresource://2/../junit.source#//@localTables.0/@localCo lumns[name='ID']
From
here,
it
tries
>>>>>
>>>>> to find the package using bundleresource://2/../junit.source which
>>>>> doesn't exist in the package registry.
>>>>>
>>>>>
>>>>> The reference in the ecore is:
>>>>> references="../junit.source#//@localTables.0/@localColumns[name='ID'] "
>>>>>
>>>>> Any suggestions on how to get the URI to resolve to the right thing?
>>>>>
>>>>> Bryan
>>>>>
>>>>> On 2008-09-15 13:43:19 -0500, Ed Merks <Ed.Merks@gmail.com> said:
>>>>>
>>>>>> Bryan,
>>>>>>
>>>>>> Comments below.
>>>>>>
>>>>>>
>>>>>> Bryan Hunt wrote:
>>>>>>> I have a model with annotations, and those annotations each have a
>>>>>>> reference to an object in another model (serialized as a file in the
>>>>>>> plugin) that I created. When I load the model with annotations and
>>>>>>> attempt to get the referenced object by calling:
>>>>>>>
>>>>>>> annotation.getReferences.get(0)
>>>>>>>
>>>>>>> I'm getting an index exception because the references list has size ==
>>>>>>> 0. Are there any key breakpoints I can set to figure out why the
>>>>>>> references are not getting resolved?
>>>>>> The generated code for building an XyzPackageImpl doesn't handle
>>>>>> EAnnotation's with information beyond just the source and the details
>>>>>> entries. But you can configure the GenPackage to use "Initialize by
>>>>>> Loading" for fancier stuff. Not sure if the relative references will
>>>>>> work properly though. You're again doing something a little
>>>>>> different...
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Bryan
|
|
|
| Re: Problem resolving EAnnotation references [message #422872 is a reply to message #422871] |
Wed, 17 September 2008 19:06 |
Ed Merks
Messages: 33138
Registered: July 2009 |
Senior Member |
|
|
Bryan,
Hmmm. Yes, that's a tricky issue. The underlying implementation
assumption has been that all proxies are resolved via the package
registry... Supporting something more than this will require some
infrastructure changes. The loaded resources would need to share a
resource set, for example... Is that why it's been failing all long?
We could look into improvements in 2.5, although I'm getting the feeling
that the ability to contain the feature requests is being outpaced of
late...
Bryan Hunt wrote:
> Well, it's not working. I think the reason that it's not working is
> when EcoreUtil.resolve() gets called, the objectContext is an
> EAnnotationImpl. The resource for the EAnnotationImpl is an
> EcoreResourcefactoryImpl$1 which has no resourceSet, and since the
> proxy is not a reference to a package, the proxy resolution fails. Is
> there any way to work around this?
>
> Bryan
>
> On 2008-09-17 00:51:44 -0500, Ed Merks <Ed.Merks@gmail.com> said:
>
>> Bryan,
>>
>> That sounds like it would work...
>>
>>
>> Bryan Hunt wrote:
>>> Ed,
>>>
>>> I don't think this will work in all cases for me. I will probably
>>> have the model referenced by more than one ecore from different
>>> bundles. How about if I created the model (the one I want to
>>> reference in an EAnnotation), then deployed it in a plugin in my
>>> developement environment that would also get depolyed in my runtime
>>> application, I think I would then have a consistent uri. Does that
>>> sound like it might work? I would then have to decide on the pain
>>> of delplying a runtime model into my development environment vs
>>> using non-type-safe strings to locate the model.
>>>
>>>
>>> On 2008-09-16 05:09:39 -0500, Ed Merks <Ed.Merks@gmail.com> said:
>>>
>>>> Bryan,
>>>>
>>>> I suspect that the only reason it isn't working is that the file
>>>> you reference ends up in a different relative location at runtime
>>>> verses at the time it's generated. I.e., I expect that if you put
>>>> it in the same folder as where the generated/serialized .ecore file
>>>> is placed, it will work properly. Anything beyond that maintaining
>>>> the same relative references requires more smarts in the builders,
>>>> i.e., when the .ecore is copied from the source folder to the bin
>>>> folder, the relative references it contains need to be correct also
>>>> in the bin folder or they need to be swizzled. Doing such
>>>> swizzling is beyond the scope of what I can try to tackle in EMF.
>>>>
>>>>
>>>> Bryan Hunt wrote:
>>>>> I worked around this problem by using strings to identify the
>>>>> model URI, and object within the model. I don't really like that
>>>>> solution, but it's working.
>>>>>
>>>>> Would this issue be worthy of a bugzilla? It seems to me that
>>>>> references in an EAnnotation should not have any special cases and
>>>>> that it should work like any other cross-model reference.
>>>>>
>>>>> Bryan
>>>>>
>>>>> On 2008-09-15 14:13:26 -0500, Bryan Hunt <bhunt@mac.com> said:
>>>>>
>>>>>> Setting Initialize by Loading is now giving me a proxy for the
>>>>>> referenced object. Looking in the debugger, the proxy URI is:
>>>>>>
>>>>>> eProxyURI:
>>>>>> bundleresource://2/../junit.source#//@localTables.0/@localCo lumns[name='ID']
>>>>>>
>
> From
> here,
>
> it
>
> tries
>>>>>>
>>>>>> to find the package using bundleresource://2/../junit.source
>>>>>> which doesn't exist in the package registry.
>>>>>>
>>>>>>
>>>>>> The reference in the ecore is:
>>>>>> references="../junit.source#//@localTables.0/@localColumns[name='ID'] "
>>>>>>
>>>>>>
>>>>>> Any suggestions on how to get the URI to resolve to the right thing?
>>>>>>
>>>>>> Bryan
>>>>>>
>>>>>> On 2008-09-15 13:43:19 -0500, Ed Merks <Ed.Merks@gmail.com> said:
>>>>>>
>>>>>>> Bryan,
>>>>>>>
>>>>>>> Comments below.
>>>>>>>
>>>>>>>
>>>>>>> Bryan Hunt wrote:
>>>>>>>> I have a model with annotations, and those annotations each
>>>>>>>> have a reference to an object in another model (serialized as a
>>>>>>>> file in the plugin) that I created. When I load the model with
>>>>>>>> annotations and attempt to get the referenced object by calling:
>>>>>>>>
>>>>>>>> annotation.getReferences.get(0)
>>>>>>>>
>>>>>>>> I'm getting an index exception because the references list has
>>>>>>>> size == 0. Are there any key breakpoints I can set to figure
>>>>>>>> out why the references are not getting resolved?
>>>>>>> The generated code for building an XyzPackageImpl doesn't handle
>>>>>>> EAnnotation's with information beyond just the source and the
>>>>>>> details entries. But you can configure the GenPackage to use
>>>>>>> "Initialize by Loading" for fancier stuff. Not sure if the
>>>>>>> relative references will work properly though. You're again
>>>>>>> doing something a little different...
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Bryan
>
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Problem resolving EAnnotation references [message #422878 is a reply to message #422872] |
Wed, 17 September 2008 20:46 |
Bryan Hunt
Messages: 366
Registered: July 2009 |
Senior Member |
|
|
Ed,
I've discovered a more fundamental problem with what I'm trying to do,
so I've changed the design to avoid this situation. Annotation
references might be a good topic for discussion over a beer sometime.
And, yes, the two models are not sharing a resource set, and that's the
root cause of the problem.
On 2008-09-17 14:06:28 -0500, Ed Merks <Ed.Merks@gmail.com> said:
> Bryan,
>
> Hmmm. Yes, that's a tricky issue. The underlying implementation
> assumption has been that all proxies are resolved via the package
> registry... Supporting something more than this will require some
> infrastructure changes. The loaded resources would need to share a
> resource set, for example... Is that why it's been failing all long?
> We could look into improvements in 2.5, although I'm getting the
> feeling that the ability to contain the feature requests is being
> outpaced of late...
>
>
> Bryan Hunt wrote:
>> Well, it's not working. I think the reason that it's not working is
>> when EcoreUtil.resolve() gets called, the objectContext is an
>> EAnnotationImpl. The resource for the EAnnotationImpl is an
>> EcoreResourcefactoryImpl$1 which has no resourceSet, and since the
>> proxy is not a reference to a package, the proxy resolution fails. Is
>> there any way to work around this?
>>
>> Bryan
>>
>> On 2008-09-17 00:51:44 -0500, Ed Merks <Ed.Merks@gmail.com> said:
>>
>>> Bryan,
>>>
>>> That sounds like it would work...
>>>
>>>
>>> Bryan Hunt wrote:
>>>> Ed,
>>>>
>>>> I don't think this will work in all cases for me. I will probably have
>>>> the model referenced by more than one ecore from different bundles.
>>>> How about if I created the model (the one I want to reference in an
>>>> EAnnotation), then deployed it in a plugin in my developement
>>>> environment that would also get depolyed in my runtime application, I
>>>> think I would then have a consistent uri. Does that sound like it
>>>> might work? I would then have to decide on the pain of delplying a
>>>> runtime model into my development environment vs using non-type-safe
>>>> strings to locate the model.
>>>>
>>>>
>>>> On 2008-09-16 05:09:39 -0500, Ed Merks <Ed.Merks@gmail.com> said:
>>>>
>>>>> Bryan,
>>>>>
>>>>> I suspect that the only reason it isn't working is that the file you
>>>>> reference ends up in a different relative location at runtime verses at
>>>>> the time it's generated. I.e., I expect that if you put it in the same
>>>>> folder as where the generated/serialized .ecore file is placed, it will
>>>>> work properly. Anything beyond that maintaining the same relative
>>>>> references requires more smarts in the builders, i.e., when the .ecore
>>>>> is copied from the source folder to the bin folder, the relative
>>>>> references it contains need to be correct also in the bin folder or
>>>>> they need to be swizzled. Doing such swizzling is beyond the scope of
>>>>> what I can try to tackle in EMF.
>>>>>
>>>>>
>>>>> Bryan Hunt wrote:
>>>>>> I worked around this problem by using strings to identify the model
>>>>>> URI, and object within the model. I don't really like that solution,
>>>>>> but it's working.
>>>>>>
>>>>>> Would this issue be worthy of a bugzilla? It seems to me that
>>>>>> references in an EAnnotation should not have any special cases and that
>>>>>> it should work like any other cross-model reference.
>>>>>>
>>>>>> Bryan
>>>>>>
>>>>>> On 2008-09-15 14:13:26 -0500, Bryan Hunt <bhunt@mac.com> said:
>>>>>>
>>>>>>> Setting Initialize by Loading is now giving me a proxy for the
>>>>>>> referenced object. Looking in the debugger, the proxy URI is:
>>>>>>>
>>>>>>> eProxyURI:
>>>>>>> bundleresource://2/../junit.source#//@localTables.0/@localCo lumns[name='ID']
From
here,
it
tries
to
>>>>>>>
>>>>>>> find the package using bundleresource://2/../junit.source which doesn't
>>>>>>> exist in the package registry.
>>>>>>>
>>>>>>>
>>>>>>> The reference in the ecore is:
>>>>>>> references="../junit.source#//@localTables.0/@localColumns[name='ID'] "
>>>>>>>
>>>>>>> Any suggestions on how to get the URI to resolve to the right thing?
>>>>>>>
>>>>>>> Bryan
>>>>>>>
>>>>>>> On 2008-09-15 13:43:19 -0500, Ed Merks <Ed.Merks@gmail.com> said:
>>>>>>>
>>>>>>>> Bryan,
>>>>>>>>
>>>>>>>> Comments below.
>>>>>>>>
>>>>>>>>
>>>>>>>> Bryan Hunt wrote:
>>>>>>>>> I have a model with annotations, and those annotations each have a
>>>>>>>>> reference to an object in another model (serialized as a file in the
>>>>>>>>> plugin) that I created. When I load the model with annotations and
>>>>>>>>> attempt to get the referenced object by calling:
>>>>>>>>>
>>>>>>>>> annotation.getReferences.get(0)
>>>>>>>>>
>>>>>>>>> I'm getting an index exception because the references list has size ==
>>>>>>>>> 0. Are there any key breakpoints I can set to figure out why the
>>>>>>>>> references are not getting resolved?
>>>>>>>> The generated code for building an XyzPackageImpl doesn't handle
>>>>>>>> EAnnotation's with information beyond just the source and the details
>>>>>>>> entries. But you can configure the GenPackage to use "Initialize by
>>>>>>>> Loading" for fancier stuff. Not sure if the relative references will
>>>>>>>> work properly though. You're again doing something a little
>>>>>>>> different...
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Bryan
|
|
|
Goto Forum:
Current Time: Sat Apr 20 08:50:03 GMT 2024
Powered by FUDForum. Page generated in 0.04129 seconds |
] 
Search
Help
Register
Login
Home
