Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » multiple namespaces in one editor supported?
multiple namespaces in one editor supported? [message #411923] Fri, 10 August 2007 09:09 Go to next message
Rene Ladan is currently offline Rene LadanFriend
Messages: 51
Registered: July 2009
Member
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 #411924 is a reply to message #411923] Fri, 10 August 2007 09:44 Go to previous messageGo to next message
Rene Ladan is currently offline Rene LadanFriend
Messages: 51
Registered: July 2009
Member
This is a multi-part message in MIME format.
--------------000200010305030701090101
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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


--------------000200010305030701090101
Content-Type: text/plain;
name="nameloading-exception.txt"
Content-Transfer-Encoding: base64
Content-Disposition: inline;
filename="nameloading-exception.txt"

b3JnLmVjbGlwc2UuY29yZS5ydW50aW1lLkFzc2VydGlvbkZhaWxlZEV4Y2Vw dGlvbjogYXNz
ZXJ0aW9uIGZhaWxlZDogDQoJYXQgb3JnLmVjbGlwc2UuY29yZS5ydW50aW1l LkFzc2VydC5p
c1RydWUoQXNzZXJ0LmphdmE6MTA5KQ0KCWF0IG9yZy5lY2xpcHNlLmNvcmUu cnVudGltZS5B
c3NlcnQuaXNUcnVlKEFzc2VydC5qYXZhOjk1KQ0KCWF0IG9yZy5lY2xpcHNl LnVpLnBhcnQu
TXVsdGlQYWdlRWRpdG9yUGFydC5zZXRBY3RpdmVQYWdlKE11bHRpUGFnZUVk aXRvclBhcnQu
amF2YTo2OTUpDQoJYXQgb3JnLmVjbGlwc2UudWkucGFydC5NdWx0aVBhZ2VF ZGl0b3JQYXJ0
LmNyZWF0ZVBhcnRDb250cm9sKE11bHRpUGFnZUVkaXRvclBhcnQuamF2YToy ODcpDQoJYXQg
b3JnLmVjbGlwc2UudWkuaW50ZXJuYWwuRWRpdG9yUmVmZXJlbmNlLmNyZWF0 ZVBhcnRIZWxw
ZXIoRWRpdG9yUmVmZXJlbmNlLmphdmE6NjYxKQ0KCWF0IG9yZy5lY2xpcHNl LnVpLmludGVy
bmFsLkVkaXRvclJlZmVyZW5jZS5jcmVhdGVQYXJ0KEVkaXRvclJlZmVyZW5j ZS5qYXZhOjQy
NikNCglhdCBvcmcuZWNsaXBzZS51aS5pbnRlcm5hbC5Xb3JrYmVuY2hQYXJ0 UmVmZXJlbmNl
LmdldFBhcnQoV29ya2JlbmNoUGFydFJlZmVyZW5jZS5qYXZhOjU5MikNCglh dCBvcmcuZWNs
aXBzZS51aS5pbnRlcm5hbC5FZGl0b3JSZWZlcmVuY2UuZ2V0RWRpdG9yKEVk aXRvclJlZmVy
ZW5jZS5qYXZhOjI2MykNCglhdCBvcmcuZWNsaXBzZS51aS5pbnRlcm5hbC5X b3JrYmVuY2hQ
YWdlLmJ1c3lPcGVuRWRpdG9yQmF0Y2hlZChXb3JrYmVuY2hQYWdlLmphdmE6 MjcyMSkNCglh
dCBvcmcuZWNsaXBzZS51aS5pbnRlcm5hbC5Xb3JrYmVuY2hQYWdlLmJ1c3lP cGVuRWRpdG9y
KFdvcmtiZW5jaFBhZ2UuamF2YToyNjMzKQ0KCWF0IG9yZy5lY2xpcHNlLnVp LmludGVybmFs
LldvcmtiZW5jaFBhZ2UuYWNjZXNzJDEyKFdvcmtiZW5jaFBhZ2UuamF2YToy NjI1KQ0KCWF0
IG9yZy5lY2xpcHNlLnVpLmludGVybmFsLldvcmtiZW5jaFBhZ2UkMTAucnVu KFdvcmtiZW5j
aFBhZ2UuamF2YToyNTc3KQ0KCWF0IG9yZy5lY2xpcHNlLnN3dC5jdXN0b20u QnVzeUluZGlj
YXRvci5zaG93V2hpbGUoQnVzeUluZGljYXRvci5qYXZhOjY3KQ0KCWF0IG9y Zy5lY2xpcHNl
LnVpLmludGVybmFsLldvcmtiZW5jaFBhZ2Uub3BlbkVkaXRvcihXb3JrYmVu Y2hQYWdlLmph
dmE6MjU3MikNCglhdCBvcmcuZWNsaXBzZS51aS5pbnRlcm5hbC5Xb3JrYmVu Y2hQYWdlLm9w
ZW5FZGl0b3IoV29ya2JlbmNoUGFnZS5qYXZhOjI1NTYpDQoJYXQgb3JnLmVj bGlwc2UudWku
aW50ZXJuYWwuV29ya2JlbmNoUGFnZS5vcGVuRWRpdG9yKFdvcmtiZW5jaFBh Z2UuamF2YToy
NTQ3KQ0KCWF0IG9yZy5lY2xpcHNlLnVpLmlkZS5JREUub3BlbkVkaXRvcihJ REUuamF2YTo2
NDQpDQoJYXQgb3JnLmVjbGlwc2UudWkuaWRlLklERS5vcGVuRWRpdG9yKElE RS5qYXZhOjYw
MykNCglhdCBvcmcuZWNsaXBzZS5qZHQuaW50ZXJuYWwudWkuamF2YWVkaXRv ci5FZGl0b3JV
dGlsaXR5Lm9wZW5JbkVkaXRvcihFZGl0b3JVdGlsaXR5LmphdmE6Mjg1KQ0K CWF0IG9yZy5l
Y2xpcHNlLmpkdC5pbnRlcm5hbC51aS5qYXZhZWRpdG9yLkVkaXRvclV0aWxp dHkub3Blbklu
RWRpdG9yKEVkaXRvclV0aWxpdHkuamF2YToxMzgpDQoJYXQgb3JnLmVjbGlw c2UuamR0LnVp
LmFjdGlvbnMuT3BlbkFjdGlvbi5ydW4oT3BlbkFjdGlvbi5qYXZhOjE5NCkN CglhdCBvcmcu
ZWNsaXBzZS5qZHQudWkuYWN0aW9ucy5PcGVuQWN0aW9uLnJ1bihPcGVuQWN0 aW9uLmphdmE6
MTc1KQ0KCWF0IG9yZy5lY2xpcHNlLmpkdC51aS5hY3Rpb25zLlNlbGVjdGlv bkRpc3BhdGNo
QWN0aW9uLmRpc3BhdGNoUnVuKFNlbGVjdGlvbkRpc3BhdGNoQWN0aW9uLmph dmE6MjY4KQ0K
CWF0IG9yZy5lY2xpcHNlLmpkdC51aS5hY3Rpb25zLlNlbGVjdGlvbkRpc3Bh dGNoQWN0aW9u
LnJ1bihTZWxlY3Rpb25EaXNwYXRjaEFjdGlvbi5qYXZhOjI0NCkNCglhdCBv cmcuZWNsaXBz
ZS5qZHQuaW50ZXJuYWwudWkucGFja2FnZXZpZXcuUGFja2FnZUV4cGxvcmVy QWN0aW9uR3Jv
dXAuaGFuZGxlT3BlbihQYWNrYWdlRXhwbG9yZXJBY3Rpb25Hcm91cC5qYXZh OjMxNikNCglh
dCBvcmcuZWNsaXBzZS5qZHQuaW50ZXJuYWwudWkucGFja2FnZXZpZXcuUGFj a2FnZUV4cGxv
cmVyUGFydCQ1Lm9wZW4oUGFja2FnZUV4cGxvcmVyUGFydC5qYXZhOjYxMykN CglhdCBvcmcu
ZWNsaXBzZS5qZmFjZS52aWV3ZXJzLlN0cnVjdHVyZWRWaWV3ZXIkMi5ydW4o U3RydWN0dXJl
ZFZpZXdlci5qYXZhOjgyMCkNCglhdCBvcmcuZWNsaXBzZS5jb3JlLnJ1bnRp bWUuU2FmZVJ1
bm5lci5ydW4oU2FmZVJ1bm5lci5qYXZhOjM3KQ0KCWF0IG9yZy5lY2xpcHNl LmNvcmUucnVu
dGltZS5QbGF0Zm9ybS5ydW4oUGxhdGZvcm0uamF2YTo4NTcpDQoJYXQgb3Jn LmVjbGlwc2Uu
dWkuaW50ZXJuYWwuSkZhY2VVdGlsJDEucnVuKEpGYWNlVXRpbC5qYXZhOjQ2 KQ0KCWF0IG9y
Zy5lY2xpcHNlLmpmYWNlLnV0aWwuU2FmZVJ1bm5hYmxlLnJ1bihTYWZlUnVu bmFibGUuamF2
YToxOTMpDQoJYXQgb3JnLmVjbGlwc2UuamZhY2Uudmlld2Vycy5TdHJ1Y3R1 cmVkVmlld2Vy
LmZpcmVPcGVuKFN0cnVjdHVyZWRWaWV3ZXIuamF2YTo4MTgpDQoJYXQgb3Jn LmVjbGlwc2Uu
amZhY2Uudmlld2Vycy5TdHJ1Y3R1cmVkVmlld2VyLmhhbmRsZU9wZW4oU3Ry dWN0dXJlZFZp
ZXdlci5qYXZhOjEwNzkpDQoJYXQgb3JnLmVjbGlwc2UuamZhY2Uudmlld2Vy cy5TdHJ1Y3R1
cmVkVmlld2VyJDYuaGFuZGxlT3BlbihTdHJ1Y3R1cmVkVmlld2VyLmphdmE6 MTE4MykNCglh
dCBvcmcuZWNsaXBzZS5qZmFjZS51dGlsLk9wZW5TdHJhdGVneS5maXJlT3Bl bkV2ZW50KE9w
ZW5TdHJhdGVneS5qYXZhOjI2MykNCglhdCBvcmcuZWNsaXBzZS5qZmFjZS51 dGlsLk9wZW5T
dHJhdGVneS5hY2Nlc3MkMihPcGVuU3RyYXRlZ3kuamF2YToyNTcpDQoJYXQg b3JnLmVjbGlw
c2UuamZhY2UudXRpbC5PcGVuU3RyYXRlZ3kkMS5oYW5kbGVFdmVudChPcGVu U3RyYXRlZ3ku
amF2YToyOTcpDQoJYXQgb3JnLmVjbGlwc2Uuc3d0LndpZGdldHMuRXZlbnRU YWJsZS5zZW5k
RXZlbnQoRXZlbnRUYWJsZS5qYXZhOjY2KQ0KCWF0IG9yZy5lY2xpcHNlLnN3 dC53aWRnZXRz
LldpZGdldC5zZW5kRXZlbnQoV2lkZ2V0LmphdmE6OTM4KQ0KCWF0IG9yZy5l Y2xpcHNlLnN3
dC53aWRnZXRzLkRpc3BsYXkucnVuRGVmZXJyZWRFdmVudHMoRGlzcGxheS5q YXZhOjM2ODIp
DQoJYXQgb3JnLmVjbGlwc2Uuc3d0LndpZGdldHMuRGlzcGxheS5yZWFkQW5k RGlzcGF0Y2go
RGlzcGxheS5qYXZhOjMyOTMpDQoJYXQgb3JnLmVjbGlwc2UudWkuaW50ZXJu YWwuV29ya2Jl
bmNoLnJ1bkV2ZW50TG9vcChXb3JrYmVuY2guamF2YToyMzg5KQ0KCWF0IG9y Zy5lY2xpcHNl
LnVpLmludGVybmFsLldvcmtiZW5jaC5ydW5VSShXb3JrYmVuY2guamF2YToy MzUzKQ0KCWF0
IG9yZy5lY2xpcHNlLnVpLmludGVybmFsLldvcmtiZW5jaC5hY2Nlc3MkNChX b3JrYmVuY2gu
amF2YToyMjE5KQ0KCWF0IG9yZy5lY2xpcHNlLnVpLmludGVybmFsLldvcmti ZW5jaCQ0LnJ1
bihXb3JrYmVuY2guamF2YTo0NjYpDQoJYXQgb3JnLmVjbGlwc2UuY29yZS5k YXRhYmluZGlu
Zy5vYnNlcnZhYmxlLlJlYWxtLnJ1bldpdGhEZWZhdWx0KFJlYWxtLmphdmE6 Mjg5KQ0KCWF0
IG9yZy5lY2xpcHNlLnVpLmludGVybmFsLldvcmtiZW5jaC5jcmVhdGVBbmRS dW5Xb3JrYmVu
Y2goV29ya2JlbmNoLmphdmE6NDYxKQ0KCWF0IG9yZy5lY2xpcHNlLnVpLlBs YXRmb3JtVUku
Y3JlYXRlQW5kUnVuV29ya2JlbmNoKFBsYXRmb3JtVUkuamF2YToxNDkpDQoJ YXQgb3JnLmVj
bGlwc2UudWkuaW50ZXJuYWwuaWRlLmFwcGxpY2F0aW9uLklERUFwcGxpY2F0 aW9uLnN0YXJ0
KElERUFwcGxpY2F0aW9uLmphdmE6MTA2KQ0KCWF0IG9yZy5lY2xpcHNlLmVx dWlub3guaW50
ZXJuYWwuYXBwLkVjbGlwc2VBcHBIYW5kbGUucnVuKEVjbGlwc2VBcHBIYW5k bGUuamF2YTox
NTMpDQoJYXQgb3JnLmVjbGlwc2UuY29yZS5ydW50aW1lLmludGVybmFsLmFk YXB0b3IuRWNs
aXBzZUFwcExhdW5jaGVyLnJ1bkFwcGxpY2F0aW9uKEVjbGlwc2VBcHBMYXVu Y2hlci5qYXZh
OjEwNikNCglhdCBvcmcuZWNsaXBzZS5jb3JlLnJ1bnRpbWUuaW50ZXJuYWwu YWRhcHRvci5F
Y2xpcHNlQXBwTGF1bmNoZXIuc3RhcnQoRWNsaXBzZUFwcExhdW5jaGVyLmph dmE6NzYpDQoJ
YXQgb3JnLmVjbGlwc2UuY29yZS5ydW50aW1lLmFkYXB0b3IuRWNsaXBzZVN0 YXJ0ZXIucnVu
KEVjbGlwc2VTdGFydGVyLmphdmE6MzYzKQ0KCWF0IG9yZy5lY2xpcHNlLmNv cmUucnVudGlt
ZS5hZGFwdG9yLkVjbGlwc2VTdGFydGVyLnJ1bihFY2xpcHNlU3RhcnRlci5q YXZhOjE3NikN
CglhdCBzdW4ucmVmbGVjdC5OYXRpdmVNZXRob2RBY2Nlc3NvckltcGwuaW52 b2tlMChOYXRp
dmUgTWV0aG9k
--------------000200010305030701090101--
Re: multiple namespaces in one editor supported? [message #411926 is a reply to message #411924] Fri, 10 August 2007 11:11 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 31342
Registered: July 2009
Senior Member
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
>


Ed Merks
Professional Support: https://www.macromodeling.com/
Re: multiple namespaces in one editor supported? [message #411930 is a reply to message #411926] Fri, 10 August 2007 12:04 Go to previous messageGo to next message
Rene Ladan is currently offline Rene LadanFriend
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 Go to previous messageGo to next message
Rene Ladan is currently offline Rene LadanFriend
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 Go to previous messageGo to next message
Vasanth Velusamy is currently offline Vasanth VelusamyFriend
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 Go to previous messageGo to next message
Vasanth Velusamy is currently offline Vasanth VelusamyFriend
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 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 31342
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 Go to previous messageGo to next message
Vasanth Velusamy is currently offline Vasanth VelusamyFriend
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 Go to previous message
Ed Merks is currently offline Ed MerksFriend
Messages: 31342
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/
Previous Topic:Instantiating an ecore metamodel
Next Topic:Loosing xsi:schemaLocation after serialization
Goto Forum:
  


Current Time: Mon Aug 03 18:49:43 GMT 2020

Powered by FUDForum. Page generated in 0.02545 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top