Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Archived » XML Schema Definition (XSD) » Letting XSDEcoreBuilder reuse existing EPackages for imported schemas
Letting XSDEcoreBuilder reuse existing EPackages for imported schemas [message #74579] Wed, 11 June 2008 12:56 Go to next message
Eclipse UserFriend
Originally posted by: moritz.eysholdt.de

Hi,

I'm using the XSDEcoreBuilder to programmatically generate Ecore
packages from XSD files. In my scenario I have a couple of XSD files on
my hard drive and I want to have the derived EPackages in memory. The
XSDs can include/import each other.

The problem is that any XSD can change any time and I have to regenerate
the EPackages while keeping the effort at a minimum.

If one XSD changes, I already manage to reload it's XSDSchema model and
all depending XSDSchema models, so I always have the current XSDSchema
models in memory.

Regenerating the EPackages for all at once works perfectly, but how do I
prevent the XSDEcoreBuilder to regenerate Epackages that have already
been generated and are up to date?

Example:

- there are XSD A and XSD B, A imports B
- there are EPackages A and B generated from the XSDs
- A changes, I reload A and update B's referencingDirectives
- I want to regenerate EPackage A, but NOT EPackage B, since it didn't
change. How to I tell the XSDEcoreBuilder to reuse the existing EPackage B?

First I thought it might be possible by making EPackage B available via
the extendedMetaData's PackageRegistry, but it didn't seem to work out.

Then I noticed that an XSDSchema model's typeDefinition list also
contains all TypeDefinitions of included/imported XSDs... which
surprised me, since I expected to find only the ones that are defined in
that file. And since the XSDEcoreBuilder iterates over that list, this
explains why subpackages are always generated, too.

thanks,
Moritz
Re: Letting XSDEcoreBuilder reuse existing EPackages for imported schemas [message #74597 is a reply to message #74579] Wed, 11 June 2008 14:21 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: merks.ca.ibm.com

Moritz,

Comments below.


Moritz Eysholdt wrote:
> Hi,
>
> I'm using the XSDEcoreBuilder to programmatically generate Ecore
> packages from XSD files. In my scenario I have a couple of XSD files
> on my hard drive and I want to have the derived EPackages in memory.
> The XSDs can include/import each other.
>
> The problem is that any XSD can change any time and I have to
> regenerate the EPackages while keeping the effort at a minimum.
>
> If one XSD changes, I already manage to reload it's XSDSchema model
> and all depending XSDSchema models, so I always have the current
> XSDSchema models in memory.
>
> Regenerating the EPackages for all at once works perfectly, but how do
> I prevent the XSDEcoreBuilder to regenerate Epackages that have
> already been generated and are up to date?
I'm not sure how you know which models have changed actually changed...
>
> Example:
>
> - there are XSD A and XSD B, A imports B
> - there are EPackages A and B generated from the XSDs
> - A changes, I reload A and update B's referencingDirectives
> - I want to regenerate EPackage A, but NOT EPackage B, since it didn't
> change. How to I tell the XSDEcoreBuilder to reuse the existing
> EPackage B?
By regenerate I guess maybe you mean recreate.
>
> First I thought it might be possible by making EPackage B available
> via the extendedMetaData's PackageRegistry, but it didn't seem to work
> out.
It's also important for the mapping between the schema instance and the
EPackage data to be populated...
>
> Then I noticed that an XSDSchema model's typeDefinition list also
> contains all TypeDefinitions of included/imported XSDs... which
> surprised me, since I expected to find only the ones that are defined
> in that file.
The XML Schema specification defines it to be that way...
> And since the XSDEcoreBuilder iterates over that list, this explains
> why subpackages are always generated, too.
You could let the builder generate all new ones, and if you're sure that
some aren't changed, you could unload the Ecore resources for those,
and let the proxy references resolve to the older version you have
elsewhere...

I'm not sure how you know what's changed and what hasn't though... I
suppose you could keep a builder instance around and keep reusing it
too, though you'd have to clean out the ones you want redone...
>
> thanks,
> Moritz
Re: Letting XSDEcoreBuilder reuse existing EPackages for imported schemas [message #74615 is a reply to message #74597] Wed, 11 June 2008 15:01 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: moritz.eysholdt.de

hi Ed,

thanks for your response. Comments below.

>> I'm using the XSDEcoreBuilder to programmatically generate Ecore
>> packages from XSD files. In my scenario I have a couple of XSD files
>> on my hard drive and I want to have the derived EPackages in memory.
>> The XSDs can include/import each other.
>>
>> The problem is that any XSD can change any time and I have to
>> regenerate the EPackages while keeping the effort at a minimum.
>>
>> If one XSD changes, I already manage to reload it's XSDSchema model
>> and all depending XSDSchema models, so I always have the current
>> XSDSchema models in memory.
>>
>> Regenerating the EPackages for all at once works perfectly, but how do
>> I prevent the XSDEcoreBuilder to regenerate Epackages that have
>> already been generated and are up to date?
> I'm not sure how you know which models have changed actually changed...

My code runs as plugin within Eclipse and all XML Schemas of concern are
located within projects within the workspace or plugins that projects
depend on.
org.eclipse.core.resources.IWorkspace.addResourceChangeListe ner(IResourceChangeListener)
and
org.eclipse.jdt.core.JavaCore.addElementChangedListener(IEle mentChangedListener)
notify me about all changes.

>>
>> Example:
>>
>> - there are XSD A and XSD B, A imports B
>> - there are EPackages A and B generated from the XSDs
>> - A changes, I reload A and update B's referencingDirectives
>> - I want to regenerate EPackage A, but NOT EPackage B, since it didn't
>> change. How to I tell the XSDEcoreBuilder to reuse the existing
>> EPackage B?
> By regenerate I guess maybe you mean recreate.

true.

>>
>> First I thought it might be possible by making EPackage B available
>> via the extendedMetaData's PackageRegistry, but it didn't seem to work
>> out.
> It's also important for the mapping between the schema instance and the
> EPackage data to be populated...

Where can I find that mapping?

>> Then I noticed that an XSDSchema model's typeDefinition list also
>> contains all TypeDefinitions of included/imported XSDs... which
>> surprised me, since I expected to find only the ones that are defined
>> in that file.
> The XML Schema specification defines it to be that way...
>> And since the XSDEcoreBuilder iterates over that list, this explains
>> why subpackages are always generated, too.
> You could let the builder generate all new ones, and if you're sure that
> some aren't changed, you could unload the Ecore resources for those,
> and let the proxy references resolve to the older version you have
> elsewhere...

But that would mean that the EPackage I already have is recreated
anyway... I want to avoid that, since it is quite time consuming if the
XSD is huge.

Imagine the following:
- I've got Book.xsd, Article.xsd and XHTML.xsd
- Book and Article import XHTML
- I've generated EPackages for all three XSDs
- Book.xsd changes... but I don't want to recreate the EPackage for
XHTML, since it is huge.

> I'm not sure how you know what's changed and what hasn't though... I
> suppose you could keep a builder instance around and keep reusing it
> too, though you'd have to clean out the ones you want redone...

Cleaning out the models I have loaded, but wich I want to reload, seems
to work quite good for me so far.


regards,
Moritz
Re: Letting XSDEcoreBuilder reuse existing EPackages for imported schemas [message #74635 is a reply to message #74615] Wed, 11 June 2008 17:55 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: merks.ca.ibm.com

Moritz,

Comments below.


Moritz Eysholdt wrote:
> hi Ed,
>
> thanks for your response. Comments below.
>
>>> I'm using the XSDEcoreBuilder to programmatically generate Ecore
>>> packages from XSD files. In my scenario I have a couple of XSD files
>>> on my hard drive and I want to have the derived EPackages in memory.
>>> The XSDs can include/import each other.
>>>
>>> The problem is that any XSD can change any time and I have to
>>> regenerate the EPackages while keeping the effort at a minimum.
>>>
>>> If one XSD changes, I already manage to reload it's XSDSchema model
>>> and all depending XSDSchema models, so I always have the current
>>> XSDSchema models in memory.
>>>
>>> Regenerating the EPackages for all at once works perfectly, but how
>>> do I prevent the XSDEcoreBuilder to regenerate Epackages that have
>>> already been generated and are up to date?
>> I'm not sure how you know which models have changed actually changed...
>
> My code runs as plugin within Eclipse and all XML Schemas of concern
> are located within projects within the workspace or plugins that
> projects depend on.
> org.eclipse.core.resources.IWorkspace.addResourceChangeListe ner(IResourceChangeListener)
> and
> org.eclipse.jdt.core.JavaCore.addElementChangedListener(IEle mentChangedListener)
>
> notify me about all changes.
I see. So you know which physical resources are affected. Of course
any change in a base schema could change all its downstream schemas,
e.g., add something to an attribute group that's used in ten other
complex types in other schemas...
>
>>>
>>> Example:
>>>
>>> - there are XSD A and XSD B, A imports B
>>> - there are EPackages A and B generated from the XSDs
>>> - A changes, I reload A and update B's referencingDirectives
>>> - I want to regenerate EPackage A, but NOT EPackage B, since it
>>> didn't change. How to I tell the XSDEcoreBuilder to reuse the
>>> existing EPackage B?
>> By regenerate I guess maybe you mean recreate.
>
> true.
>
>>>
>>> First I thought it might be possible by making EPackage B available
>>> via the extendedMetaData's PackageRegistry, but it didn't seem to
>>> work out.
>> It's also important for the mapping between the schema instance and
>> the EPackage data to be populated...
>
> Where can I find that mapping?
It's the mapping that's populated as you create the Ecore model
instances, i.e, xsdComponentToEModelElementMap.put and calls to map().
>
>>> Then I noticed that an XSDSchema model's typeDefinition list also
>>> contains all TypeDefinitions of included/imported XSDs... which
>>> surprised me, since I expected to find only the ones that are
>>> defined in that file.
>> The XML Schema specification defines it to be that way...
>>> And since the XSDEcoreBuilder iterates over that list, this explains
>>> why subpackages are always generated, too.
>> You could let the builder generate all new ones, and if you're sure
>> that some aren't changed, you could unload the Ecore resources for
>> those, and let the proxy references resolve to the older version you
>> have elsewhere...
>
> But that would mean that the EPackage I already have is recreated
> anyway... I want to avoid that, since it is quite time consuming if
> the XSD is huge.
True, but reestablishing the mapping is expensive too and more likely to
be error prone.
>
> Imagine the following:
> - I've got Book.xsd, Article.xsd and XHTML.xsd
> - Book and Article import XHTML
> - I've generated EPackages for all three XSDs
> - Book.xsd changes... but I don't want to recreate the EPackage for
> XHTML, since it is huge.
Reusing an XSDEcoreBuilder instance, and cleaning out stale mappings
might be better for this kind of thing.
>
>> I'm not sure how you know what's changed and what hasn't though... I
>> suppose you could keep a builder instance around and keep reusing it
>> too, though you'd have to clean out the ones you want redone...
>
> Cleaning out the models I have loaded, but wich I want to reload,
> seems to work quite good for me so far.
Yes, I think that's the best approach for what you've described. Be
sure to look closely at all the maps, including
targetNamespaceToEPackageMap.
>
>
> regards,
> Moritz
Re: Letting XSDEcoreBuilder reuse existing EPackages for imported schemas [message #74651 is a reply to message #74635] Fri, 13 June 2008 15:57 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: moritz.eysholdt.de

Hi Ed,

thanks again for your hints.

>> Imagine the following:
>> - I've got Book.xsd, Article.xsd and XHTML.xsd
>> - Book and Article import XHTML
>> - I've generated EPackages for all three XSDs
>> - Book.xsd changes... but I don't want to recreate the EPackage for
>> XHTML, since it is huge.
> Reusing an XSDEcoreBuilder instance, and cleaning out stale mappings
> might be better for this kind of thing.

I made it work after all, but it still took some time to figure out to
right approach. I want to describe my solution in case somebody runs
into the same problem one day...

I tried to reuse one singel XSDECoreBuilder instance and to clean out
all stale mappings after each reloading of the modified schemas. This
worked good at the beginning, but I ran into trouble with the following
scenario:

If there are multiple schemas which include (not import) each other,
XSDEcoreBuilder generates one EPackage for them all together. How this
EPackage exactly looks like and which types are included depends on
which schema you start with. I my case, I needed an EPackage for every
single schema file that is supposed to include all types the schema and
its included schemas contain.

So I wanted to end up having multiple Epackages with the same namespace
and xsd-types that have multiple corresponding EClassifiers. Too much
for one XSDECoreBuilder instance to handle.

My solution now looks like this:
Before generating an EPackage, I manually iterate over the schema to
find all XSDIncludes and generate an EPackage for each of them. This way
I ensure an XSDECoreBuilder is generating exactly one EPackage and I end
up maintaining one XSDECoreBuilder instance for every package.

If I now need to recreate an EPackage that depends on EPackages I have
already created, I instantiate a new XSDECoreBuilder for the new
EPackage and initialize the builder's mappings
(targetNamespaceToEPackageMap, xsdComponenentToModelElement etc.) with
the mapping's values of all XSDECoreBuilders that are associater with
the EPackages the new EPackage depends on.

regards,
Moritz
Re: Letting XSDEcoreBuilder reuse existing EPackages for imported schemas [message #74670 is a reply to message #74651] Fri, 13 June 2008 16:07 Go to previous message
Eclipse UserFriend
Originally posted by: merks.ca.ibm.com

Moritz,

Comments below.


Moritz Eysholdt wrote:
> Hi Ed,
>
> thanks again for your hints.
>
>>> Imagine the following:
>>> - I've got Book.xsd, Article.xsd and XHTML.xsd
>>> - Book and Article import XHTML
>>> - I've generated EPackages for all three XSDs
>>> - Book.xsd changes... but I don't want to recreate the EPackage for
>>> XHTML, since it is huge.
>> Reusing an XSDEcoreBuilder instance, and cleaning out stale mappings
>> might be better for this kind of thing.
>
> I made it work after all, but it still took some time to figure out to
> right approach. I want to describe my solution in case somebody runs
> into the same problem one day...
Thanks on their behalf!!
>
> I tried to reuse one singel XSDECoreBuilder instance and to clean out
> all stale mappings after each reloading of the modified schemas. This
> worked good at the beginning, but I ran into trouble with the
> following scenario:
>
> If there are multiple schemas which include (not import) each other,
> XSDEcoreBuilder generates one EPackage for them all together. How this
> EPackage exactly looks like and which types are included depends on
> which schema you start with. I my case, I needed an EPackage for every
> single schema file that is supposed to include all types the schema
> and its included schemas contain.
Yes, there is a one-to-one mapping between target namespace and EPackage
nsURI. Things will be added to the package as you visit schemas that
define things in that corresponding namespace.
>
> So I wanted to end up having multiple Epackages with the same
> namespace and xsd-types that have multiple corresponding EClassifiers.
> Too much for one XSDECoreBuilder instance to handle.
Yes, it's not designed to take that approach, because later when these
things are using, the ability to map a given nsURI to just one package
is important...
>
> My solution now looks like this:
> Before generating an EPackage, I manually iterate over the schema to
> find all XSDIncludes and generate an EPackage for each of them. This
> way I ensure an XSDECoreBuilder is generating exactly one EPackage and
> I end up maintaining one XSDECoreBuilder instance for every package.
>
> If I now need to recreate an EPackage that depends on EPackages I have
> already created, I instantiate a new XSDECoreBuilder for the new
> EPackage and initialize the builder's mappings
> (targetNamespaceToEPackageMap, xsdComponenentToModelElement etc.) with
> the mapping's values of all XSDECoreBuilders that are associater with
> the EPackages the new EPackage depends on.
I see. Tricky. Where there's a will, there's a way, usually...
>
> regards,
> Moritz
Re: Letting XSDEcoreBuilder reuse existing EPackages for imported schemas [message #603060 is a reply to message #74579] Wed, 11 June 2008 14:21 Go to previous message
Ed Merks is currently offline Ed MerksFriend
Messages: 33113
Registered: July 2009
Senior Member
Moritz,

Comments below.


Moritz Eysholdt wrote:
> Hi,
>
> I'm using the XSDEcoreBuilder to programmatically generate Ecore
> packages from XSD files. In my scenario I have a couple of XSD files
> on my hard drive and I want to have the derived EPackages in memory.
> The XSDs can include/import each other.
>
> The problem is that any XSD can change any time and I have to
> regenerate the EPackages while keeping the effort at a minimum.
>
> If one XSD changes, I already manage to reload it's XSDSchema model
> and all depending XSDSchema models, so I always have the current
> XSDSchema models in memory.
>
> Regenerating the EPackages for all at once works perfectly, but how do
> I prevent the XSDEcoreBuilder to regenerate Epackages that have
> already been generated and are up to date?
I'm not sure how you know which models have changed actually changed...
>
> Example:
>
> - there are XSD A and XSD B, A imports B
> - there are EPackages A and B generated from the XSDs
> - A changes, I reload A and update B's referencingDirectives
> - I want to regenerate EPackage A, but NOT EPackage B, since it didn't
> change. How to I tell the XSDEcoreBuilder to reuse the existing
> EPackage B?
By regenerate I guess maybe you mean recreate.
>
> First I thought it might be possible by making EPackage B available
> via the extendedMetaData's PackageRegistry, but it didn't seem to work
> out.
It's also important for the mapping between the schema instance and the
EPackage data to be populated...
>
> Then I noticed that an XSDSchema model's typeDefinition list also
> contains all TypeDefinitions of included/imported XSDs... which
> surprised me, since I expected to find only the ones that are defined
> in that file.
The XML Schema specification defines it to be that way...
> And since the XSDEcoreBuilder iterates over that list, this explains
> why subpackages are always generated, too.
You could let the builder generate all new ones, and if you're sure that
some aren't changed, you could unload the Ecore resources for those,
and let the proxy references resolve to the older version you have
elsewhere...

I'm not sure how you know what's changed and what hasn't though... I
suppose you could keep a builder instance around and keep reusing it
too, though you'd have to clean out the ones you want redone...
>
> thanks,
> Moritz


Ed Merks
Professional Support: https://www.macromodeling.com/
Re: Letting XSDEcoreBuilder reuse existing EPackages for imported schemas [message #603064 is a reply to message #74597] Wed, 11 June 2008 15:01 Go to previous message
Moritz Eysholdt is currently offline Moritz EysholdtFriend
Messages: 161
Registered: July 2009
Location: Kiel, Germany
Senior Member
hi Ed,

thanks for your response. Comments below.

>> I'm using the XSDEcoreBuilder to programmatically generate Ecore
>> packages from XSD files. In my scenario I have a couple of XSD files
>> on my hard drive and I want to have the derived EPackages in memory.
>> The XSDs can include/import each other.
>>
>> The problem is that any XSD can change any time and I have to
>> regenerate the EPackages while keeping the effort at a minimum.
>>
>> If one XSD changes, I already manage to reload it's XSDSchema model
>> and all depending XSDSchema models, so I always have the current
>> XSDSchema models in memory.
>>
>> Regenerating the EPackages for all at once works perfectly, but how do
>> I prevent the XSDEcoreBuilder to regenerate Epackages that have
>> already been generated and are up to date?
> I'm not sure how you know which models have changed actually changed...

My code runs as plugin within Eclipse and all XML Schemas of concern are
located within projects within the workspace or plugins that projects
depend on.
org.eclipse.core.resources.IWorkspace.addResourceChangeListe ner(IResourceChangeListener)
and
org.eclipse.jdt.core.JavaCore.addElementChangedListener(IEle mentChangedListener)
notify me about all changes.

>>
>> Example:
>>
>> - there are XSD A and XSD B, A imports B
>> - there are EPackages A and B generated from the XSDs
>> - A changes, I reload A and update B's referencingDirectives
>> - I want to regenerate EPackage A, but NOT EPackage B, since it didn't
>> change. How to I tell the XSDEcoreBuilder to reuse the existing
>> EPackage B?
> By regenerate I guess maybe you mean recreate.

true.

>>
>> First I thought it might be possible by making EPackage B available
>> via the extendedMetaData's PackageRegistry, but it didn't seem to work
>> out.
> It's also important for the mapping between the schema instance and the
> EPackage data to be populated...

Where can I find that mapping?

>> Then I noticed that an XSDSchema model's typeDefinition list also
>> contains all TypeDefinitions of included/imported XSDs... which
>> surprised me, since I expected to find only the ones that are defined
>> in that file.
> The XML Schema specification defines it to be that way...
>> And since the XSDEcoreBuilder iterates over that list, this explains
>> why subpackages are always generated, too.
> You could let the builder generate all new ones, and if you're sure that
> some aren't changed, you could unload the Ecore resources for those,
> and let the proxy references resolve to the older version you have
> elsewhere...

But that would mean that the EPackage I already have is recreated
anyway... I want to avoid that, since it is quite time consuming if the
XSD is huge.

Imagine the following:
- I've got Book.xsd, Article.xsd and XHTML.xsd
- Book and Article import XHTML
- I've generated EPackages for all three XSDs
- Book.xsd changes... but I don't want to recreate the EPackage for
XHTML, since it is huge.

> I'm not sure how you know what's changed and what hasn't though... I
> suppose you could keep a builder instance around and keep reusing it
> too, though you'd have to clean out the ones you want redone...

Cleaning out the models I have loaded, but wich I want to reload, seems
to work quite good for me so far.


regards,
Moritz
Re: Letting XSDEcoreBuilder reuse existing EPackages for imported schemas [message #603068 is a reply to message #74615] Wed, 11 June 2008 17:55 Go to previous message
Ed Merks is currently offline Ed MerksFriend
Messages: 33113
Registered: July 2009
Senior Member
Moritz,

Comments below.


Moritz Eysholdt wrote:
> hi Ed,
>
> thanks for your response. Comments below.
>
>>> I'm using the XSDEcoreBuilder to programmatically generate Ecore
>>> packages from XSD files. In my scenario I have a couple of XSD files
>>> on my hard drive and I want to have the derived EPackages in memory.
>>> The XSDs can include/import each other.
>>>
>>> The problem is that any XSD can change any time and I have to
>>> regenerate the EPackages while keeping the effort at a minimum.
>>>
>>> If one XSD changes, I already manage to reload it's XSDSchema model
>>> and all depending XSDSchema models, so I always have the current
>>> XSDSchema models in memory.
>>>
>>> Regenerating the EPackages for all at once works perfectly, but how
>>> do I prevent the XSDEcoreBuilder to regenerate Epackages that have
>>> already been generated and are up to date?
>> I'm not sure how you know which models have changed actually changed...
>
> My code runs as plugin within Eclipse and all XML Schemas of concern
> are located within projects within the workspace or plugins that
> projects depend on.
> org.eclipse.core.resources.IWorkspace.addResourceChangeListe ner(IResourceChangeListener)
> and
> org.eclipse.jdt.core.JavaCore.addElementChangedListener(IEle mentChangedListener)
>
> notify me about all changes.
I see. So you know which physical resources are affected. Of course
any change in a base schema could change all its downstream schemas,
e.g., add something to an attribute group that's used in ten other
complex types in other schemas...
>
>>>
>>> Example:
>>>
>>> - there are XSD A and XSD B, A imports B
>>> - there are EPackages A and B generated from the XSDs
>>> - A changes, I reload A and update B's referencingDirectives
>>> - I want to regenerate EPackage A, but NOT EPackage B, since it
>>> didn't change. How to I tell the XSDEcoreBuilder to reuse the
>>> existing EPackage B?
>> By regenerate I guess maybe you mean recreate.
>
> true.
>
>>>
>>> First I thought it might be possible by making EPackage B available
>>> via the extendedMetaData's PackageRegistry, but it didn't seem to
>>> work out.
>> It's also important for the mapping between the schema instance and
>> the EPackage data to be populated...
>
> Where can I find that mapping?
It's the mapping that's populated as you create the Ecore model
instances, i.e, xsdComponentToEModelElementMap.put and calls to map().
>
>>> Then I noticed that an XSDSchema model's typeDefinition list also
>>> contains all TypeDefinitions of included/imported XSDs... which
>>> surprised me, since I expected to find only the ones that are
>>> defined in that file.
>> The XML Schema specification defines it to be that way...
>>> And since the XSDEcoreBuilder iterates over that list, this explains
>>> why subpackages are always generated, too.
>> You could let the builder generate all new ones, and if you're sure
>> that some aren't changed, you could unload the Ecore resources for
>> those, and let the proxy references resolve to the older version you
>> have elsewhere...
>
> But that would mean that the EPackage I already have is recreated
> anyway... I want to avoid that, since it is quite time consuming if
> the XSD is huge.
True, but reestablishing the mapping is expensive too and more likely to
be error prone.
>
> Imagine the following:
> - I've got Book.xsd, Article.xsd and XHTML.xsd
> - Book and Article import XHTML
> - I've generated EPackages for all three XSDs
> - Book.xsd changes... but I don't want to recreate the EPackage for
> XHTML, since it is huge.
Reusing an XSDEcoreBuilder instance, and cleaning out stale mappings
might be better for this kind of thing.
>
>> I'm not sure how you know what's changed and what hasn't though... I
>> suppose you could keep a builder instance around and keep reusing it
>> too, though you'd have to clean out the ones you want redone...
>
> Cleaning out the models I have loaded, but wich I want to reload,
> seems to work quite good for me so far.
Yes, I think that's the best approach for what you've described. Be
sure to look closely at all the maps, including
targetNamespaceToEPackageMap.
>
>
> regards,
> Moritz


Ed Merks
Professional Support: https://www.macromodeling.com/
Re: Letting XSDEcoreBuilder reuse existing EPackages for imported schemas [message #603074 is a reply to message #74635] Fri, 13 June 2008 15:57 Go to previous message
Moritz Eysholdt is currently offline Moritz EysholdtFriend
Messages: 161
Registered: July 2009
Location: Kiel, Germany
Senior Member
Hi Ed,

thanks again for your hints.

>> Imagine the following:
>> - I've got Book.xsd, Article.xsd and XHTML.xsd
>> - Book and Article import XHTML
>> - I've generated EPackages for all three XSDs
>> - Book.xsd changes... but I don't want to recreate the EPackage for
>> XHTML, since it is huge.
> Reusing an XSDEcoreBuilder instance, and cleaning out stale mappings
> might be better for this kind of thing.

I made it work after all, but it still took some time to figure out to
right approach. I want to describe my solution in case somebody runs
into the same problem one day...

I tried to reuse one singel XSDECoreBuilder instance and to clean out
all stale mappings after each reloading of the modified schemas. This
worked good at the beginning, but I ran into trouble with the following
scenario:

If there are multiple schemas which include (not import) each other,
XSDEcoreBuilder generates one EPackage for them all together. How this
EPackage exactly looks like and which types are included depends on
which schema you start with. I my case, I needed an EPackage for every
single schema file that is supposed to include all types the schema and
its included schemas contain.

So I wanted to end up having multiple Epackages with the same namespace
and xsd-types that have multiple corresponding EClassifiers. Too much
for one XSDECoreBuilder instance to handle.

My solution now looks like this:
Before generating an EPackage, I manually iterate over the schema to
find all XSDIncludes and generate an EPackage for each of them. This way
I ensure an XSDECoreBuilder is generating exactly one EPackage and I end
up maintaining one XSDECoreBuilder instance for every package.

If I now need to recreate an EPackage that depends on EPackages I have
already created, I instantiate a new XSDECoreBuilder for the new
EPackage and initialize the builder's mappings
(targetNamespaceToEPackageMap, xsdComponenentToModelElement etc.) with
the mapping's values of all XSDECoreBuilders that are associater with
the EPackages the new EPackage depends on.

regards,
Moritz
Re: Letting XSDEcoreBuilder reuse existing EPackages for imported schemas [message #603079 is a reply to message #74651] Fri, 13 June 2008 16:07 Go to previous message
Ed Merks is currently offline Ed MerksFriend
Messages: 33113
Registered: July 2009
Senior Member
Moritz,

Comments below.


Moritz Eysholdt wrote:
> Hi Ed,
>
> thanks again for your hints.
>
>>> Imagine the following:
>>> - I've got Book.xsd, Article.xsd and XHTML.xsd
>>> - Book and Article import XHTML
>>> - I've generated EPackages for all three XSDs
>>> - Book.xsd changes... but I don't want to recreate the EPackage for
>>> XHTML, since it is huge.
>> Reusing an XSDEcoreBuilder instance, and cleaning out stale mappings
>> might be better for this kind of thing.
>
> I made it work after all, but it still took some time to figure out to
> right approach. I want to describe my solution in case somebody runs
> into the same problem one day...
Thanks on their behalf!!
>
> I tried to reuse one singel XSDECoreBuilder instance and to clean out
> all stale mappings after each reloading of the modified schemas. This
> worked good at the beginning, but I ran into trouble with the
> following scenario:
>
> If there are multiple schemas which include (not import) each other,
> XSDEcoreBuilder generates one EPackage for them all together. How this
> EPackage exactly looks like and which types are included depends on
> which schema you start with. I my case, I needed an EPackage for every
> single schema file that is supposed to include all types the schema
> and its included schemas contain.
Yes, there is a one-to-one mapping between target namespace and EPackage
nsURI. Things will be added to the package as you visit schemas that
define things in that corresponding namespace.
>
> So I wanted to end up having multiple Epackages with the same
> namespace and xsd-types that have multiple corresponding EClassifiers.
> Too much for one XSDECoreBuilder instance to handle.
Yes, it's not designed to take that approach, because later when these
things are using, the ability to map a given nsURI to just one package
is important...
>
> My solution now looks like this:
> Before generating an EPackage, I manually iterate over the schema to
> find all XSDIncludes and generate an EPackage for each of them. This
> way I ensure an XSDECoreBuilder is generating exactly one EPackage and
> I end up maintaining one XSDECoreBuilder instance for every package.
>
> If I now need to recreate an EPackage that depends on EPackages I have
> already created, I instantiate a new XSDECoreBuilder for the new
> EPackage and initialize the builder's mappings
> (targetNamespaceToEPackageMap, xsdComponenentToModelElement etc.) with
> the mapping's values of all XSDECoreBuilders that are associater with
> the EPackages the new EPackage depends on.
I see. Tricky. Where there's a will, there's a way, usually...
>
> regards,
> Moritz


Ed Merks
Professional Support: https://www.macromodeling.com/
Previous Topic:Letting XSDEcoreBuilder reuse existing EPackages for imported schemas
Next Topic:XSD Ecore File Open Source ?
Goto Forum:
  


Current Time: Thu Mar 28 22:14:07 GMT 2024

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

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

Back to the top