Home » Modeling » EMF » XSDEcoreBuilder --> using a different EcorePackage instance
| XSDEcoreBuilder --> using a different EcorePackage instance [message #433217] |
Thu, 30 July 2009 13:56  |
Eclipse User |
|
|
|
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 #434049 is a reply to message #433706] |
Thu, 30 July 2009 15:02  |
| Eclipse User |
|
|
|
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 15:26 |
| Eclipse User |
|
|
|
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!
>>>
>
>
|
|
|
| Re: XSDEcoreBuilder --> using a different EcorePackage instance [message #434299 is a reply to message #434296] |
Thu, 30 July 2009 15:28 |
| Eclipse User |
|
|
|
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 15:38 |
| Eclipse User |
|
|
|
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!
>>>>>
>>>
>>>
>
>
|
|
|
| Re: XSDEcoreBuilder --> using a different EcorePackage instance [message #434501 is a reply to message #434499] |
Thu, 30 July 2009 15:41 |
| Eclipse User |
|
|
|
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!
>>>>>>
>>>>
>>>>
>>
>>
|
|
|
Goto Forum:
Current Time: Thu Jul 03 11:11:57 EDT 2025
Powered by FUDForum. Page generated in 0.26237 seconds |
Home