Home » Modeling » EMF » multiple namespaces in one editor supported?
| | |
| Re: multiple namespaces in one editor supported? [message #411930 is a reply to message #411926] |
Fri, 10 August 2007 12:04   |
 Rene Ladan
Messages: 51
Registered: July 2009 |
Member |
|
|
Hi Ed,
your suggestion works fine.
Thanks,
Rene
Ed Merks wrote:
> Rene,
>
> The error log doesn't show anything useful. Perhaps the problem would
> be solved simply by registering A for both namespaces, e.g.,
>
> <extension point="org.eclipse.emf.ecore.generated_package">
> <package
> uri = "http://www.example.com/OldLibrary"
> class = "com.example.library.LibraryPackage"
> </extension>
>
> <extension point="org.eclipse.emf.ecore.generated_package">
> <package
> uri = "http://www.example.com/Library"
> class = "com.example.library.LibraryPackage"
> genModel = "model/library.genmodel" />
> </extension>
>
>
> Rene Ladan wrote:
>> Rene Ladan wrote:
>>> Hi,
>>>
>>> say I have metamodel A with namespace http://mm.A/ which is a
>>> superset of metamodel B with namespace http://mm.B/ .
>>>
>>> If I generate an EMF editor using namespace A, it can by default not
>>> read legacy files which were serialized using namespace B, unless I
>>> manually edit the files to point to namespace A.
>>>
>>> Is there a way to support both namespaces in the same editor? An
>>> alternative would be to rename namespace A to B and regenerate the
>>> editor (and merge all the manual code...). The legacy files cannot
>>> be changed since they have to work with another EMF tool.
>>>
>> Forgot to attach the error log...
>>
>>> Regards,
>>> Rene
>>
|
|
|
| Re: multiple namespaces in one editor supported? [message #411959 is a reply to message #411926] |
Mon, 13 August 2007 11:37 |
Rene Ladan
Messages: 51
Registered: July 2009 |
Member |
|
|
Hi all,
I've added Eds suggestion and some further experiences to the new EMF
recipe wiki.
Regards,
Rene
Ed Merks wrote:
> Rene,
>
> [...] Perhaps the problem would
> be solved simply by registering A for both namespaces, e.g.,
>
> <extension point="org.eclipse.emf.ecore.generated_package">
> <package
> uri = "http://www.example.com/OldLibrary"
> class = "com.example.library.LibraryPackage"
> </extension>
>
> <extension point="org.eclipse.emf.ecore.generated_package">
> <package
> uri = "http://www.example.com/Library"
> class = "com.example.library.LibraryPackage"
> genModel = "model/library.genmodel" />
> </extension>
>
>
> Rene Ladan wrote:
>> Rene Ladan wrote:
>>> Hi,
>>>
>>> say I have metamodel A with namespace http://mm.A/ which is a
>>> superset of metamodel B with namespace http://mm.B/ .
>>>
>>> If I generate an EMF editor using namespace A, it can by default not
>>> read legacy files which were serialized using namespace B, unless I
>>> manually edit the files to point to namespace A.
>>>
>>> Is there a way to support both namespaces in the same editor? An
>>> alternative would be to rename namespace A to B and regenerate the
>>> editor (and merge all the manual code...). The legacy files cannot
>>> be changed since they have to work with another EMF tool.
>>>
[...]
>>> Regards,
>>> Rene
>>
|
|
|
| Re: multiple namespaces in one editor supported? [message #423530 is a reply to message #411959] |
Wed, 01 October 2008 19:44 |
Vasanth Velusamy
Messages: 31
Registered: July 2009 |
Member |
|
|
Ed,
I am trying to register multiple uris to the same package. As you had
described in this thread, and yet another thread, I included an
additional extension contribution (for
org.eclipse.emf.ecore.generated_package) for a new uri, but that didn't
seem to be enough. When I attempted to open a file with the new
namespace, I received a FeatureNotFoundException (full stack trace in
attachement). Without this contribution, I received an exception similar
to what the thread owner received initially (AssertionFailedException).
So I would assume that the new extension contribution is being used.
I did a search for the old namespace in all three projects (model, edit
and editor) and found them used in the following places:
* my schema file
* my ecore file
* XXXFactoryImpl.java
* XXXPackage.java
* plugin.xml in model project
* plugin.xml in edit project (used in contributing to extension point
org.eclipse.emf.edit.itemProviderAdapterFactories. Should there be
additional contributions for the new URI here as well? I tried it but
didn't seem to help.)
I changed XXXPackage.eNS_URI to point to the new URI. Obviously, with
this change, the editor worked for the new URI but not the old URI.
So, I am wondering if I am missing any additional step to get the editor
to work with multiple uris, or if something broke. For example, should I
have another ecore for the new namespace? I am using EMF 2.3.1.
Thanks,
Vasanth
Rene Ladan wrote:
> Hi all,
>
> I've added Eds suggestion and some further experiences to the new EMF
> recipe wiki.
>
> Regards,
> Rene
>
> Ed Merks wrote:
>> Rene,
>>
>> [...] Perhaps the problem would be solved simply by registering A for
>> both namespaces, e.g.,
>>
>> <extension point="org.eclipse.emf.ecore.generated_package">
>> <package
>> uri = "http://www.example.com/OldLibrary"
>> class = "com.example.library.LibraryPackage"
>> </extension>
>>
>> <extension point="org.eclipse.emf.ecore.generated_package">
>> <package
>> uri = "http://www.example.com/Library"
>> class = "com.example.library.LibraryPackage"
>> genModel = "model/library.genmodel" />
>> </extension>
>>
>>
>> Rene Ladan wrote:
>>> Rene Ladan wrote:
>>>> Hi,
>>>>
>>>> say I have metamodel A with namespace http://mm.A/ which is a
>>>> superset of metamodel B with namespace http://mm.B/ .
>>>>
>>>> If I generate an EMF editor using namespace A, it can by default not
>>>> read legacy files which were serialized using namespace B, unless I
>>>> manually edit the files to point to namespace A.
>>>>
>>>> Is there a way to support both namespaces in the same editor? An
>>>> alternative would be to rename namespace A to B and regenerate the
>>>> editor (and merge all the manual code...). The legacy files cannot
>>>> be changed since they have to work with another EMF tool.
>>>>
> [...]
>>>> Regards,
>>>> Rene
>>>
|
|
|
| Re: multiple namespaces in one editor supported? [message #423532 is a reply to message #423530] |
Wed, 01 October 2008 19:47 |
Vasanth Velusamy
Messages: 31
Registered: July 2009 |
Member |
|
|
This is a multi-part message in MIME format.
--------------030407000700030301020806
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Adding missing attachment.
-Vasanth
Vasanth Velusamy wrote:
> Ed,
>
> I am trying to register multiple uris to the same package. As you had
> described in this thread, and yet another thread, I included an
> additional extension contribution (for
> org.eclipse.emf.ecore.generated_package) for a new uri, but that didn't
> seem to be enough. When I attempted to open a file with the new
> namespace, I received a FeatureNotFoundException (full stack trace in
> attachement). Without this contribution, I received an exception similar
> to what the thread owner received initially (AssertionFailedException).
> So I would assume that the new extension contribution is being used.
>
> I did a search for the old namespace in all three projects (model, edit
> and editor) and found them used in the following places:
>
> * my schema file
> * my ecore file
> * XXXFactoryImpl.java
> * XXXPackage.java
> * plugin.xml in model project
> * plugin.xml in edit project (used in contributing to extension point
> org.eclipse.emf.edit.itemProviderAdapterFactories. Should there be
> additional contributions for the new URI here as well? I tried it but
> didn't seem to help.)
>
> I changed XXXPackage.eNS_URI to point to the new URI. Obviously, with
> this change, the editor worked for the new URI but not the old URI.
>
> So, I am wondering if I am missing any additional step to get the editor
> to work with multiple uris, or if something broke. For example, should I
> have another ecore for the new namespace? I am using EMF 2.3.1.
>
> Thanks,
> Vasanth
>
>
> Rene Ladan wrote:
>> Hi all,
>>
>> I've added Eds suggestion and some further experiences to the new EMF
>> recipe wiki.
>>
>> Regards,
>> Rene
>>
>> Ed Merks wrote:
>>> Rene,
>>>
>>> [...] Perhaps the problem would be solved simply by registering A
>>> for both namespaces, e.g.,
>>>
>>> <extension point="org.eclipse.emf.ecore.generated_package">
>>> <package
>>> uri = "http://www.example.com/OldLibrary"
>>> class = "com.example.library.LibraryPackage"
>>> </extension>
>>>
>>> <extension point="org.eclipse.emf.ecore.generated_package">
>>> <package
>>> uri = "http://www.example.com/Library"
>>> class = "com.example.library.LibraryPackage"
>>> genModel = "model/library.genmodel" />
>>> </extension>
>>>
>>>
>>> Rene Ladan wrote:
>>>> Rene Ladan wrote:
>>>>> Hi,
>>>>>
>>>>> say I have metamodel A with namespace http://mm.A/ which is a
>>>>> superset of metamodel B with namespace http://mm.B/ .
>>>>>
>>>>> If I generate an EMF editor using namespace A, it can by default
>>>>> not read legacy files which were serialized using namespace B,
>>>>> unless I manually edit the files to point to namespace A.
>>>>>
>>>>> Is there a way to support both namespaces in the same editor? An
>>>>> alternative would be to rename namespace A to B and regenerate the
>>>>> editor (and merge all the manual code...). The legacy files cannot
>>>>> be changed since they have to work with another EMF tool.
>>>>>
>> [...]
>>>>> Regards,
>>>>> Rene
>>>>
--------------030407000700030301020806
Content-Type: text/plain;
name="FeatureNotFoundException.txt"
Content-Transfer-Encoding: base64
Content-Disposition: inline;
filename="FeatureNotFoundException.txt"
b3JnLmVjbGlwc2UuZW1mLmVjb3JlLnhtaS5GZWF0dXJlTm90Rm91bmRFeGNl cHRpb246IEZl
YXR1cmUgJ3NhbXBsZScgbm90IGZvdW5kLiAocGxhdGZvcm06L3Jlc291cmNl L3NhbmRib3gx
L015TmV3LnNhbXBsZXYxLCAyLCA3NykNCglhdCBvcmcuZWNsaXBzZS5lbWYu ZWNvcmUueG1p
LmltcGwuWE1MSGFuZGxlci5yZXBvcnRVbmtub3duRmVhdHVyZShYTUxIYW5k bGVyLmphdmE6
MTg1NikNCglhdCBvcmcuZWNsaXBzZS5lbWYuZWNvcmUueG1pLmltcGwuWE1M SGFuZGxlci5o
YW5kbGVVbmtub3duRmVhdHVyZShYTUxIYW5kbGVyLmphdmE6MTgyMCkNCglh dCBvcmcuZWNs
aXBzZS5lbWYuZWNvcmUueG1pLmltcGwuWE1MSGFuZGxlci5oYW5kbGVGZWF0 dXJlKFhNTEhh
bmRsZXIuamF2YToxNzY0KQ0KCWF0IG9yZy5lY2xpcHNlLmVtZi5lY29yZS54 bWkuaW1wbC5Y
TUxIYW5kbGVyLmNyZWF0ZURvY3VtZW50Um9vdChYTUxIYW5kbGVyLmphdmE6 MTMyNikNCglh
dCBvcmcuZWNsaXBzZS5lbWYuZWNvcmUueG1pLmltcGwuWE1MSGFuZGxlci5j cmVhdGVPYmpl
Y3RCeVR5cGUoWE1MSGFuZGxlci5qYXZhOjEyNTkpDQoJYXQgb3JnLmVjbGlw c2UuZW1mLmVj
b3JlLnhtaS5pbXBsLlhNTEhhbmRsZXIuY3JlYXRlVG9wT2JqZWN0KFhNTEhh bmRsZXIuamF2
YToxMzM2KQ0KCWF0IG9yZy5lY2xpcHNlLmVtZi5lY29yZS54bWkuaW1wbC5Y TUxIYW5kbGVy
LnByb2Nlc3NFbGVtZW50KFhNTEhhbmRsZXIuamF2YTo5NzApDQoJYXQgb3Jn LmVjbGlwc2Uu
ZW1mLmVjb3JlLnhtaS5pbXBsLlhNTEhhbmRsZXIuc3RhcnRFbGVtZW50KFhN TEhhbmRsZXIu
amF2YTo5NTMpDQoJYXQgb3JnLmVjbGlwc2UuZW1mLmVjb3JlLnhtaS5pbXBs LlhNTEhhbmRs
ZXIuc3RhcnRFbGVtZW50KFhNTEhhbmRsZXIuamF2YTo2ODQpDQoJYXQgY29t LnN1bi5vcmcu
YXBhY2hlLnhlcmNlcy5pbnRlcm5hbC5wYXJzZXJzLkFic3RyYWN0U0FYUGFy c2VyLnN0YXJ0
RWxlbWVudChVbmtub3duIFNvdXJjZSkNCglhdCBjb20uc3VuLm9yZy5hcGFj aGUueGVyY2Vz
LmludGVybmFsLnBhcnNlcnMuQWJzdHJhY3RYTUxEb2N1bWVudFBhcnNlci5l bXB0eUVsZW1l
bnQoVW5rbm93biBTb3VyY2UpDQoJYXQgY29tLnN1bi5vcmcuYXBhY2hlLnhl cmNlcy5pbnRl
cm5hbC5pbXBsLmR0ZC5YTUxEVERWYWxpZGF0b3IuZW1wdHlFbGVtZW50KFVu a25vd24gU291
cmNlKQ0KCWF0IGNvbS5zdW4ub3JnLmFwYWNoZS54ZXJjZXMuaW50ZXJuYWwu aW1wbC5YTUxE
b2N1bWVudEZyYWdtZW50U2Nhbm5lckltcGwuc2NhblN0YXJ0RWxlbWVudChV bmtub3duIFNv
dXJjZSkNCglhdCBjb20uc3VuLm9yZy5hcGFjaGUueGVyY2VzLmludGVybmFs LmltcGwuWE1M
RG9jdW1lbnRTY2FubmVySW1wbCRDb250ZW50RGlzcGF0Y2hlci5zY2FuUm9v dEVsZW1lbnRI
b29rKFVua25vd24gU291cmNlKQ0KCWF0IGNvbS5zdW4ub3JnLmFwYWNoZS54 ZXJjZXMuaW50
ZXJuYWwuaW1wbC5YTUxEb2N1bWVudEZyYWdtZW50U2Nhbm5lckltcGwkRnJh Z21lbnRDb250
ZW50RGlzcGF0Y2hlci5kaXNwYXRjaChVbmtub3duIFNvdXJjZSkNCglhdCBj b20uc3VuLm9y
Zy5hcGFjaGUueGVyY2VzLmludGVybmFsLmltcGwuWE1MRG9jdW1lbnRGcmFn bWVudFNjYW5u
ZXJJbXBsLnNjYW5Eb2N1bWVudChVbmtub3duIFNvdXJjZSkNCglhdCBjb20u c3VuLm9yZy5h
cGFjaGUueGVyY2VzLmludGVybmFsLnBhcnNlcnMuWE1MMTFDb25maWd1cmF0 aW9uLnBhcnNl
KFVua25vd24gU291cmNlKQ0KCWF0IGNvbS5zdW4ub3JnLmFwYWNoZS54ZXJj ZXMuaW50ZXJu
YWwucGFyc2Vycy5YTUwxMUNvbmZpZ3VyYXRpb24ucGFyc2UoVW5rbm93biBT b3VyY2UpDQoJ
YXQgY29tLnN1bi5vcmcuYXBhY2hlLnhlcmNlcy5pbnRlcm5hbC5wYXJzZXJz LlhNTFBhcnNl
ci5wYXJzZShVbmtub3duIFNvdXJjZSkNCglhdCBjb20uc3VuLm9yZy5hcGFj aGUueGVyY2Vz
LmludGVybmFsLnBhcnNlcnMuQWJzdHJhY3RTQVhQYXJzZXIucGFyc2UoVW5r bm93biBTb3Vy
Y2UpDQoJYXQgamF2YXgueG1sLnBhcnNlcnMuU0FYUGFyc2VyLnBhcnNlKFVu a25vd24gU291
cmNlKQ0KCWF0IG9yZy5lY2xpcHNlLmVtZi5lY29yZS54bWkuaW1wbC5YTUxM b2FkSW1wbC5s
b2FkKFhNTExvYWRJbXBsLmphdmE6MTc5KQ0KCWF0IG9yZy5lY2xpcHNlLmVt Zi5lY29yZS54
bWkuaW1wbC5YTUxSZXNvdXJjZUltcGwuZG9Mb2FkKFhNTFJlc291cmNlSW1w bC5qYXZhOjE4
MCkNCglhdCBvcmcuZWNsaXBzZS5lbWYuZWNvcmUucmVzb3VyY2UuaW1wbC5S ZXNvdXJjZUlt
cGwubG9hZChSZXNvdXJjZUltcGwuamF2YToxMzU0KQ0KCWF0IG9yZy5lY2xp cHNlLmVtZi5l
Y29yZS5yZXNvdXJjZS5pbXBsLlJlc291cmNlSW1wbC5sb2FkKFJlc291cmNl SW1wbC5qYXZh
OjExNTUpDQoJYXQgb3JnLmVjbGlwc2UuZW1mLmVjb3JlLnJlc291cmNlLmlt cGwuUmVzb3Vy
Y2VTZXRJbXBsLmRlbWFuZExvYWQoUmVzb3VyY2VTZXRJbXBsLmphdmE6MjU2 KQ0KCWF0IG9y
Zy5lY2xpcHNlLmVtZi5lY29yZS5yZXNvdXJjZS5pbXBsLlJlc291cmNlU2V0 SW1wbC5kZW1h
bmRMb2FkSGVscGVyKFJlc291cmNlU2V0SW1wbC5qYXZhOjI3MSkNCglhdCBv cmcuZWNsaXBz
ZS5lbWYuZWNvcmUucmVzb3VyY2UuaW1wbC5SZXNvdXJjZVNldEltcGwuZ2V0 UmVzb3VyY2Uo
UmVzb3VyY2VTZXRJbXBsLmphdmE6Mzk4KQ0KCWF0IG9yZy5leGFtcGxlLnNh bXBsZXNjaGVt
YS5zYW1wbGV2MS5wcmVzZW50YXRpb24uU2FtcGxlVjFFZGl0b3IuY3JlYXRl TW9kZWwoU2Ft
cGxlVjFFZGl0b3IuamF2YToxMDU2KQ0KCWF0IG9yZy5leGFtcGxlLnNhbXBs ZXNjaGVtYS5z
YW1wbGV2MS5wcmVzZW50YXRpb24uU2FtcGxlVjFFZGl0b3IuY3JlYXRlUGFn ZXMoU2FtcGxl
VjFFZGl0b3IuamF2YToxMTIwKQ0KCWF0IG9yZy5lY2xpcHNlLnVpLnBhcnQu TXVsdGlQYWdl
RWRpdG9yUGFydC5jcmVhdGVQYXJ0Q29udHJvbChNdWx0aVBhZ2VFZGl0b3JQ YXJ0LmphdmE6
MjgzKQ0KCWF0IG9yZy5lY2xpcHNlLnVpLmludGVybmFsLkVkaXRvclJlZmVy ZW5jZS5jcmVh
dGVQYXJ0SGVscGVyKEVkaXRvclJlZmVyZW5jZS5qYXZhOjY2MSkNCglhdCBv cmcuZWNsaXBz
ZS51aS5pbnRlcm5hbC5FZGl0b3JSZWZlcmVuY2UuY3JlYXRlUGFydChFZGl0 b3JSZWZlcmVu
Y2UuamF2YTo0MjYpDQoJYXQgb3JnLmVjbGlwc2UudWkuaW50ZXJuYWwuV29y a2JlbmNoUGFy
dFJlZmVyZW5jZS5nZXRQYXJ0KFdvcmtiZW5jaFBhcnRSZWZlcmVuY2UuamF2 YTo1OTIpDQoJ
YXQgb3JnLmVjbGlwc2UudWkuaW50ZXJuYWwuRWRpdG9yQXJlYUhlbHBlci5z ZXRWaXNpYmxl
RWRpdG9yKEVkaXRvckFyZWFIZWxwZXIuamF2YToyNjMpDQoJYXQgb3JnLmVj bGlwc2UudWku
aW50ZXJuYWwuRWRpdG9yTWFuYWdlci5zZXRWaXNpYmxlRWRpdG9yKEVkaXRv ck1hbmFnZXIu
amF2YToxNDA1KQ0KCWF0IG9yZy5lY2xpcHNlLnVpLmludGVybmFsLkVkaXRv ck1hbmFnZXIk
NS5ydW5XaXRoRXhjZXB0aW9uKEVkaXRvck1hbmFnZXIuamF2YTo5MzkpDQoJ YXQgb3JnLmVj
bGlwc2UudWkuaW50ZXJuYWwuU3RhcnR1cFRocmVhZGluZyRTdGFydHVwUnVu bmFibGUucnVu
KFN0YXJ0dXBUaHJlYWRpbmcuamF2YTozMSkNCglhdCBvcmcuZWNsaXBzZS5z d3Qud2lkZ2V0
cy5SdW5uYWJsZUxvY2sucnVuKFJ1bm5hYmxlTG9jay5qYXZhOjM1KQ0KCWF0 IG9yZy5lY2xp
cHNlLnN3dC53aWRnZXRzLlN5bmNocm9uaXplci5ydW5Bc3luY01lc3NhZ2Vz KFN5bmNocm9u
aXplci5qYXZhOjEyMykNCglhdCBvcmcuZWNsaXBzZS5zd3Qud2lkZ2V0cy5E aXNwbGF5LnJ1
bkFzeW5jTWVzc2FnZXMoRGlzcGxheS5qYXZhOjM2NTkpDQoJYXQgb3JnLmVj bGlwc2Uuc3d0
LndpZGdldHMuRGlzcGxheS5yZWFkQW5kRGlzcGF0Y2goRGlzcGxheS5qYXZh OjMyOTYpDQoJ
YXQgb3JnLmVjbGlwc2UudWkuYXBwbGljYXRpb24uV29ya2JlbmNoQWR2aXNv ci5vcGVuV2lu
ZG93cyhXb3JrYmVuY2hBZHZpc29yLmphdmE6ODAxKQ0KCWF0IG9yZy5lY2xp cHNlLnVpLmlu
dGVybmFsLldvcmtiZW5jaCQyNS5ydW5XaXRoRXhjZXB0aW9uKFdvcmtiZW5j aC5qYXZhOjEz
NDIpDQoJYXQgb3JnLmVjbGlwc2UudWkuaW50ZXJuYWwuU3RhcnR1cFRocmVh ZGluZyRTdGFy
dHVwUnVubmFibGUucnVuKFN0YXJ0dXBUaHJlYWRpbmcuamF2YTozMSkNCglh dCBvcmcuZWNs
aXBzZS5zd3Qud2lkZ2V0cy5SdW5uYWJsZUxvY2sucnVuKFJ1bm5hYmxlTG9j ay5qYXZhOjM1
KQ0KCWF0IG9yZy5lY2xpcHNlLnN3dC53aWRnZXRzLlN5bmNocm9uaXplci5y dW5Bc3luY01l
c3NhZ2VzKFN5bmNocm9uaXplci5qYXZhOjEyMykNCglhdCBvcmcuZWNsaXBz ZS5zd3Qud2lk
Z2V0cy5EaXNwbGF5LnJ1bkFzeW5jTWVzc2FnZXMoRGlzcGxheS5qYXZhOjM2 NTkpDQoJYXQg
b3JnLmVjbGlwc2Uuc3d0LndpZGdldHMuRGlzcGxheS5yZWFkQW5kRGlzcGF0 Y2goRGlzcGxh
eS5qYXZhOjMyOTYpDQoJYXQgb3JnLmVjbGlwc2UudWkuaW50ZXJuYWwuV29y a2JlbmNoLnJ1
blVJKFdvcmtiZW5jaC5qYXZhOjIzMDkpDQoJYXQgb3JnLmVjbGlwc2UudWku aW50ZXJuYWwu
V29ya2JlbmNoLmFjY2VzcyQ0KFdvcmtiZW5jaC5qYXZhOjIyMTkpDQoJYXQg b3JnLmVjbGlw
c2UudWkuaW50ZXJuYWwuV29ya2JlbmNoJDQucnVuKFdvcmtiZW5jaC5qYXZh OjQ2NikNCglh
dCBvcmcuZWNsaXBzZS5jb3JlLmRhdGFiaW5kaW5nLm9ic2VydmFibGUuUmVh bG0ucnVuV2l0
aERlZmF1bHQoUmVhbG0uamF2YToyODgpDQoJYXQgb3JnLmVjbGlwc2UudWku aW50ZXJuYWwu
V29ya2JlbmNoLmNyZWF0ZUFuZFJ1bldvcmtiZW5jaChXb3JrYmVuY2guamF2 YTo0NjEpDQoJ
YXQgb3JnLmVjbGlwc2UudWkuUGxhdGZvcm1VSS5jcmVhdGVBbmRSdW5Xb3Jr YmVuY2goUGxh
dGZvcm1VSS5qYXZhOjE0OSkNCglhdCBvcmcuZWNsaXBzZS51aS5pbnRlcm5h bC5pZGUuYXBw
bGljYXRpb24uSURFQXBwbGljYXRpb24uc3RhcnQoSURFQXBwbGljYXRpb24u amF2YToxMDYp
DQoJYXQgb3JnLmVjbGlwc2UuZXF1aW5veC5pbnRlcm5hbC5hcHAuRWNsaXBz ZUFwcEhhbmRs
ZS5ydW4oRWNsaXBzZUFwcEhhbmRsZS5qYXZhOjE2OSkNCglhdCBvcmcuZWNs aXBzZS5jb3Jl
LnJ1bnRpbWUuaW50ZXJuYWwuYWRhcHRvci5FY2xpcHNlQXBwTGF1bmNoZXIu cnVuQXBwbGlj
YXRpb24oRWNsaXBzZUFwcExhdW5jaGVyLmphdmE6MTA2KQ0KCWF0IG9yZy5l Y2xpcHNlLmNv
cmUucnVudGltZS5pbnRlcm5hbC5hZGFwdG9yLkVjbGlwc2VBcHBMYXVuY2hl ci5zdGFydChF
Y2xpcHNlQXBwTGF1bmNoZXIuamF2YTo3NikNCglhdCBvcmcuZWNsaXBzZS5j b3JlLnJ1bnRp
bWUuYWRhcHRvci5FY2xpcHNlU3RhcnRlci5ydW4oRWNsaXBzZVN0YXJ0ZXIu amF2YTozNjMp
DQoJYXQgb3JnLmVjbGlwc2UuY29yZS5ydW50aW1lLmFkYXB0b3IuRWNsaXBz ZVN0YXJ0ZXIu
cnVuKEVjbGlwc2VTdGFydGVyLmphdmE6MTc2KQ0KCWF0IHN1bi5yZWZsZWN0 Lk5hdGl2ZU1l
dGhvZEFjY2Vzc29ySW1wbC5pbnZva2UwKE5hdGl2ZSBNZXRob2QpDQoJYXQg c3VuLnJlZmxl
Y3QuTmF0aXZlTWV0aG9kQWNjZXNzb3JJbXBsLmludm9rZShVbmtub3duIFNv dXJjZSkNCglh
dCBzdW4ucmVmbGVjdC5EZWxlZ2F0aW5nTWV0aG9kQWNjZXNzb3JJbXBsLmlu dm9rZShVbmtu
b3duIFNvdXJjZSkNCglhdCBqYXZhLmxhbmcucmVmbGVjdC5NZXRob2QuaW52 b2tlKFVua25v
d24gU291cmNlKQ0KCWF0IG9yZy5lY2xpcHNlLmVxdWlub3gubGF1bmNoZXIu TWFpbi5pbnZv
a2VGcmFtZXdvcmsoTWFpbi5qYXZhOjUwOCkNCglhdCBvcmcuZWNsaXBzZS5l cXVpbm94Lmxh
dW5jaGVyLk1haW4uYmFzaWNSdW4oTWFpbi5qYXZhOjQ0NykNCglhdCBvcmcu ZWNsaXBzZS5l
cXVpbm94LmxhdW5jaGVyLk1haW4ucnVuKE1haW4uamF2YToxMTczKQ0KCWF0 IG9yZy5lY2xp
cHNlLmVxdWlub3gubGF1bmNoZXIuTWFpbi5tYWluKE1haW4uamF2YToxMTQ4 KQ==
--------------030407000700030301020806--
|
|
|
| Re: multiple namespaces in one editor supported? [message #423533 is a reply to message #423530] |
Wed, 01 October 2008 20:16 |
Ed Merks
Messages: 33137
Registered: July 2009 |
Senior Member |
|
|
Vasanth,
In a schema based model, it's more complicated because the root
element's qualified name is looked up in the document root of the
EPackage for that namespace. So while the additional registration will
result in ExtendedMetaData.getPackage finding the right package, the
getElement method won't find the right element in the document root. I
think you'd need to create a specialized BasicExtendedMetaData instance
in your resource factory, in place of Boolean.TRUE, and override
getLocalElement to replace with "additional" namespace with the "actual"
namespace before calling super.
Vasanth Velusamy wrote:
> Ed,
>
> I am trying to register multiple uris to the same package. As you had
> described in this thread, and yet another thread, I included an
> additional extension contribution (for
> org.eclipse.emf.ecore.generated_package) for a new uri, but that
> didn't seem to be enough. When I attempted to open a file with the
> new namespace, I received a FeatureNotFoundException (full stack trace
> in attachement). Without this contribution, I received an exception
> similar to what the thread owner received initially
> (AssertionFailedException). So I would assume that the new extension
> contribution is being used.
>
> I did a search for the old namespace in all three projects (model,
> edit and editor) and found them used in the following places:
>
> * my schema file
> * my ecore file
> * XXXFactoryImpl.java
> * XXXPackage.java
> * plugin.xml in model project
> * plugin.xml in edit project (used in contributing to extension point
> org.eclipse.emf.edit.itemProviderAdapterFactories. Should there be
> additional contributions for the new URI here as well? I tried it but
> didn't seem to help.)
>
> I changed XXXPackage.eNS_URI to point to the new URI. Obviously, with
> this change, the editor worked for the new URI but not the old URI.
>
> So, I am wondering if I am missing any additional step to get the
> editor to work with multiple uris, or if something broke. For example,
> should I have another ecore for the new namespace? I am using EMF 2.3.1.
>
> Thanks,
> Vasanth
>
>
> Rene Ladan wrote:
>> Hi all,
>>
>> I've added Eds suggestion and some further experiences to the new EMF
>> recipe wiki.
>>
>> Regards,
>> Rene
>>
>> Ed Merks wrote:
>>> Rene,
>>>
>>> [...] Perhaps the problem would be solved simply by registering A
>>> for both namespaces, e.g.,
>>>
>>> <extension point="org.eclipse.emf.ecore.generated_package">
>>> <package
>>> uri = "http://www.example.com/OldLibrary"
>>> class = "com.example.library.LibraryPackage"
>>> </extension>
>>>
>>> <extension point="org.eclipse.emf.ecore.generated_package">
>>> <package
>>> uri = "http://www.example.com/Library"
>>> class = "com.example.library.LibraryPackage"
>>> genModel = "model/library.genmodel" />
>>> </extension>
>>>
>>>
>>> Rene Ladan wrote:
>>>> Rene Ladan wrote:
>>>>> Hi,
>>>>>
>>>>> say I have metamodel A with namespace http://mm.A/ which is a
>>>>> superset of metamodel B with namespace http://mm.B/ .
>>>>>
>>>>> If I generate an EMF editor using namespace A, it can by default
>>>>> not read legacy files which were serialized using namespace B,
>>>>> unless I manually edit the files to point to namespace A.
>>>>>
>>>>> Is there a way to support both namespaces in the same editor? An
>>>>> alternative would be to rename namespace A to B and regenerate the
>>>>> editor (and merge all the manual code...). The legacy files
>>>>> cannot be changed since they have to work with another EMF tool.
>>>>>
>> [...]
>>>>> Regards,
>>>>> Rene
>>>>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: multiple namespaces in one editor supported? [message #423670 is a reply to message #423533] |
Mon, 06 October 2008 14:18 |
Vasanth Velusamy
Messages: 31
Registered: July 2009 |
Member |
|
|
Ed,
In XXXResourceFactoryImpl.createResource(...), for default load options,
I set an instance of BasicExtendedMetaData that overrides
getLocalElement(...) to replace older schema namespace with the most
current one. It works. Thanks for the pointer.
However (isn't there always a however?), this essentially converts the
model to have the newer namespace. When I save the model, it writes out
the model to be in the new namespace. This is not what I desire. I
suppose I will just have to work around that. I am planning to remember
the actual namespace when the model was read in, and perform a namespace
conversion before writing it out, if needed.
Thanks,
Vasanth
Ed Merks wrote:
> Vasanth,
>
> In a schema based model, it's more complicated because the root
> element's qualified name is looked up in the document root of the
> EPackage for that namespace. So while the additional registration will
> result in ExtendedMetaData.getPackage finding the right package, the
> getElement method won't find the right element in the document root. I
> think you'd need to create a specialized BasicExtendedMetaData instance
> in your resource factory, in place of Boolean.TRUE, and override
> getLocalElement to replace with "additional" namespace with the "actual"
> namespace before calling super.
>
>
> Vasanth Velusamy wrote:
>> Ed,
>>
>> I am trying to register multiple uris to the same package. As you had
>> described in this thread, and yet another thread, I included an
>> additional extension contribution (for
>> org.eclipse.emf.ecore.generated_package) for a new uri, but that
>> didn't seem to be enough. When I attempted to open a file with the
>> new namespace, I received a FeatureNotFoundException (full stack trace
>> in attachement). Without this contribution, I received an exception
>> similar to what the thread owner received initially
>> (AssertionFailedException). So I would assume that the new extension
>> contribution is being used.
>>
>> I did a search for the old namespace in all three projects (model,
>> edit and editor) and found them used in the following places:
>>
>> * my schema file
>> * my ecore file
>> * XXXFactoryImpl.java
>> * XXXPackage.java
>> * plugin.xml in model project
>> * plugin.xml in edit project (used in contributing to extension point
>> org.eclipse.emf.edit.itemProviderAdapterFactories. Should there be
>> additional contributions for the new URI here as well? I tried it but
>> didn't seem to help.)
>>
>> I changed XXXPackage.eNS_URI to point to the new URI. Obviously, with
>> this change, the editor worked for the new URI but not the old URI.
>>
>> So, I am wondering if I am missing any additional step to get the
>> editor to work with multiple uris, or if something broke. For example,
>> should I have another ecore for the new namespace? I am using EMF 2.3.1.
>>
>> Thanks,
>> Vasanth
>>
>>
>> Rene Ladan wrote:
>>> Hi all,
>>>
>>> I've added Eds suggestion and some further experiences to the new EMF
>>> recipe wiki.
>>>
>>> Regards,
>>> Rene
>>>
>>> Ed Merks wrote:
>>>> Rene,
>>>>
>>>> [...] Perhaps the problem would be solved simply by registering A
>>>> for both namespaces, e.g.,
>>>>
>>>> <extension point="org.eclipse.emf.ecore.generated_package">
>>>> <package
>>>> uri = "http://www.example.com/OldLibrary"
>>>> class = "com.example.library.LibraryPackage"
>>>> </extension>
>>>>
>>>> <extension point="org.eclipse.emf.ecore.generated_package">
>>>> <package
>>>> uri = "http://www.example.com/Library"
>>>> class = "com.example.library.LibraryPackage"
>>>> genModel = "model/library.genmodel" />
>>>> </extension>
>>>>
>>>>
>>>> Rene Ladan wrote:
>>>>> Rene Ladan wrote:
>>>>>> Hi,
>>>>>>
>>>>>> say I have metamodel A with namespace http://mm.A/ which is a
>>>>>> superset of metamodel B with namespace http://mm.B/ .
>>>>>>
>>>>>> If I generate an EMF editor using namespace A, it can by default
>>>>>> not read legacy files which were serialized using namespace B,
>>>>>> unless I manually edit the files to point to namespace A.
>>>>>>
>>>>>> Is there a way to support both namespaces in the same editor? An
>>>>>> alternative would be to rename namespace A to B and regenerate the
>>>>>> editor (and merge all the manual code...). The legacy files
>>>>>> cannot be changed since they have to work with another EMF tool.
>>>>>>
>>> [...]
>>>>>> Regards,
>>>>>> Rene
>>>>>
|
|
|
| Re: multiple namespaces in one editor supported? [message #423745 is a reply to message #423670] |
Mon, 06 October 2008 14:45 |
Ed Merks
Messages: 33137
Registered: July 2009 |
Senior Member |
|
|
Vasanth,
Comments below.
Vasanth Velusamy wrote:
> Ed,
>
> In XXXResourceFactoryImpl.createResource(...), for default load
> options, I set an instance of BasicExtendedMetaData that overrides
> getLocalElement(...) to replace older schema namespace with the most
> current one. It works. Thanks for the pointer.
>
> However (isn't there always a however?
Unfortunately yes. :-P
> ), this essentially converts the model to have the newer namespace.
> When I save the model, it writes out the model to be in the new namespace.
It generally uses the XyzPackage.getNsURI...
> This is not what I desire. I suppose I will just have to work around that.
When extended meta data is present, it will use methods like
getNamespace() to determine what to use.
> I am planning to remember the actual namespace when the model was read
> in, and perform a namespace conversion before writing it out, if needed.
The DocumentRoot's getXMLNSPrefixDeclarations will record information
about this. You might key your behavior off of that...
>
> Thanks,
> Vasanth
>
>
> Ed Merks wrote:
>> Vasanth,
>>
>> In a schema based model, it's more complicated because the root
>> element's qualified name is looked up in the document root of the
>> EPackage for that namespace. So while the additional registration
>> will result in ExtendedMetaData.getPackage finding the right package,
>> the getElement method won't find the right element in the document
>> root. I think you'd need to create a specialized
>> BasicExtendedMetaData instance in your resource factory, in place of
>> Boolean.TRUE, and override getLocalElement to replace with
>> "additional" namespace with the "actual" namespace before calling super.
>>
>>
>> Vasanth Velusamy wrote:
>>> Ed,
>>>
>>> I am trying to register multiple uris to the same package. As you
>>> had described in this thread, and yet another thread, I included an
>>> additional extension contribution (for
>>> org.eclipse.emf.ecore.generated_package) for a new uri, but that
>>> didn't seem to be enough. When I attempted to open a file with the
>>> new namespace, I received a FeatureNotFoundException (full stack
>>> trace in attachement). Without this contribution, I received an
>>> exception similar to what the thread owner received initially
>>> (AssertionFailedException). So I would assume that the new extension
>>> contribution is being used.
>>>
>>> I did a search for the old namespace in all three projects (model,
>>> edit and editor) and found them used in the following places:
>>>
>>> * my schema file
>>> * my ecore file
>>> * XXXFactoryImpl.java
>>> * XXXPackage.java
>>> * plugin.xml in model project
>>> * plugin.xml in edit project (used in contributing to extension
>>> point org.eclipse.emf.edit.itemProviderAdapterFactories. Should
>>> there be additional contributions for the new URI here as well? I
>>> tried it but didn't seem to help.)
>>>
>>> I changed XXXPackage.eNS_URI to point to the new URI. Obviously,
>>> with this change, the editor worked for the new URI but not the old
>>> URI.
>>>
>>> So, I am wondering if I am missing any additional step to get the
>>> editor to work with multiple uris, or if something broke. For
>>> example, should I have another ecore for the new namespace? I am
>>> using EMF 2.3.1.
>>>
>>> Thanks,
>>> Vasanth
>>>
>>>
>>> Rene Ladan wrote:
>>>> Hi all,
>>>>
>>>> I've added Eds suggestion and some further experiences to the new
>>>> EMF recipe wiki.
>>>>
>>>> Regards,
>>>> Rene
>>>>
>>>> Ed Merks wrote:
>>>>> Rene,
>>>>>
>>>>> [...] Perhaps the problem would be solved simply by registering A
>>>>> for both namespaces, e.g.,
>>>>>
>>>>> <extension point="org.eclipse.emf.ecore.generated_package">
>>>>> <package
>>>>> uri = "http://www.example.com/OldLibrary"
>>>>> class = "com.example.library.LibraryPackage"
>>>>> </extension>
>>>>>
>>>>> <extension point="org.eclipse.emf.ecore.generated_package">
>>>>> <package
>>>>> uri = "http://www.example.com/Library"
>>>>> class = "com.example.library.LibraryPackage"
>>>>> genModel = "model/library.genmodel" />
>>>>> </extension>
>>>>>
>>>>>
>>>>> Rene Ladan wrote:
>>>>>> Rene Ladan wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> say I have metamodel A with namespace http://mm.A/ which is a
>>>>>>> superset of metamodel B with namespace http://mm.B/ .
>>>>>>>
>>>>>>> If I generate an EMF editor using namespace A, it can by default
>>>>>>> not read legacy files which were serialized using namespace B,
>>>>>>> unless I manually edit the files to point to namespace A.
>>>>>>>
>>>>>>> Is there a way to support both namespaces in the same editor?
>>>>>>> An alternative would be to rename namespace A to B and
>>>>>>> regenerate the editor (and merge all the manual code...). The
>>>>>>> legacy files cannot be changed since they have to work with
>>>>>>> another EMF tool.
>>>>>>>
>>>> [...]
>>>>>>> Regards,
>>>>>>> Rene
>>>>>>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Goto Forum:
Current Time: Fri Apr 19 11:28:48 GMT 2024
Powered by FUDForum. Page generated in 0.02589 seconds |
] 
Search
Help
Register
Login
Home
