|
|
Re: XSD -> EMF -> UML [message #478330 is a reply to message #478328] |
Fri, 24 April 2009 19:22 |
james bruck 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 |
John T.E. Timm 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 |
Ed Merks 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 |
james bruck 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 |
John T.E. Timm 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
>>>
|
|
|
Powered by
FUDForum. Page generated in 0.04848 seconds