Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » UML2 » XSD -> EMF -> UML
XSD -> EMF -> UML [message #478326] Thu, 23 April 2009 21:05 Go to next message
John T.E. Timm is currently offline John T.E. TimmFriend
Messages: 161
Registered: July 2009
Senior Member
I am creating an EMF model from XML schema and then exporting it to UML
using the "Export Model..." option on the genmodel context menu. What I
find is one of two things:

1. Either I get a runtime error with an InvocationTargetException
(mentioned in a previous post)

or

2. If my schema has a root element definition that creates DocumentRoot in
the EMF model, the model exporter tries to create a locally defined
Ecore.uml in addition to library.uml.

I am using the simple library.xsd schema (from various EMF examples) and
adding a root element:

<xsd:element name="library" type="lib:Library"/>

When the DocumentRoot EClass is created in Ecore, it has some attributes
that are of type EStringToStringMapEntry. I believe it is this specific
class that causes the model export to attempt to create a local definition
of Ecore.uml (as opposed to simply referencing it with path maps). Without
the root element, I do not have any issues.

My goal is to take the XML Schema convert it to Ecore and then UML so that
I can use it in other UML models and finally take those UML models back
into Ecore with OCL and ultimately produce a Java runtime that validates
the ecore model using OCL constraints specified at the UML level.
Unfortunately, this has not been possible with the library example that I
am using due to the above problems. Any ideas or workarounds would be
appreciated.

Thanks,

JT
Re: XSD -> EMF -> UML [message #478328 is a reply to message #478326] Thu, 23 April 2009 22:53 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 33142
Registered: July 2009
Senior Member
John,

I'd suggest opening a bugzilla with the artifacts needed to reproduce
any problems you see as well as the steps required to see them.


John T.E. Timm wrote:
> I am creating an EMF model from XML schema and then exporting it to
> UML using the "Export Model..." option on the genmodel context menu.
> What I find is one of two things:
>
> 1. Either I get a runtime error with an InvocationTargetException
> (mentioned in a previous post)
>
> or
>
> 2. If my schema has a root element definition that creates
> DocumentRoot in the EMF model, the model exporter tries to create a
> locally defined Ecore.uml in addition to library.uml.
>
> I am using the simple library.xsd schema (from various EMF examples)
> and adding a root element:
>
> <xsd:element name="library" type="lib:Library"/>
>
> When the DocumentRoot EClass is created in Ecore, it has some
> attributes that are of type EStringToStringMapEntry. I believe it is
> this specific class that causes the model export to attempt to create
> a local definition of Ecore.uml (as opposed to simply referencing it
> with path maps). Without the root element, I do not have any issues.
>
> My goal is to take the XML Schema convert it to Ecore and then UML so
> that I can use it in other UML models and finally take those UML
> models back into Ecore with OCL and ultimately produce a Java runtime
> that validates the ecore model using OCL constraints specified at the
> UML level. Unfortunately, this has not been possible with the library
> example that I am using due to the above problems. Any ideas or
> workarounds would be appreciated.
>
> Thanks,
>
> JT
>


Ed Merks
Professional Support: https://www.macromodeling.com/
Re: XSD -> EMF -> UML [message #478330 is a reply to message #478328] Fri, 24 April 2009 19:22 Go to previous messageGo to next message
james bruck is currently offline james bruckFriend
Messages: 1724
Registered: July 2009
Senior Member
Hi Timm, Ed,

Issue 1 below has already been addressed in the latest 3.5 build and will be
available early next week.

Issue 2 is a little trickier and would require an enhancement request
(bugzilla). We simply need to expose the ability to reference the
"official" EMF metamodel that is registered using pathmaps from
pathmap://UML_METAMODELS/Ecore.metamodel.uml.

An ugly workaround that you can use in the meantime would be:

1. Export your .uml version from the .genmodel (or .ecore) as usual. In
your particular case, the DocumentRoot has two properties of type
EStringToStringMapEntry defined in ecore.uml.

Your library.uml model should have a href that looks like
href="ecore.uml#GUID"

2. Open your library.uml with the UML2 editor.

3. Expand the DocumentRoot node.
This should cause the ecore.uml to be loaded in the resource set. It
should have an entry that looks something like
"platform:/resource/EMFLib/model/ecore.uml"

4. Select the root package under the above mentioned node.

5. Select 'UML Editor > Convert To > Metamodel'

6. Save everything.

The href's in your library.uml should now have human readable ID's.
They should look like:
href = "ecore.uml#EStringToStringMapEntry"

7. Open up library.uml in a text editor
Replace ecore.uml with pathmap://UML_METAMODELS/Ecore.metamodel.uml

8. Save everything.

9. Delete the ecore.uml. You are now free of that artifact.

Let us know how that works out for you.
Cheers,
- James.


"Ed Merks" <Ed.Merks@gmail.com> wrote in message
news:gsqrhk$ae4$1@build.eclipse.org...
> John,
>
> I'd suggest opening a bugzilla with the artifacts needed to reproduce any
> problems you see as well as the steps required to see them.
>
>
> John T.E. Timm wrote:
>> I am creating an EMF model from XML schema and then exporting it to UML
>> using the "Export Model..." option on the genmodel context menu. What I
>> find is one of two things:
>>
>> 1. Either I get a runtime error with an InvocationTargetException
>> (mentioned in a previous post)
>>
>> or
>>
>> 2. If my schema has a root element definition that creates DocumentRoot
>> in the EMF model, the model exporter tries to create a locally defined
>> Ecore.uml in addition to library.uml.
>>
>> I am using the simple library.xsd schema (from various EMF examples) and
>> adding a root element:
>>
>> <xsd:element name="library" type="lib:Library"/>
>>
>> When the DocumentRoot EClass is created in Ecore, it has some attributes
>> that are of type EStringToStringMapEntry. I believe it is this specific
>> class that causes the model export to attempt to create a local
>> definition of Ecore.uml (as opposed to simply referencing it with path
>> maps). Without the root element, I do not have any issues.
>>
>> My goal is to take the XML Schema convert it to Ecore and then UML so
>> that I can use it in other UML models and finally take those UML models
>> back into Ecore with OCL and ultimately produce a Java runtime that
>> validates the ecore model using OCL constraints specified at the UML
>> level. Unfortunately, this has not been possible with the library example
>> that I am using due to the above problems. Any ideas or workarounds would
>> be appreciated.
>>
>> Thanks,
>>
>> JT
>>
Re: XSD -> EMF -> UML [message #478332 is a reply to message #478330] Fri, 24 April 2009 21:25 Go to previous message
John T.E. Timm is currently offline John T.E. TimmFriend
Messages: 161
Registered: July 2009
Senior Member
Thanks James. I will submit an enhancement request for this feature.
Additionally, I will submit a bug report for the GenModel "Base Package"
not copying over to the basePackage property of the <<ePackage>>
stereotype. Did you find out any more information on the base package
issue?

JT

James Bruck wrote:

> Hi Timm, Ed,

> Issue 1 below has already been addressed in the latest 3.5 build and will be
> available early next week.

> Issue 2 is a little trickier and would require an enhancement request
> (bugzilla). We simply need to expose the ability to reference the
> "official" EMF metamodel that is registered using pathmaps from
> pathmap://UML_METAMODELS/Ecore.metamodel.uml.

> An ugly workaround that you can use in the meantime would be:

> 1. Export your .uml version from the .genmodel (or .ecore) as usual. In
> your particular case, the DocumentRoot has two properties of type
> EStringToStringMapEntry defined in ecore.uml.

> Your library.uml model should have a href that looks like
> href="ecore.uml#GUID"

> 2. Open your library.uml with the UML2 editor.

> 3. Expand the DocumentRoot node.
> This should cause the ecore.uml to be loaded in the resource set. It
> should have an entry that looks something like
> "platform:/resource/EMFLib/model/ecore.uml"

> 4. Select the root package under the above mentioned node.

> 5. Select 'UML Editor > Convert To > Metamodel'

> 6. Save everything.

> The href's in your library.uml should now have human readable ID's.
> They should look like:
> href = "ecore.uml#EStringToStringMapEntry"

> 7. Open up library.uml in a text editor
> Replace ecore.uml with pathmap://UML_METAMODELS/Ecore.metamodel.uml

> 8. Save everything.

> 9. Delete the ecore.uml. You are now free of that artifact.

> Let us know how that works out for you.
> Cheers,
> - James.


> "Ed Merks" <Ed.Merks@gmail.com> wrote in message
> news:gsqrhk$ae4$1@build.eclipse.org...
>> John,
>>
>> I'd suggest opening a bugzilla with the artifacts needed to reproduce any
>> problems you see as well as the steps required to see them.
>>
>>
>> John T.E. Timm wrote:
>>> I am creating an EMF model from XML schema and then exporting it to UML
>>> using the "Export Model..." option on the genmodel context menu. What I
>>> find is one of two things:
>>>
>>> 1. Either I get a runtime error with an InvocationTargetException
>>> (mentioned in a previous post)
>>>
>>> or
>>>
>>> 2. If my schema has a root element definition that creates DocumentRoot
>>> in the EMF model, the model exporter tries to create a locally defined
>>> Ecore.uml in addition to library.uml.
>>>
>>> I am using the simple library.xsd schema (from various EMF examples) and
>>> adding a root element:
>>>
>>> <xsd:element name="library" type="lib:Library"/>
>>>
>>> When the DocumentRoot EClass is created in Ecore, it has some attributes
>>> that are of type EStringToStringMapEntry. I believe it is this specific
>>> class that causes the model export to attempt to create a local
>>> definition of Ecore.uml (as opposed to simply referencing it with path
>>> maps). Without the root element, I do not have any issues.
>>>
>>> My goal is to take the XML Schema convert it to Ecore and then UML so
>>> that I can use it in other UML models and finally take those UML models
>>> back into Ecore with OCL and ultimately produce a Java runtime that
>>> validates the ecore model using OCL constraints specified at the UML
>>> level. Unfortunately, this has not been possible with the library example
>>> that I am using due to the above problems. Any ideas or workarounds would
>>> be appreciated.
>>>
>>> Thanks,
>>>
>>> JT
>>>
Re: XSD -> EMF -> UML [message #627517 is a reply to message #478326] Thu, 23 April 2009 22:53 Go to previous message
Ed Merks is currently offline Ed MerksFriend
Messages: 33142
Registered: July 2009
Senior Member
John,

I'd suggest opening a bugzilla with the artifacts needed to reproduce
any problems you see as well as the steps required to see them.


John T.E. Timm wrote:
> I am creating an EMF model from XML schema and then exporting it to
> UML using the "Export Model..." option on the genmodel context menu.
> What I find is one of two things:
>
> 1. Either I get a runtime error with an InvocationTargetException
> (mentioned in a previous post)
>
> or
>
> 2. If my schema has a root element definition that creates
> DocumentRoot in the EMF model, the model exporter tries to create a
> locally defined Ecore.uml in addition to library.uml.
>
> I am using the simple library.xsd schema (from various EMF examples)
> and adding a root element:
>
> <xsd:element name="library" type="lib:Library"/>
>
> When the DocumentRoot EClass is created in Ecore, it has some
> attributes that are of type EStringToStringMapEntry. I believe it is
> this specific class that causes the model export to attempt to create
> a local definition of Ecore.uml (as opposed to simply referencing it
> with path maps). Without the root element, I do not have any issues.
>
> My goal is to take the XML Schema convert it to Ecore and then UML so
> that I can use it in other UML models and finally take those UML
> models back into Ecore with OCL and ultimately produce a Java runtime
> that validates the ecore model using OCL constraints specified at the
> UML level. Unfortunately, this has not been possible with the library
> example that I am using due to the above problems. Any ideas or
> workarounds would be appreciated.
>
> Thanks,
>
> JT
>


Ed Merks
Professional Support: https://www.macromodeling.com/
Re: XSD -> EMF -> UML [message #627519 is a reply to message #478328] Fri, 24 April 2009 19:22 Go to previous message
james bruck is currently offline james bruckFriend
Messages: 1724
Registered: July 2009
Senior Member
Hi Timm, Ed,

Issue 1 below has already been addressed in the latest 3.5 build and will be
available early next week.

Issue 2 is a little trickier and would require an enhancement request
(bugzilla). We simply need to expose the ability to reference the
"official" EMF metamodel that is registered using pathmaps from
pathmap://UML_METAMODELS/Ecore.metamodel.uml

An ugly workaround that you can use in the meantime would be:

1. Export your .uml version from the .genmodel (or .ecore) as usual. In
your particular case, the DocumentRoot has two properties of type
EStringToStringMapEntry defined in ecore.uml.

Your library.uml model should have a href that looks like
href="ecore.uml#GUID"

2. Open your library.uml with the UML2 editor.

3. Expand the DocumentRoot node.
This should cause the ecore.uml to be loaded in the resource set. It
should have an entry that looks something like
"platform:/resource/EMFLib/model/ecore.uml"

4. Select the root package under the above mentioned node.

5. Select 'UML Editor > Convert To > Metamodel'

6. Save everything.

The href's in your library.uml should now have human readable ID's.
They should look like:
href = "ecore.uml#EStringToStringMapEntry"

7. Open up library.uml in a text editor
Replace ecore.uml with pathmap://UML_METAMODELS/Ecore.metamodel.uml

8. Save everything.

9. Delete the ecore.uml. You are now free of that artifact.

Let us know how that works out for you.
Cheers,
- James.


"Ed Merks" <Ed.Merks@gmail.com> wrote in message
news:gsqrhk$ae4$1@build.eclipse.org...
> John,
>
> I'd suggest opening a bugzilla with the artifacts needed to reproduce any
> problems you see as well as the steps required to see them.
>
>
> John T.E. Timm wrote:
>> I am creating an EMF model from XML schema and then exporting it to UML
>> using the "Export Model..." option on the genmodel context menu. What I
>> find is one of two things:
>>
>> 1. Either I get a runtime error with an InvocationTargetException
>> (mentioned in a previous post)
>>
>> or
>>
>> 2. If my schema has a root element definition that creates DocumentRoot
>> in the EMF model, the model exporter tries to create a locally defined
>> Ecore.uml in addition to library.uml.
>>
>> I am using the simple library.xsd schema (from various EMF examples) and
>> adding a root element:
>>
>> <xsd:element name="library" type="lib:Library"/>
>>
>> When the DocumentRoot EClass is created in Ecore, it has some attributes
>> that are of type EStringToStringMapEntry. I believe it is this specific
>> class that causes the model export to attempt to create a local
>> definition of Ecore.uml (as opposed to simply referencing it with path
>> maps). Without the root element, I do not have any issues.
>>
>> My goal is to take the XML Schema convert it to Ecore and then UML so
>> that I can use it in other UML models and finally take those UML models
>> back into Ecore with OCL and ultimately produce a Java runtime that
>> validates the ecore model using OCL constraints specified at the UML
>> level. Unfortunately, this has not been possible with the library example
>> that I am using due to the above problems. Any ideas or workarounds would
>> be appreciated.
>>
>> Thanks,
>>
>> JT
>>
Re: XSD -> EMF -> UML [message #627521 is a reply to message #478330] Fri, 24 April 2009 21:25 Go to previous message
John T.E. Timm is currently offline John T.E. TimmFriend
Messages: 161
Registered: July 2009
Senior Member
Thanks James. I will submit an enhancement request for this feature.
Additionally, I will submit a bug report for the GenModel "Base Package"
not copying over to the basePackage property of the <<ePackage>>
stereotype. Did you find out any more information on the base package
issue?

JT

James Bruck wrote:

> Hi Timm, Ed,

> Issue 1 below has already been addressed in the latest 3.5 build and will be
> available early next week.

> Issue 2 is a little trickier and would require an enhancement request
> (bugzilla). We simply need to expose the ability to reference the
> "official" EMF metamodel that is registered using pathmaps from
> pathmap://UML_METAMODELS/Ecore.metamodel.uml

> An ugly workaround that you can use in the meantime would be:

> 1. Export your .uml version from the .genmodel (or .ecore) as usual. In
> your particular case, the DocumentRoot has two properties of type
> EStringToStringMapEntry defined in ecore.uml.

> Your library.uml model should have a href that looks like
> href="ecore.uml#GUID"

> 2. Open your library.uml with the UML2 editor.

> 3. Expand the DocumentRoot node.
> This should cause the ecore.uml to be loaded in the resource set. It
> should have an entry that looks something like
> "platform:/resource/EMFLib/model/ecore.uml"

> 4. Select the root package under the above mentioned node.

> 5. Select 'UML Editor > Convert To > Metamodel'

> 6. Save everything.

> The href's in your library.uml should now have human readable ID's.
> They should look like:
> href = "ecore.uml#EStringToStringMapEntry"

> 7. Open up library.uml in a text editor
> Replace ecore.uml with pathmap://UML_METAMODELS/Ecore.metamodel.uml

> 8. Save everything.

> 9. Delete the ecore.uml. You are now free of that artifact.

> Let us know how that works out for you.
> Cheers,
> - James.


> "Ed Merks" <Ed.Merks@gmail.com> wrote in message
> news:gsqrhk$ae4$1@build.eclipse.org...
>> John,
>>
>> I'd suggest opening a bugzilla with the artifacts needed to reproduce any
>> problems you see as well as the steps required to see them.
>>
>>
>> John T.E. Timm wrote:
>>> I am creating an EMF model from XML schema and then exporting it to UML
>>> using the "Export Model..." option on the genmodel context menu. What I
>>> find is one of two things:
>>>
>>> 1. Either I get a runtime error with an InvocationTargetException
>>> (mentioned in a previous post)
>>>
>>> or
>>>
>>> 2. If my schema has a root element definition that creates DocumentRoot
>>> in the EMF model, the model exporter tries to create a locally defined
>>> Ecore.uml in addition to library.uml.
>>>
>>> I am using the simple library.xsd schema (from various EMF examples) and
>>> adding a root element:
>>>
>>> <xsd:element name="library" type="lib:Library"/>
>>>
>>> When the DocumentRoot EClass is created in Ecore, it has some attributes
>>> that are of type EStringToStringMapEntry. I believe it is this specific
>>> class that causes the model export to attempt to create a local
>>> definition of Ecore.uml (as opposed to simply referencing it with path
>>> maps). Without the root element, I do not have any issues.
>>>
>>> My goal is to take the XML Schema convert it to Ecore and then UML so
>>> that I can use it in other UML models and finally take those UML models
>>> back into Ecore with OCL and ultimately produce a Java runtime that
>>> validates the ecore model using OCL constraints specified at the UML
>>> level. Unfortunately, this has not been possible with the library example
>>> that I am using due to the above problems. Any ideas or workarounds would
>>> be appreciated.
>>>
>>> Thanks,
>>>
>>> JT
>>>
Previous Topic:[Announce] MDT UML2 3.0.0 I200904241604 is available
Next Topic:createExtension() problem
Goto Forum:
  


Current Time: Sat Apr 27 03:06:36 GMT 2024

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

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

Back to the top