Home » Modeling » EMF » GenModel initialization updates EPackage.Registry
| |
Re: GenModel initialization updates EPackage.Registry [message #396149 is a reply to message #396113] |
Wed, 12 October 2005 15:33 |
Baybora Aksoy Messages: 26 Registered: July 2009 |
Junior Member |
|
|
Ed,
thanks for the reply. We are still trying to find out why UML2 didn't have
to override this. However, this insertion we made seems to be working. I
will change it to "containsKey" check to avoid package loading. What would
happen if you make "containsKey" check on EPackage.Registry instead of
comparing the epackage's nsURI to those of Ecore and Genmodel packages?
cheers,
Bora
"Ed Merks" <merks@ca.ibm.com> wrote in message
news:digpj7$srh$1@news.eclipse.org...
> Bora,
>
> UML2 didn't override this so I'm not sure why this wasn't a problem for
> them. One concern here would be that this will load the package if not
> already loaded. Doing a containsKey test would avoid that. This could
> also prevent you from working with packages that happen to collide with
> something in the development environment that wouldn't be there in the
> deployment environment. It might be better to specifically exclude only
> certain things. If some refactoring of this method to make your
> specialization easier to introduce would be worth while, we'd be happy to
> make changes to accommodate that.
>
>
> Baybora Aksoy wrote:
>
>>Hello,
>>
>>We are migrating our code from EMF version 200503100800 to the latest.
>>We discovered that GenModel initialization logic has changed such that
>>GenModel.populateExtendedMetadata() is now getting called during
>>initialization, which is now updating the EPackageRegistry with the
>>packages of the GenModel as follows:
>>
>> GenModel::protected void populateExtendedMetaData(List genPackages) {
>> ....
>> if (!EcorePackage.eNS_URI.equals(ePackage.getNsURI())
>> && ! GenModelPackage.eNS_URI.equals(ePackage.getNsURI())
>>---->>>> && null ==
>>Package.Registry.INSTANCE.getPackage(ePackage.getNsURI()) <<<<<---- our
>>hack
>> )
>> {
>> extendedMetaData.putPackage(ePackage.getNsURI(), ePackage);
>> }
>>
>>Previously somehow this logic did not get called since GenFeatures'
>>containment used to be set AFTER extended metadata initialization. See:
>>
>>GenBase::protected ExtendedMetaData getExtendedMetaData() {
>> return eContainer() == null ? ExtendedMetaData.INSTANCE :
>> ((GenBaseImpl)eContainer()).getExtendedMetaData();
>> }
>>
>>Since we are generating our own code from our models in bootstrap fashion,
>>like like Ecore does, this logic change has caused us some problems.
>>Ecore protects itself via the "if
>>(!EcorePackage.eNS_URI.equals(ePackage.getNsURI()) && !
>>GenModelPackage.eNS_URI.equals(ePackage.getNsURI())" check.
>>I am curious how UML2 deals with this same issue. Can you please advice on
>>the appropriateness of our hack above?
>>Thanks,
>>Bora
>>
>>
|
|
|
Re: GenModel initialization updates EPackage.Registry [message #396150 is a reply to message #396149] |
Wed, 12 October 2005 15:44 |
Ed Merks Messages: 33137 Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
--------------090002050803040509060108
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Bora,
Probably it's not an issue for UML2 because the UML2 stuff isn't
actually generating from UML2, it's also generating from Ecore. I
don't really understand your final question...
Baybora Aksoy wrote:
>Ed,
>thanks for the reply. We are still trying to find out why UML2 didn't have
>to override this. However, this insertion we made seems to be working. I
>will change it to "containsKey" check to avoid package loading. What would
>happen if you make "containsKey" check on EPackage.Registry instead of
>comparing the epackage's nsURI to those of Ecore and Genmodel packages?
>
>cheers,
>Bora
>
>"Ed Merks" <merks@ca.ibm.com> wrote in message
>news:digpj7$srh$1@news.eclipse.org...
>
>
>>Bora,
>>
>>UML2 didn't override this so I'm not sure why this wasn't a problem for
>>them. One concern here would be that this will load the package if not
>>already loaded. Doing a containsKey test would avoid that. This could
>>also prevent you from working with packages that happen to collide with
>>something in the development environment that wouldn't be there in the
>>deployment environment. It might be better to specifically exclude only
>>certain things. If some refactoring of this method to make your
>>specialization easier to introduce would be worth while, we'd be happy to
>>make changes to accommodate that.
>>
>>
>>Baybora Aksoy wrote:
>>
>>
>>
>>>Hello,
>>>
>>>We are migrating our code from EMF version 200503100800 to the latest.
>>>We discovered that GenModel initialization logic has changed such that
>>>GenModel.populateExtendedMetadata() is now getting called during
>>>initialization, which is now updating the EPackageRegistry with the
>>>packages of the GenModel as follows:
>>>
>>> GenModel::protected void populateExtendedMetaData(List genPackages) {
>>> ....
>>> if (!EcorePackage.eNS_URI.equals(ePackage.getNsURI())
>>> && ! GenModelPackage.eNS_URI.equals(ePackage.getNsURI())
>>>---->>>> && null ==
>>>Package.Registry.INSTANCE.getPackage(ePackage.getNsURI()) <<<<<---- our
>>>hack
>>> )
>>> {
>>> extendedMetaData.putPackage(ePackage.getNsURI(), ePackage);
>>> }
>>>
>>>Previously somehow this logic did not get called since GenFeatures'
>>>containment used to be set AFTER extended metadata initialization. See:
>>>
>>>GenBase::protected ExtendedMetaData getExtendedMetaData() {
>>> return eContainer() == null ? ExtendedMetaData.INSTANCE :
>>>((GenBaseImpl)eContainer()).getExtendedMetaData();
>>> }
>>>
>>>Since we are generating our own code from our models in bootstrap fashion,
>>>like like Ecore does, this logic change has caused us some problems.
>>>Ecore protects itself via the "if
>>>(!EcorePackage.eNS_URI.equals(ePackage.getNsURI()) && !
>>>GenModelPackage.eNS_URI.equals(ePackage.getNsURI())" check.
>>>I am curious how UML2 deals with this same issue. Can you please advice on
>>>the appropriateness of our hack above?
>>>Thanks,
>>>Bora
>>>
>>>
>>>
>>>
>
>
>
>
--------------090002050803040509060108
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Bora,<br>
<br>
Probably it's not an issue for UML2 because the UML2 stuff isn't
actually generating from UML2, it's also generating from Ecore. I
don't really understand your final question...<br>
<br>
<br>
Baybora Aksoy wrote:
<blockquote cite="middijaah$2jo$1@news.eclipse.org" type="cite">
<pre wrap="">Ed,
thanks for the reply. We are still trying to find out why UML2 didn't have
to override this. However, this insertion we made seems to be working. I
will change it to "containsKey" check to avoid package loading. What would
happen if you make "containsKey" check on EPackage.Registry instead of
comparing the epackage's nsURI to those of Ecore and Genmodel packages?
cheers,
Bora
"Ed Merks" <a class="moz-txt-link-rfc2396E" href="mailto:merks@ca.ibm.com"><merks@ca.ibm.com></a> wrote in message
<a class="moz-txt-link-freetext" href="news:digpj7$srh$1@news.eclipse.org">news:digpj7$srh$1@news.eclipse.org</a>...
</pre>
<blockquote type="cite">
<pre wrap="">Bora,
UML2 didn't override this so I'm not sure why this wasn't a problem for
them. One concern here would be that this will load the package if not
already loaded. Doing a containsKey test would avoid that. This could
also prevent you from working with packages that happen to collide with
something in the development environment that wouldn't be there in the
deployment environment. It might be better to specifically exclude only
certain things. If some refactoring of this method to make your
specialization easier to introduce would be worth while, we'd be happy to
make changes to accommodate that.
Baybora Aksoy wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Hello,
We are migrating our code from EMF version 200503100800 to the latest.
We discovered that GenModel initialization logic has changed such that
GenModel.populateExtendedMetadata() is now getting called during
initialization, which is now updating the EPackageRegistry with the
packages of the GenModel as follows:
GenModel::protected void populateExtendedMetaData(List genPackages) {
....
if (!EcorePackage.eNS_URI.equals(ePackage.getNsURI())
&& ! GenModelPackage.eNS_URI.equals(ePackage.getNsURI())
---->>>> && null ==
Package.Registry.INSTANCE.getPackage(ePackage.getNsURI()) <<<<<---- our
hack
)
{
extendedMetaData.putPackage(ePackage.getNsURI(), ePackage);
}
Previously somehow this logic did not get called since GenFeatures'
containment used to be set AFTER extended metadata initialization. See:
GenBase::protected ExtendedMetaData getExtendedMetaData() {
return eContainer() == null ? ExtendedMetaData.INSTANCE :
((GenBaseImpl)eContainer()).getExtendedMetaData();
}
Since we are generating our own code from our models in bootstrap fashion,
like like Ecore does, this logic change has caused us some problems.
Ecore protects itself via the "if
(!EcorePackage.eNS_URI.equals(ePackage.getNsURI()) && !
GenModelPackage.eNS_URI.equals(ePackage.getNsURI())" check.
I am curious how UML2 deals with this same issue. Can you please advice on
the appropriateness of our hack above?
Thanks,
Bora
</pre>
</blockquote>
</blockquote>
<pre wrap=""><!---->
</pre>
</blockquote>
<br>
</body>
</html>
--------------090002050803040509060108--
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Re: GenModel initialization updates EPackage.Registry [message #396278 is a reply to message #396150] |
Wed, 19 October 2005 16:11 |
Baybora Aksoy Messages: 26 Registered: July 2009 |
Junior Member |
|
|
This is a multi-part message in MIME format.
------=_NextPart_000_007A_01C5D48D.08FB4790
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hi Ed,
My last question is, would it be appropriate to override =
"populateExtendedMetaData" method as follows ?
GenModel::protected void populateExtendedMetaData(List genPackages) {
....
if (! EPackage.Registry.INSTANCE.containsKey( =
ePackage.getNsURI() ) )=20
// EcorePackage and GenModelPackage uri checks are removed
{
extendedMetaData.putPackage(ePackage.getNsURI(), ePackage);
}
thanks,
Bora
"Ed Merks" <merks@ca.ibm.com> wrote in message =
news:dijav5$3hq$1@news.eclipse.org...
Bora,
Probably it's not an issue for UML2 because the UML2 stuff isn't =
actually generating from UML2, it's also generating from Ecore. I =
don't really understand your final question...
Baybora Aksoy wrote:=20
Ed,
thanks for the reply. We are still trying to find out why UML2 didn't =
have=20
to override this. However, this insertion we made seems to be working. I =
will change it to "containsKey" check to avoid package loading. What =
would=20
happen if you make "containsKey" check on EPackage.Registry instead of=20
comparing the epackage's nsURI to those of Ecore and Genmodel packages?
cheers,
Bora
"Ed Merks" <merks@ca.ibm.com> wrote in message=20
news:digpj7$srh$1@news.eclipse.org...
Bora,
UML2 didn't override this so I'm not sure why this wasn't a problem for=20
them. One concern here would be that this will load the package if not =
already loaded. Doing a containsKey test would avoid that. This could=20
also prevent you from working with packages that happen to collide with=20
something in the development environment that wouldn't be there in the=20
deployment environment. It might be better to specifically exclude =
only=20
certain things. If some refactoring of this method to make your=20
specialization easier to introduce would be worth while, we'd be happy =
to=20
make changes to accommodate that.
Baybora Aksoy wrote:
Hello,
We are migrating our code from EMF version 200503100800 to the latest.
We discovered that GenModel initialization logic has changed such that=20
GenModel.populateExtendedMetadata() is now getting called during=20
initialization, which is now updating the EPackageRegistry with the=20
packages of the GenModel as follows:
GenModel::protected void populateExtendedMetaData(List genPackages) {
....
if (!EcorePackage.eNS_URI.equals(ePackage.getNsURI())
&& ! GenModelPackage.eNS_URI.equals(ePackage.getNsURI())
---->>>> && null =3D=3D=20
Package.Registry.INSTANCE.getPackage(ePackage.getNsURI()) <<<<<---- =
our=20
hack
)
{
extendedMetaData.putPackage(ePackage.getNsURI(), ePackage);
}
Previously somehow this logic did not get called since GenFeatures'=20
containment used to be set AFTER extended metadata initialization. See:
GenBase::protected ExtendedMetaData getExtendedMetaData() {
return eContainer() =3D=3D null ? ExtendedMetaData.INSTANCE :=20
((GenBaseImpl)eContainer()).getExtendedMetaData();
}
Since we are generating our own code from our models in bootstrap =
fashion,=20
like like Ecore does, this logic change has caused us some problems.
Ecore protects itself via the "if=20
(!EcorePackage.eNS_URI.equals(ePackage.getNsURI()) && !=20
GenModelPackage.eNS_URI.equals(ePackage.getNsURI())" check.
I am curious how UML2 deals with this same issue. Can you please advice =
on=20
the appropriateness of our hack above?
Thanks,
Bora
=20
=20
------=_NextPart_000_007A_01C5D48D.08FB4790
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type =
content=3Dtext/html;charset=3DISO-8859-1>
<META content=3D"MSHTML 6.00.2900.2769" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY text=3D#000000 bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Hi Ed,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>My last question is, would it be =
appropriate=20
to override "populateExtendedMetaData" method as follows ?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>GenModel::protected void=20
populateExtendedMetaData(List genPackages)=20
{<BR> =20
.....<BR> if (!=20
EPackage.Registry.INSTANCE.containsKey( ePackage.getNsURI() )=20
) </FONT></DIV>
<DIV><FONT face=3DArial size=3D2> =
//=20
EcorePackage and GenModelPackage uri checks are=20
removed<BR> =20
{<BR> =20
extendedMetaData.putPackage(ePackage.getNsURI(),=20
ePackage);<BR> =
}</FONT></DIV>
<DIV><FONT><BR><FONT face=3DArial size=3D2>thanks,</FONT></FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Bora</FONT></DIV>
<BLOCKQUOTE=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<DIV>"Ed Merks" <<A =
href=3D"mailto:merks@ca.ibm.com">merks@ca.ibm.com</A>>=20
wrote in message <A=20
=
href=3D"news:dijav5$3hq$1@news.eclipse.org">news:dijav5$3hq$1@news.eclips=
e.org</A>...</DIV>Bora,<BR><BR>Probably=20
it's not an issue for UML2 because the UML2 stuff isn't actually =
generating=20
from UML2, it's also generating from Ecore. I don't really =
understand your final question...<BR><BR><BR>Baybora Aksoy wrote:=20
<BLOCKQUOTE cite=3Dmiddijaah$2jo$1@news.eclipse.org type=3D"cite"><PRE =
wrap=3D"">Ed,
thanks for the reply. We are still trying to find out why UML2 didn't =
have=20
to override this. However, this insertion we made seems to be working. I =
will change it to "containsKey" check to avoid package loading. What =
would=20
happen if you make "containsKey" check on EPackage.Registry instead of=20
comparing the epackage's nsURI to those of Ecore and Genmodel packages?
cheers,
Bora
"Ed Merks" <A class=3Dmoz-txt-link-rfc2396E =
href=3D"mailto:merks@ca.ibm.com"><merks@ca.ibm.com></A> wrote in =
message=20
<A class=3Dmoz-txt-link-freetext =
href=3D"news:digpj7$srh$1@news.eclipse.org">news:digpj7$srh$1@news.eclips=
e.org</A>...
</PRE>
<BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">Bora,
UML2 didn't override this so I'm not sure why this wasn't a problem for=20
them. One concern here would be that this will load the package if not =
already loaded. Doing a containsKey test would avoid that. This could=20
also prevent you from working with packages that happen to collide with=20
something in the development environment that wouldn't be there in the=20
deployment environment. It might be better to specifically exclude =
only=20
certain things. If some refactoring of this method to make your=20
specialization easier to introduce would be worth while, we'd be happy =
to=20
make changes to accommodate that.
Baybora Aksoy wrote:
</PRE>
<BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">Hello,
We are migrating our code from EMF version 200503100800 to the latest.
We discovered that GenModel initialization logic has changed such that=20
GenModel.populateExtendedMetadata() is now getting called during=20
initialization, which is now updating the EPackageRegistry with the=20
packages of the GenModel as follows:
GenModel::protected void populateExtendedMetaData(List genPackages) {
....
if (!EcorePackage.eNS_URI.equals(ePackage.getNsURI())
&& ! =
GenModelPackage.eNS_URI.equals(ePackage.getNsURI())
---->>>> && null =3D=3D=20
Package.Registry.INSTANCE.getPackage(ePackage.getNsURI()) =
<<<<<---- our=20
hack
)
{
extendedMetaData.putPackage(ePackage.getNsURI(), ePackage);
}
Previously somehow this logic did not get called since GenFeatures'=20
containment used to be set AFTER extended metadata initialization. See:
GenBase::protected ExtendedMetaData getExtendedMetaData() {
return eContainer() =3D=3D null ? ExtendedMetaData.INSTANCE :=20
((GenBaseImpl)eContainer()).getExtendedMetaData();
}
Since we are generating our own code from our models in bootstrap =
fashion,=20
like like Ecore does, this logic change has caused us some problems.
Ecore protects itself via the "if=20
(!EcorePackage.eNS_URI.equals(ePackage.getNsURI()) && !=20
GenModelPackage.eNS_URI.equals(ePackage.getNsURI())" check.
I am curious how UML2 deals with this same issue. Can you please advice =
on=20
the appropriateness of our hack above?
Thanks,
Bora
</PRE></BLOCKQUOTE></BLOCKQUOTE><PRE wrap=3D""><!---->
</PRE></BLOCKQUOTE><BR></BLOCKQUOTE></BODY></HTML>
------=_NextPart_000_007A_01C5D48D.08FB4790--
|
|
|
Re: GenModel initialization updates EPackage.Registry [message #396279 is a reply to message #396278] |
Wed, 19 October 2005 16:17 |
Ed Merks Messages: 33137 Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
--------------040203000308010901080807
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Baybora,
You mean correct in general? I don't think so because this will filter
out anything that just happens to match something in the development
environment. But since you might never hit that case, this will appear
to be generally correct until you hit an actual corner case.
Baybora Aksoy wrote:
> Hi Ed,
>
> My last question is, would it be appropriate to override
> "populateExtendedMetaData" method as follows ?
>
> GenModel::protected void populateExtendedMetaData(List genPackages) {
> .....
> if (! EPackage.Registry.INSTANCE.containsKey(
> ePackage.getNsURI() ) )
> // EcorePackage and GenModelPackage uri checks are removed
> {
> extendedMetaData.putPackage(ePackage.getNsURI(), ePackage);
> }
>
> thanks,
> Bora
>
> "Ed Merks" <merks@ca.ibm.com <mailto:merks@ca.ibm.com>> wrote in
> message news:dijav5$3hq$1@news.eclipse.org...
> Bora,
>
> Probably it's not an issue for UML2 because the UML2 stuff isn't
> actually generating from UML2, it's also generating from Ecore.
> I don't really understand your final question...
>
>
> Baybora Aksoy wrote:
>
>>Ed,
>>thanks for the reply. We are still trying to find out why UML2 didn't have
>>to override this. However, this insertion we made seems to be working. I
>>will change it to "containsKey" check to avoid package loading. What would
>>happen if you make "containsKey" check on EPackage.Registry instead of
>>comparing the epackage's nsURI to those of Ecore and Genmodel packages?
>>
>>cheers,
>>Bora
>>
>>"Ed Merks" <merks@ca.ibm.com> wrote in message
>>news:digpj7$srh$1@news.eclipse.org...
>>
>>
>>>Bora,
>>>
>>>UML2 didn't override this so I'm not sure why this wasn't a problem for
>>>them. One concern here would be that this will load the package if not
>>>already loaded. Doing a containsKey test would avoid that. This could
>>>also prevent you from working with packages that happen to collide with
>>>something in the development environment that wouldn't be there in the
>>>deployment environment. It might be better to specifically exclude only
>>>certain things. If some refactoring of this method to make your
>>>specialization easier to introduce would be worth while, we'd be happy to
>>>make changes to accommodate that.
>>>
>>>
>>>Baybora Aksoy wrote:
>>>
>>>
>>>
>>>>Hello,
>>>>
>>>>We are migrating our code from EMF version 200503100800 to the latest.
>>>>We discovered that GenModel initialization logic has changed such that
>>>>GenModel.populateExtendedMetadata() is now getting called during
>>>>initialization, which is now updating the EPackageRegistry with the
>>>>packages of the GenModel as follows:
>>>>
>>>> GenModel::protected void populateExtendedMetaData(List genPackages) {
>>>> ....
>>>> if (!EcorePackage.eNS_URI.equals(ePackage.getNsURI())
>>>> && ! GenModelPackage.eNS_URI.equals(ePackage.getNsURI())
>>>>---->>>> && null ==
>>>>Package.Registry.INSTANCE.getPackage(ePackage.getNsURI()) <<<<<---- our
>>>>hack
>>>> )
>>>> {
>>>> extendedMetaData.putPackage(ePackage.getNsURI(), ePackage);
>>>> }
>>>>
>>>>Previously somehow this logic did not get called since GenFeatures'
>>>>containment used to be set AFTER extended metadata initialization. See:
>>>>
>>>>GenBase::protected ExtendedMetaData getExtendedMetaData() {
>>>> return eContainer() == null ? ExtendedMetaData.INSTANCE :
>>>>((GenBaseImpl)eContainer()).getExtendedMetaData();
>>>> }
>>>>
>>>>Since we are generating our own code from our models in bootstrap fashion,
>>>>like like Ecore does, this logic change has caused us some problems.
>>>>Ecore protects itself via the "if
>>>>(!EcorePackage.eNS_URI.equals(ePackage.getNsURI()) && !
>>>>GenModelPackage.eNS_URI.equals(ePackage.getNsURI())" check.
>>>>I am curious how UML2 deals with this same issue. Can you please advice on
>>>>the appropriateness of our hack above?
>>>>Thanks,
>>>>Bora
>>>>
>>>>
>>>>
>>>>
>>
>>
>>
>>
>
--------------040203000308010901080807
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Baybora,<br>
<br>
You mean correct in general? I don't think so because this will filter
out anything that just happens to match something in the development
environment. But since you might never hit that case, this will appear
to be generally correct until you hit an actual corner case.<br>
<br>
<br>
Baybora Aksoy wrote:
<blockquote cite="middj5r53$o3c$1@news.eclipse.org" type="cite">
<meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
<meta content="MSHTML 6.00.2900.2769" name="GENERATOR">
<style></style>
<div><font face="Arial" size="2">Hi Ed,</font></div>
<div> </div>
<div><font face="Arial" size="2">My last question is, would it be
appropriate to override "populateExtendedMetaData" method as follows ?</font></div>
<div> </div>
<div><font face="Arial" size="2">GenModel::protected void
populateExtendedMetaData(List genPackages) {<br>
.....<br>
if (! EPackage.Registry.INSTANCE.containsKey(
ePackage.getNsURI() ) ) </font></div>
<div><font face="Arial" size="2"> // EcorePackage and
GenModelPackage uri checks are removed<br>
{<br>
extendedMetaData.putPackage(ePackage.getNsURI(), ePackage);<br>
}</font></div>
<div><font><br>
<font face="Arial" size="2">thanks,</font></font></div>
<div><font face="Arial" size="2">Bora</font></div>
<blockquote
style="border-left: 2px solid rgb(0, 0, 0); padding-right: 0px; padding-left: 5px; margin-left: 5px; margin-right: 0px;">
<div>"Ed Merks" <<a href="mailto:merks@ca.ibm.com">merks@ca.ibm.com</a>>
wrote in message <a href="news:dijav5$3hq$1@news.eclipse.org">news:dijav5$3hq$1@news.eclipse.org</a>...</div>
Bora,<br>
<br>
Probably it's not an issue for UML2 because the UML2 stuff isn't
actually generating from UML2, it's also generating from Ecore. I
don't really understand your final question...<br>
<br>
<br>
Baybora Aksoy wrote:
<blockquote cite="middijaah$2jo$1@news.eclipse.org" type="cite">
<pre wrap="">Ed,
thanks for the reply. We are still trying to find out why UML2 didn't have
to override this. However, this insertion we made seems to be working. I
will change it to "containsKey" check to avoid package loading. What would
happen if you make "containsKey" check on EPackage.Registry instead of
comparing the epackage's nsURI to those of Ecore and Genmodel packages?
cheers,
Bora
"Ed Merks" <a class="moz-txt-link-rfc2396E"
href="mailto:merks@ca.ibm.com"><merks@ca.ibm.com></a> wrote in message
<a class="moz-txt-link-freetext"
href="news:digpj7$srh$1@news.eclipse.org">news:digpj7$srh$1@news.eclipse.org</a>...
</pre>
<blockquote type="cite">
<pre wrap="">Bora,
UML2 didn't override this so I'm not sure why this wasn't a problem for
them. One concern here would be that this will load the package if not
already loaded. Doing a containsKey test would avoid that. This could
also prevent you from working with packages that happen to collide with
something in the development environment that wouldn't be there in the
deployment environment. It might be better to specifically exclude only
certain things. If some refactoring of this method to make your
specialization easier to introduce would be worth while, we'd be happy to
make changes to accommodate that.
Baybora Aksoy wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Hello,
We are migrating our code from EMF version 200503100800 to the latest.
We discovered that GenModel initialization logic has changed such that
GenModel.populateExtendedMetadata() is now getting called during
initialization, which is now updating the EPackageRegistry with the
packages of the GenModel as follows:
GenModel::protected void populateExtendedMetaData(List genPackages) {
....
if (!EcorePackage.eNS_URI.equals(ePackage.getNsURI())
&& ! GenModelPackage.eNS_URI.equals(ePackage.getNsURI())
---->>>> && null ==
Package.Registry.INSTANCE.getPackage(ePackage.getNsURI()) <<<<<---- our
hack
)
{
extendedMetaData.putPackage(ePackage.getNsURI(), ePackage);
}
Previously somehow this logic did not get called since GenFeatures'
containment used to be set AFTER extended metadata initialization. See:
GenBase::protected ExtendedMetaData getExtendedMetaData() {
return eContainer() == null ? ExtendedMetaData.INSTANCE :
((GenBaseImpl)eContainer()).getExtendedMetaData();
}
Since we are generating our own code from our models in bootstrap fashion,
like like Ecore does, this logic change has caused us some problems.
Ecore protects itself via the "if
(!EcorePackage.eNS_URI.equals(ePackage.getNsURI()) && !
GenModelPackage.eNS_URI.equals(ePackage.getNsURI())" check.
I am curious how UML2 deals with this same issue. Can you please advice on
the appropriateness of our hack above?
Thanks,
Bora
</pre>
</blockquote>
</blockquote>
<pre wrap=""><!---->
</pre>
</blockquote>
<br>
</blockquote>
</blockquote>
<br>
</body>
</html>
--------------040203000308010901080807--
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Goto Forum:
Current Time: Fri Apr 19 12:49:41 GMT 2024
Powered by FUDForum. Page generated in 0.03129 seconds
|