Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » XSDEcoreBuilder --> using a different EcorePackage instance
XSDEcoreBuilder --> using a different EcorePackage instance [message #433217] Thu, 30 July 2009 17:56 Go to next message
Martin Taal is currently offline Martin TaalFriend
Messages: 5468
Registered: July 2009
Senior Member
Hi,
I am persisting ecore models in the database. Including the EcorePackage itself (and XMLTypePackage etc.). To handle
this correctly I also use my own EPackage.Registry which has my own instance of EcorePackage (read from the database).

First a general question: is it possible/feasible to have my own instance of the EcorePackage
(!=EcorePackage.eINSTANCE)? I mean will having my own EPackage.Registry solve all the issues I can have with references
to the Ecore types themselves? Or are there hidden things I should be aware of (for example with the way that base edata
types are resolved through the extendedmetadata)?

I noticed at least one location where the EcorePackage/XMLTypePackage are used 'hardcoded' and not through a package
registry. That is the XSDEcoreBuilder. I can solve this in two ways:
- copy XSDEcoreBuilder and replace all the hard-references to these packages with one resolved through a packageregistry
(the XSDEcoreBuilder has a package registry)
- 'repair' the epackages (created by XSDEcoreBuilder) afterwards and replace all references to the EcorePackage instance
(incl. the edatatypes/eclasses it has etc.) with references to my own instances of EcorePackage (the same for
XMLTypePackage etc.).

What is the best way in your opinion (or maybe both are very unsmart and there is an other great elegant way to solve this)?

Thanks!

--

With Regards, Martin Taal

Springsite/Elver.org
Office: Hardwareweg 4, 3821 BV Amersfoort
Postal: Nassaulaan 7, 3941 EC Doorn
The Netherlands
Cell: +31 (0)6 288 48 943
Tel: +31 (0)84 420 2397
Fax: +31 (0)84 225 9307
Mail: mtaal@springsite.com - mtaal@elver.org
Web: www.springsite.com - www.elver.org
Re: XSDEcoreBuilder --> using a different EcorePackage instance [message #433706 is a reply to message #433217] Thu, 30 July 2009 18:47 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 33113
Registered: July 2009
Senior Member
Martin,

Comments below.


Martin Taal wrote:
> Hi,
> I am persisting ecore models in the database. Including the
> EcorePackage itself (and XMLTypePackage etc.). To handle this
> correctly I also use my own EPackage.Registry which has my own
> instance of EcorePackage (read from the database).
>
> First a general question: is it possible/feasible to have my own
> instance of the EcorePackage (!=EcorePackage.eINSTANCE)? I mean will
> having my own EPackage.Registry solve all the issues I can have with
> references to the Ecore types themselves? Or are there hidden things I
> should be aware of (for example with the way that base edata types are
> resolved through the extendedmetadata)?
I don't think that would work well...
>
> I noticed at least one location where the EcorePackage/XMLTypePackage
> are used 'hardcoded' and not through a package registry. That is the
> XSDEcoreBuilder. I can solve this in two ways:
> - copy XSDEcoreBuilder and replace all the hard-references to these
> packages with one resolved through a packageregistry (the
> XSDEcoreBuilder has a package registry)
> - 'repair' the epackages (created by XSDEcoreBuilder) afterwards and
> replace all references to the EcorePackage instance (incl. the
> edatatypes/eclasses it has etc.) with references to my own instances
> of EcorePackage (the same for XMLTypePackage etc.).
Changing code seems like a bad plan.
>
> What is the best way in your opinion (or maybe both are very unsmart
> and there is an other great elegant way to solve this)?
I'm not sure why you'd need to persist models that should be
ubiquitously available. In general, if you have a generated model, it's
important when persisting references to it that when you restore the
persisted thing you don't end up with a copy of the model, but rather
the generated model itself...
>
> Thanks!
>


Ed Merks
Professional Support: https://www.macromodeling.com/
Re: XSDEcoreBuilder --> using a different EcorePackage instance [message #434049 is a reply to message #433706] Thu, 30 July 2009 19:02 Go to previous messageGo to next message
Martin Taal is currently offline Martin TaalFriend
Messages: 5468
Registered: July 2009
Senior Member
Hi Ed,
I am persisting dynamic (non-generated) epackages, but because these have references to the ecore model also (i.e. to
the XMLTypePackage most of the time), I also need to persist (in the database) the ecore and xmltypepackages themselves.
I don't like that :-( but I need to because for example a persisted estructuralfeature can refer to an edatatype to the
epackage itself (persisted in the database) or to an ecore type.At database level I don't know the difference... This
also applies to epackages which belong to generated classes and 'dynamic' epackages.

But your answer is clear!

One last question, can I detect that an EPackage has a generated EPackage class available somewhere? I mean an EClass
has an instancetypename but an epackage does not seem to have such a thing.

gr. Martin


Ed Merks wrote:
> Martin,
>
> Comments below.
>
>
> Martin Taal wrote:
>> Hi,
>> I am persisting ecore models in the database. Including the
>> EcorePackage itself (and XMLTypePackage etc.). To handle this
>> correctly I also use my own EPackage.Registry which has my own
>> instance of EcorePackage (read from the database).
>>
>> First a general question: is it possible/feasible to have my own
>> instance of the EcorePackage (!=EcorePackage.eINSTANCE)? I mean will
>> having my own EPackage.Registry solve all the issues I can have with
>> references to the Ecore types themselves? Or are there hidden things I
>> should be aware of (for example with the way that base edata types are
>> resolved through the extendedmetadata)?
> I don't think that would work well...
>>
>> I noticed at least one location where the EcorePackage/XMLTypePackage
>> are used 'hardcoded' and not through a package registry. That is the
>> XSDEcoreBuilder. I can solve this in two ways:
>> - copy XSDEcoreBuilder and replace all the hard-references to these
>> packages with one resolved through a packageregistry (the
>> XSDEcoreBuilder has a package registry)
>> - 'repair' the epackages (created by XSDEcoreBuilder) afterwards and
>> replace all references to the EcorePackage instance (incl. the
>> edatatypes/eclasses it has etc.) with references to my own instances
>> of EcorePackage (the same for XMLTypePackage etc.).
> Changing code seems like a bad plan.
>>
>> What is the best way in your opinion (or maybe both are very unsmart
>> and there is an other great elegant way to solve this)?
> I'm not sure why you'd need to persist models that should be
> ubiquitously available. In general, if you have a generated model, it's
> important when persisting references to it that when you restore the
> persisted thing you don't end up with a copy of the model, but rather
> the generated model itself...
>>
>> Thanks!
>>


--

With Regards, Martin Taal

Springsite/Elver.org
Office: Hardwareweg 4, 3821 BV Amersfoort
Postal: Nassaulaan 7, 3941 EC Doorn
The Netherlands
Cell: +31 (0)6 288 48 943
Tel: +31 (0)84 420 2397
Fax: +31 (0)84 225 9307
Mail: mtaal@springsite.com - mtaal@elver.org
Web: www.springsite.com - www.elver.org
Re: XSDEcoreBuilder --> using a different EcorePackage instance [message #434296 is a reply to message #434049] Thu, 30 July 2009 19:26 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 33113
Registered: July 2009
Senior Member
Martin,

Generally if EPackage.Registry.INSTANCE.getEPackage(ePackage.getNsURI())
== ePackage it would be better to assume it will always be available as
a registered package...


Martin Taal wrote:
> Hi Ed,
> I am persisting dynamic (non-generated) epackages, but because these
> have references to the ecore model also (i.e. to the XMLTypePackage
> most of the time), I also need to persist (in the database) the ecore
> and xmltypepackages themselves. I don't like that :-( but I need to
> because for example a persisted estructuralfeature can refer to an
> edatatype to the epackage itself (persisted in the database) or to an
> ecore type.At database level I don't know the difference... This also
> applies to epackages which belong to generated classes and 'dynamic'
> epackages.
>
> But your answer is clear!
>
> One last question, can I detect that an EPackage has a generated
> EPackage class available somewhere? I mean an EClass has an
> instancetypename but an epackage does not seem to have such a thing.
>
> gr. Martin
>
>
> Ed Merks wrote:
>> Martin,
>>
>> Comments below.
>>
>>
>> Martin Taal wrote:
>>> Hi,
>>> I am persisting ecore models in the database. Including the
>>> EcorePackage itself (and XMLTypePackage etc.). To handle this
>>> correctly I also use my own EPackage.Registry which has my own
>>> instance of EcorePackage (read from the database).
>>>
>>> First a general question: is it possible/feasible to have my own
>>> instance of the EcorePackage (!=EcorePackage.eINSTANCE)? I mean will
>>> having my own EPackage.Registry solve all the issues I can have with
>>> references to the Ecore types themselves? Or are there hidden things
>>> I should be aware of (for example with the way that base edata types
>>> are resolved through the extendedmetadata)?
>> I don't think that would work well...
>>>
>>> I noticed at least one location where the
>>> EcorePackage/XMLTypePackage are used 'hardcoded' and not through a
>>> package registry. That is the XSDEcoreBuilder. I can solve this in
>>> two ways:
>>> - copy XSDEcoreBuilder and replace all the hard-references to these
>>> packages with one resolved through a packageregistry (the
>>> XSDEcoreBuilder has a package registry)
>>> - 'repair' the epackages (created by XSDEcoreBuilder) afterwards and
>>> replace all references to the EcorePackage instance (incl. the
>>> edatatypes/eclasses it has etc.) with references to my own instances
>>> of EcorePackage (the same for XMLTypePackage etc.).
>> Changing code seems like a bad plan.
>>>
>>> What is the best way in your opinion (or maybe both are very unsmart
>>> and there is an other great elegant way to solve this)?
>> I'm not sure why you'd need to persist models that should be
>> ubiquitously available. In general, if you have a generated model,
>> it's important when persisting references to it that when you restore
>> the persisted thing you don't end up with a copy of the model, but
>> rather the generated model itself...
>>>
>>> Thanks!
>>>
>
>


Ed Merks
Professional Support: https://www.macromodeling.com/
Re: XSDEcoreBuilder --> using a different EcorePackage instance [message #434299 is a reply to message #434296] Thu, 30 July 2009 19:28 Go to previous messageGo to next message
Martin Taal is currently offline Martin TaalFriend
Messages: 5468
Registered: July 2009
Senior Member
Hi Ed,
You mean generated package?

I can check it in another way also I think, just check if the instance of the EPackage==EPackageImpl.class or a subclass
(the last should be a generated one).

gr. Martin

Ed Merks wrote:
> Martin,
>
> Generally if EPackage.Registry.INSTANCE.getEPackage(ePackage.getNsURI())
> == ePackage it would be better to assume it will always be available as
> a registered package...
>
>
> Martin Taal wrote:
>> Hi Ed,
>> I am persisting dynamic (non-generated) epackages, but because these
>> have references to the ecore model also (i.e. to the XMLTypePackage
>> most of the time), I also need to persist (in the database) the ecore
>> and xmltypepackages themselves. I don't like that :-( but I need to
>> because for example a persisted estructuralfeature can refer to an
>> edatatype to the epackage itself (persisted in the database) or to an
>> ecore type.At database level I don't know the difference... This also
>> applies to epackages which belong to generated classes and 'dynamic'
>> epackages.
>>
>> But your answer is clear!
>>
>> One last question, can I detect that an EPackage has a generated
>> EPackage class available somewhere? I mean an EClass has an
>> instancetypename but an epackage does not seem to have such a thing.
>>
>> gr. Martin
>>
>>
>> Ed Merks wrote:
>>> Martin,
>>>
>>> Comments below.
>>>
>>>
>>> Martin Taal wrote:
>>>> Hi,
>>>> I am persisting ecore models in the database. Including the
>>>> EcorePackage itself (and XMLTypePackage etc.). To handle this
>>>> correctly I also use my own EPackage.Registry which has my own
>>>> instance of EcorePackage (read from the database).
>>>>
>>>> First a general question: is it possible/feasible to have my own
>>>> instance of the EcorePackage (!=EcorePackage.eINSTANCE)? I mean will
>>>> having my own EPackage.Registry solve all the issues I can have with
>>>> references to the Ecore types themselves? Or are there hidden things
>>>> I should be aware of (for example with the way that base edata types
>>>> are resolved through the extendedmetadata)?
>>> I don't think that would work well...
>>>>
>>>> I noticed at least one location where the
>>>> EcorePackage/XMLTypePackage are used 'hardcoded' and not through a
>>>> package registry. That is the XSDEcoreBuilder. I can solve this in
>>>> two ways:
>>>> - copy XSDEcoreBuilder and replace all the hard-references to these
>>>> packages with one resolved through a packageregistry (the
>>>> XSDEcoreBuilder has a package registry)
>>>> - 'repair' the epackages (created by XSDEcoreBuilder) afterwards and
>>>> replace all references to the EcorePackage instance (incl. the
>>>> edatatypes/eclasses it has etc.) with references to my own instances
>>>> of EcorePackage (the same for XMLTypePackage etc.).
>>> Changing code seems like a bad plan.
>>>>
>>>> What is the best way in your opinion (or maybe both are very unsmart
>>>> and there is an other great elegant way to solve this)?
>>> I'm not sure why you'd need to persist models that should be
>>> ubiquitously available. In general, if you have a generated model,
>>> it's important when persisting references to it that when you restore
>>> the persisted thing you don't end up with a copy of the model, but
>>> rather the generated model itself...
>>>>
>>>> Thanks!
>>>>
>>
>>


--

With Regards, Martin Taal

Springsite/Elver.org
Office: Hardwareweg 4, 3821 BV Amersfoort
Postal: Nassaulaan 7, 3941 EC Doorn
The Netherlands
Cell: +31 (0)6 288 48 943
Tel: +31 (0)84 420 2397
Fax: +31 (0)84 225 9307
Mail: mtaal@springsite.com - mtaal@elver.org
Web: www.springsite.com - www.elver.org
Re: XSDEcoreBuilder --> using a different EcorePackage instance [message #434499 is a reply to message #434299] Thu, 30 July 2009 19:38 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 33113
Registered: July 2009
Senior Member
Martin,

I used the term registered on purpose because it's even possible to
register dynamic packages in the global package registry but I think
they should be treated the same way...


Martin Taal wrote:
> Hi Ed,
> You mean generated package?
>
> I can check it in another way also I think, just check if the instance
> of the EPackage==EPackageImpl.class or a subclass (the last should be
> a generated one).
>
> gr. Martin
>
> Ed Merks wrote:
>> Martin,
>>
>> Generally if
>> EPackage.Registry.INSTANCE.getEPackage(ePackage.getNsURI()) ==
>> ePackage it would be better to assume it will always be available as
>> a registered package...
>>
>>
>> Martin Taal wrote:
>>> Hi Ed,
>>> I am persisting dynamic (non-generated) epackages, but because these
>>> have references to the ecore model also (i.e. to the XMLTypePackage
>>> most of the time), I also need to persist (in the database) the
>>> ecore and xmltypepackages themselves. I don't like that :-( but I
>>> need to because for example a persisted estructuralfeature can refer
>>> to an edatatype to the epackage itself (persisted in the database)
>>> or to an ecore type.At database level I don't know the difference...
>>> This also applies to epackages which belong to generated classes and
>>> 'dynamic' epackages.
>>>
>>> But your answer is clear!
>>>
>>> One last question, can I detect that an EPackage has a generated
>>> EPackage class available somewhere? I mean an EClass has an
>>> instancetypename but an epackage does not seem to have such a thing.
>>>
>>> gr. Martin
>>>
>>>
>>> Ed Merks wrote:
>>>> Martin,
>>>>
>>>> Comments below.
>>>>
>>>>
>>>> Martin Taal wrote:
>>>>> Hi,
>>>>> I am persisting ecore models in the database. Including the
>>>>> EcorePackage itself (and XMLTypePackage etc.). To handle this
>>>>> correctly I also use my own EPackage.Registry which has my own
>>>>> instance of EcorePackage (read from the database).
>>>>>
>>>>> First a general question: is it possible/feasible to have my own
>>>>> instance of the EcorePackage (!=EcorePackage.eINSTANCE)? I mean
>>>>> will having my own EPackage.Registry solve all the issues I can
>>>>> have with references to the Ecore types themselves? Or are there
>>>>> hidden things I should be aware of (for example with the way that
>>>>> base edata types are resolved through the extendedmetadata)?
>>>> I don't think that would work well...
>>>>>
>>>>> I noticed at least one location where the
>>>>> EcorePackage/XMLTypePackage are used 'hardcoded' and not through a
>>>>> package registry. That is the XSDEcoreBuilder. I can solve this in
>>>>> two ways:
>>>>> - copy XSDEcoreBuilder and replace all the hard-references to
>>>>> these packages with one resolved through a packageregistry (the
>>>>> XSDEcoreBuilder has a package registry)
>>>>> - 'repair' the epackages (created by XSDEcoreBuilder) afterwards
>>>>> and replace all references to the EcorePackage instance (incl. the
>>>>> edatatypes/eclasses it has etc.) with references to my own
>>>>> instances of EcorePackage (the same for XMLTypePackage etc.).
>>>> Changing code seems like a bad plan.
>>>>>
>>>>> What is the best way in your opinion (or maybe both are very
>>>>> unsmart and there is an other great elegant way to solve this)?
>>>> I'm not sure why you'd need to persist models that should be
>>>> ubiquitously available. In general, if you have a generated model,
>>>> it's important when persisting references to it that when you
>>>> restore the persisted thing you don't end up with a copy of the
>>>> model, but rather the generated model itself...
>>>>>
>>>>> Thanks!
>>>>>
>>>
>>>
>
>


Ed Merks
Professional Support: https://www.macromodeling.com/
Re: XSDEcoreBuilder --> using a different EcorePackage instance [message #434501 is a reply to message #434499] Thu, 30 July 2009 19:41 Go to previous message
Ed Merks is currently offline Ed MerksFriend
Messages: 33113
Registered: July 2009
Senior Member
Martin,

And yes, checking the implementation class would be a reasonable trick
as well (and one I've used in the past)...


Ed Merks wrote:
> Martin,
>
> I used the term registered on purpose because it's even possible to
> register dynamic packages in the global package registry but I think
> they should be treated the same way...
>
>
> Martin Taal wrote:
>> Hi Ed,
>> You mean generated package?
>>
>> I can check it in another way also I think, just check if the
>> instance of the EPackage==EPackageImpl.class or a subclass (the last
>> should be a generated one).
>>
>> gr. Martin
>>
>> Ed Merks wrote:
>>> Martin,
>>>
>>> Generally if
>>> EPackage.Registry.INSTANCE.getEPackage(ePackage.getNsURI()) ==
>>> ePackage it would be better to assume it will always be available as
>>> a registered package...
>>>
>>>
>>> Martin Taal wrote:
>>>> Hi Ed,
>>>> I am persisting dynamic (non-generated) epackages, but because
>>>> these have references to the ecore model also (i.e. to the
>>>> XMLTypePackage most of the time), I also need to persist (in the
>>>> database) the ecore and xmltypepackages themselves. I don't like
>>>> that :-( but I need to because for example a persisted
>>>> estructuralfeature can refer to an edatatype to the epackage itself
>>>> (persisted in the database) or to an ecore type.At database level I
>>>> don't know the difference... This also applies to epackages which
>>>> belong to generated classes and 'dynamic' epackages.
>>>>
>>>> But your answer is clear!
>>>>
>>>> One last question, can I detect that an EPackage has a generated
>>>> EPackage class available somewhere? I mean an EClass has an
>>>> instancetypename but an epackage does not seem to have such a thing.
>>>>
>>>> gr. Martin
>>>>
>>>>
>>>> Ed Merks wrote:
>>>>> Martin,
>>>>>
>>>>> Comments below.
>>>>>
>>>>>
>>>>> Martin Taal wrote:
>>>>>> Hi,
>>>>>> I am persisting ecore models in the database. Including the
>>>>>> EcorePackage itself (and XMLTypePackage etc.). To handle this
>>>>>> correctly I also use my own EPackage.Registry which has my own
>>>>>> instance of EcorePackage (read from the database).
>>>>>>
>>>>>> First a general question: is it possible/feasible to have my own
>>>>>> instance of the EcorePackage (!=EcorePackage.eINSTANCE)? I mean
>>>>>> will having my own EPackage.Registry solve all the issues I can
>>>>>> have with references to the Ecore types themselves? Or are there
>>>>>> hidden things I should be aware of (for example with the way that
>>>>>> base edata types are resolved through the extendedmetadata)?
>>>>> I don't think that would work well...
>>>>>>
>>>>>> I noticed at least one location where the
>>>>>> EcorePackage/XMLTypePackage are used 'hardcoded' and not through
>>>>>> a package registry. That is the XSDEcoreBuilder. I can solve this
>>>>>> in two ways:
>>>>>> - copy XSDEcoreBuilder and replace all the hard-references to
>>>>>> these packages with one resolved through a packageregistry (the
>>>>>> XSDEcoreBuilder has a package registry)
>>>>>> - 'repair' the epackages (created by XSDEcoreBuilder) afterwards
>>>>>> and replace all references to the EcorePackage instance (incl.
>>>>>> the edatatypes/eclasses it has etc.) with references to my own
>>>>>> instances of EcorePackage (the same for XMLTypePackage etc.).
>>>>> Changing code seems like a bad plan.
>>>>>>
>>>>>> What is the best way in your opinion (or maybe both are very
>>>>>> unsmart and there is an other great elegant way to solve this)?
>>>>> I'm not sure why you'd need to persist models that should be
>>>>> ubiquitously available. In general, if you have a generated model,
>>>>> it's important when persisting references to it that when you
>>>>> restore the persisted thing you don't end up with a copy of the
>>>>> model, but rather the generated model itself...
>>>>>>
>>>>>> Thanks!
>>>>>>
>>>>
>>>>
>>
>>


Ed Merks
Professional Support: https://www.macromodeling.com/
Previous Topic:[CDO]Problem creating CDO/RAP target profile
Next Topic:XSDPackage nsuri, why not: http://www.w3.org/2001/XMLSchema
Goto Forum:
  


Current Time: Thu Mar 28 11:54:10 GMT 2024

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

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

Back to the top