Eclipse Community Forums: UML2 » EPackage to Profile mapping

Help

Home

Home » Modeling » UML2 » EPackage to Profile mapping

Show: Today's Messages :: Show Polls :: Message Navigator

EPackage to Profile mapping [message #476429]

Thu, 25 October 2007 15:10

Eclipse User

Originally posted by: cdamus.ca.ibm.com

Hi,

The static profile definition capability relies on a mapping of EPackage
namespace URIs to URIs locating the corresponding UML Profiles (populated
in Eclipse environment from an extension point).

Why was it necessary to introduce this registry? It would seem, at first
blush, that EMF's support for registration of genmodels would cover this
need by mapping the EPackage to the GenModel, then getting the foreign
model from that.

I am particularly interested because, in OCL, I need to be able to map
EPackages not only to Profiles but to any UML package in order to find the
UML metamodel from which the Java classes describing run-time objects were
generated. Perhaps this mapping needs to be extended to metamodels as well
as profiles?

Thanks,

Christian

Report message to a moderator

Re: EPackage to Profile mapping [message #476432 is a reply to message #476429]

Fri, 26 October 2007 13:42

james bruck

Messages: 1724
Registered: July 2009

Senior Member

Hi Christian,

The very first attempt at implementing this did involve attempting to use
the foreign model but a dedicated extension point was deemed a better choice
for several reasons:

1. A generator model is a development time artifact that need not be
deployed with the profile.
2. As a performance concern, parsing the generator model just to get back
the .uml model which may be one of several foreign models seemed like a lot
of overhead.

For the above mentioned reasons, an extension point dedicated to profiles
seemed like a more robust alternative.

Cheers,

- James.

"Christian W. Damus" <cdamus@ca.ibm.com> wrote in message
news:ffqbkh$9k$1@build.eclipse.org...
> Hi,
>
> The static profile definition capability relies on a mapping of EPackage
> namespace URIs to URIs locating the corresponding UML Profiles (populated
> in Eclipse environment from an extension point).
>
> Why was it necessary to introduce this registry? It would seem, at first
> blush, that EMF's support for registration of genmodels would cover this
> need by mapping the EPackage to the GenModel, then getting the foreign
> model from that.
>
> I am particularly interested because, in OCL, I need to be able to map
> EPackages not only to Profiles but to any UML package in order to find the
> UML metamodel from which the Java classes describing run-time objects were
> generated. Perhaps this mapping needs to be extended to metamodels as
> well
> as profiles?
>
> Thanks,
>
> Christian

Report message to a moderator

Re: EPackage to Profile mapping [message #476436 is a reply to message #476432]

Fri, 26 October 2007 17:09

Eclipse User

Originally posted by: cdamus.ca.ibm.com

Hi, James,

Thanks, that makes sense.

Any sense on the idea of extending this function to all generated Packages?
:-)

cW

James Bruck wrote:

> Hi Christian,
>
> The very first attempt at implementing this did involve attempting to use
> the foreign model but a dedicated extension point was deemed a better
> choice for several reasons:
>
> 1. A generator model is a development time artifact that need not be
> deployed with the profile.
> 2. As a performance concern, parsing the generator model just to get back
> the .uml model which may be one of several foreign models seemed like a
> lot of overhead.
>
> For the above mentioned reasons, an extension point dedicated to profiles
> seemed like a more robust alternative.
>
> Cheers,
>
> - James.
>
>
> "Christian W. Damus" <cdamus@ca.ibm.com> wrote in message
> news:ffqbkh$9k$1@build.eclipse.org...
>> Hi,
>>
>> The static profile definition capability relies on a mapping of EPackage
>> namespace URIs to URIs locating the corresponding UML Profiles (populated
>> in Eclipse environment from an extension point).
>>
>> Why was it necessary to introduce this registry? It would seem, at first
>> blush, that EMF's support for registration of genmodels would cover this
>> need by mapping the EPackage to the GenModel, then getting the foreign
>> model from that.
>>
>> I am particularly interested because, in OCL, I need to be able to map
>> EPackages not only to Profiles but to any UML package in order to find
>> the UML metamodel from which the Java classes describing run-time objects
>> were
>> generated. Perhaps this mapping needs to be extended to metamodels as
>> well
>> as profiles?
>>
>> Thanks,
>>
>> Christian

Report message to a moderator

Re: EPackage to Profile mapping [message #476438 is a reply to message #476436]

Sun, 28 October 2007 00:29

james bruck

Messages: 1724
Registered: July 2009

Senior Member

Hi Christian,

The mapping could be extended. I'll make the long trek over to your
cubicle so we can discuss the details ;)

Cheers,
- James.

"Christian W. Damus" <cdamus@ca.ibm.com> wrote in message
news:fft70e$lmn$1@build.eclipse.org...
> Hi, James,
>
> Thanks, that makes sense.
>
> Any sense on the idea of extending this function to all generated
> Packages?
> :-)
>
> cW
>
> James Bruck wrote:
>
>> Hi Christian,
>>
>> The very first attempt at implementing this did involve attempting to use
>> the foreign model but a dedicated extension point was deemed a better
>> choice for several reasons:
>>
>> 1. A generator model is a development time artifact that need not be
>> deployed with the profile.
>> 2. As a performance concern, parsing the generator model just to get back
>> the .uml model which may be one of several foreign models seemed like a
>> lot of overhead.
>>
>> For the above mentioned reasons, an extension point dedicated to profiles
>> seemed like a more robust alternative.
>>
>> Cheers,
>>
>> - James.
>>
>>
>> "Christian W. Damus" <cdamus@ca.ibm.com> wrote in message
>> news:ffqbkh$9k$1@build.eclipse.org...
>>> Hi,
>>>
>>> The static profile definition capability relies on a mapping of EPackage
>>> namespace URIs to URIs locating the corresponding UML Profiles
>>> (populated
>>> in Eclipse environment from an extension point).
>>>
>>> Why was it necessary to introduce this registry? It would seem, at
>>> first
>>> blush, that EMF's support for registration of genmodels would cover this
>>> need by mapping the EPackage to the GenModel, then getting the foreign
>>> model from that.
>>>
>>> I am particularly interested because, in OCL, I need to be able to map
>>> EPackages not only to Profiles but to any UML package in order to find
>>> the UML metamodel from which the Java classes describing run-time
>>> objects
>>> were
>>> generated. Perhaps this mapping needs to be extended to metamodels as
>>> well
>>> as profiles?
>>>
>>> Thanks,
>>>
>>> Christian
>

Report message to a moderator

Re: EPackage to Profile mapping [message #476843 is a reply to message #476438]

Thu, 10 January 2008 16:17

Kenn Hussey

Messages: 1620
Registered: July 2009

Senior Member

James,

Any update on the in-cubicle discussion? Was a decision made to make any
changes here? Note that EMF has added support for registering dynamic
packages (see https://bugs.eclipse.org/bugs/show_bug.cgi?id=145239)...
should consider a similar registry for dynamic profiles? Doing so might
obliviate the need for a profile registry, i.e. it would provide a discovery
mechanism for "known" profiles...

Kenn

"James Bruck" <jbruck@ca.ibm.com> wrote in message
news:fg0l61$p0k$1@build.eclipse.org...
> Hi Christian,
>
> The mapping could be extended. I'll make the long trek over to your
> cubicle so we can discuss the details ;)
>
> Cheers,
> - James.
>
>
> "Christian W. Damus" <cdamus@ca.ibm.com> wrote in message
> news:fft70e$lmn$1@build.eclipse.org...
>> Hi, James,
>>
>> Thanks, that makes sense.
>>
>> Any sense on the idea of extending this function to all generated
>> Packages?
>> :-)
>>
>> cW
>>
>> James Bruck wrote:
>>
>>> Hi Christian,
>>>
>>> The very first attempt at implementing this did involve attempting to
>>> use
>>> the foreign model but a dedicated extension point was deemed a better
>>> choice for several reasons:
>>>
>>> 1. A generator model is a development time artifact that need not be
>>> deployed with the profile.
>>> 2. As a performance concern, parsing the generator model just to get
>>> back
>>> the .uml model which may be one of several foreign models seemed like a
>>> lot of overhead.
>>>
>>> For the above mentioned reasons, an extension point dedicated to
>>> profiles
>>> seemed like a more robust alternative.
>>>
>>> Cheers,
>>>
>>> - James.
>>>
>>>
>>> "Christian W. Damus" <cdamus@ca.ibm.com> wrote in message
>>> news:ffqbkh$9k$1@build.eclipse.org...
>>>> Hi,
>>>>
>>>> The static profile definition capability relies on a mapping of
>>>> EPackage
>>>> namespace URIs to URIs locating the corresponding UML Profiles
>>>> (populated
>>>> in Eclipse environment from an extension point).
>>>>
>>>> Why was it necessary to introduce this registry? It would seem, at
>>>> first
>>>> blush, that EMF's support for registration of genmodels would cover
>>>> this
>>>> need by mapping the EPackage to the GenModel, then getting the foreign
>>>> model from that.
>>>>
>>>> I am particularly interested because, in OCL, I need to be able to map
>>>> EPackages not only to Profiles but to any UML package in order to find
>>>> the UML metamodel from which the Java classes describing run-time
>>>> objects
>>>> were
>>>> generated. Perhaps this mapping needs to be extended to metamodels as
>>>> well
>>>> as profiles?
>>>>
>>>> Thanks,
>>>>
>>>> Christian
>>
>
>

Report message to a moderator

Re: EPackage to Profile mapping [message #476844 is a reply to message #476843]

Fri, 11 January 2008 18:37

james bruck

Messages: 1724
Registered: July 2009

Senior Member

Hi Kenn,

Yes absolutely, UML could use a similar registry to provide a list of all
"known" profiles.
Thanks for pointing it out. I will raise a bugzilla on UML to address
this.

Cheers,
- James.

"Kenn Hussey" <Kenn.Hussey@embarcadero.com> wrote in message
news:fm5gds$prk$1@build.eclipse.org...
> James,
>
> Any update on the in-cubicle discussion? Was a decision made to make any
> changes here? Note that EMF has added support for registering dynamic
> packages (see https://bugs.eclipse.org/bugs/show_bug.cgi?id=145239)...
> should consider a similar registry for dynamic profiles? Doing so might
> obliviate the need for a profile registry, i.e. it would provide a
> discovery mechanism for "known" profiles...
>
> Kenn
>
> "James Bruck" <jbruck@ca.ibm.com> wrote in message
> news:fg0l61$p0k$1@build.eclipse.org...
>> Hi Christian,
>>
>> The mapping could be extended. I'll make the long trek over to your
>> cubicle so we can discuss the details ;)
>>
>> Cheers,
>> - James.
>>
>>
>> "Christian W. Damus" <cdamus@ca.ibm.com> wrote in message
>> news:fft70e$lmn$1@build.eclipse.org...
>>> Hi, James,
>>>
>>> Thanks, that makes sense.
>>>
>>> Any sense on the idea of extending this function to all generated
>>> Packages?
>>> :-)
>>>
>>> cW
>>>
>>> James Bruck wrote:
>>>
>>>> Hi Christian,
>>>>
>>>> The very first attempt at implementing this did involve attempting to
>>>> use
>>>> the foreign model but a dedicated extension point was deemed a better
>>>> choice for several reasons:
>>>>
>>>> 1. A generator model is a development time artifact that need not be
>>>> deployed with the profile.
>>>> 2. As a performance concern, parsing the generator model just to get
>>>> back
>>>> the .uml model which may be one of several foreign models seemed like a
>>>> lot of overhead.
>>>>
>>>> For the above mentioned reasons, an extension point dedicated to
>>>> profiles
>>>> seemed like a more robust alternative.
>>>>
>>>> Cheers,
>>>>
>>>> - James.
>>>>
>>>>
>>>> "Christian W. Damus" <cdamus@ca.ibm.com> wrote in message
>>>> news:ffqbkh$9k$1@build.eclipse.org...
>>>>> Hi,
>>>>>
>>>>> The static profile definition capability relies on a mapping of
>>>>> EPackage
>>>>> namespace URIs to URIs locating the corresponding UML Profiles
>>>>> (populated
>>>>> in Eclipse environment from an extension point).
>>>>>
>>>>> Why was it necessary to introduce this registry? It would seem, at
>>>>> first
>>>>> blush, that EMF's support for registration of genmodels would cover
>>>>> this
>>>>> need by mapping the EPackage to the GenModel, then getting the foreign
>>>>> model from that.
>>>>>
>>>>> I am particularly interested because, in OCL, I need to be able to map
>>>>> EPackages not only to Profiles but to any UML package in order to find
>>>>> the UML metamodel from which the Java classes describing run-time
>>>>> objects
>>>>> were
>>>>> generated. Perhaps this mapping needs to be extended to metamodels as
>>>>> well
>>>>> as profiles?
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Christian
>>>
>>
>>
>
>

Report message to a moderator