Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » etypes.ecore Model in CDO Source(Why is etypes.ecore model using Ecore.ecore metamodel?)
etypes.ecore Model in CDO Source [message #1244046] Tue, 11 February 2014 20:58 Go to next message
UmaShankar Subramani is currently offline UmaShankar SubramaniFriend
Messages: 194
Registered: December 2011
Location: SWEDEN
Senior Member
CDO source has a model named etypes.ecore, which is using the development version of Ecore.ecore metamodel.


What is the purpose of doing this? Is this the way of extending Ecore to provide CDO support for .ecore models?

[Updated on: Tue, 11 February 2014 21:15]

Report message to a moderator

Re: etypes.ecore [message #1244307 is a reply to message #1244046] Wed, 12 February 2014 06:28 Go to previous messageGo to next message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6682
Registered: July 2009
Senior Member
Am 11.02.2014 21:58, schrieb UmaShankar Subramani:
> CDO source has a model named etypes.ecore, which is using the development version of Ecore.ecore metamodel.
>
>
> What is the purpose of doing this?
That Etypes refers to the development time version of Ecore was not really necessary and I've fixed that in the context of

427767: Enhance the Etypes and Eresource models
https://bugs.eclipse.org/bugs/show_bug.cgi?id=427767

Now you should no longer see a reference to the Ecore model.

> Is this the way of extending Ecore to provide CDO support for .ecore models?
No.

Cheers
/Eike

----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper


Re: etypes.ecore [message #1244459 is a reply to message #1244307] Wed, 12 February 2014 11:24 Go to previous messageGo to next message
UmaShankar Subramani is currently offline UmaShankar SubramaniFriend
Messages: 194
Registered: December 2011
Location: SWEDEN
Senior Member
Hi Eike,

Thanks for the information.

But how does Ecore models get CDO support. That is, when an EObject is added/deleted in a .ecore model, How is does the methods in CDOResource is notified.
Re: etypes.ecore [message #1244491 is a reply to message #1244459] Wed, 12 February 2014 12:11 Go to previous messageGo to next message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6682
Registered: July 2009
Senior Member
Am 12.02.2014 12:24, schrieb UmaShankar Subramani:
> Hi Eike,
>
> Thanks for the information.
>
> But how does Ecore models get CDO support. That is, when an EObject is added/deleted in a .ecore model, How is does
> the methods in CDOResource is notified.

I get the impression that I read your questions more carefully than you read my answers. I've already told you:

That's explained here: https://wiki.eclipse.org/CDO/Preparing_EMF_Models

Is there something specific in that article that you don't understand? Have you tried it out?

Cheers
/Eike

----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper


Re: etypes.ecore [message #1244506 is a reply to message #1244491] Wed, 12 February 2014 12:39 Go to previous messageGo to next message
UmaShankar Subramani is currently offline UmaShankar SubramaniFriend
Messages: 194
Registered: December 2011
Location: SWEDEN
Senior Member
Hi Eike,

I am really sorry. The problem is that, my question was not clear enough.

My question is not about using CDOMigrator. I am asking how CDO source works.

Consider, I have CDO source installed on my computer. When I create an Ecore model, it works
normally. But, when I create another Ecore model in the runtime instance(with CDO support)
it works under CDO. This is my question.

So, I believe that the functionality of Ecore itself is extended/overridden by CDO. Where has
this happened. This is my question.

If I create a custom metamodel of my own, I can generate the code for it. Than I can have the custom implementation there.

But how the Ecore functionality itself is overridden in CDO?





[Updated on: Wed, 12 February 2014 13:09]

Report message to a moderator

Re: etypes.ecore [message #1245089 is a reply to message #1244506] Thu, 13 February 2014 09:22 Go to previous messageGo to next message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6682
Registered: July 2009
Senior Member
Am 12.02.2014 13:39, schrieb UmaShankar Subramani:
> Hi Eike,
>
> I am really sorry. The problem is that, my question was not clear enough.
> My question is not about using CDOMigrator. I am asking how CDO source works.
CDOObjectImpl extends EObjectImpl (more or less) and the CDO migrator modifies the GenModels to generate your model
classes as subclasses of CDOObjectImpl instead of EObjectImpl.

> Consider, I have CDO source installed on my computer. When I create an Ecore model, it works
> normally.
Do you want to say that you can save and load XML files? Or what is "normally"?

> But, when I create another Ecore model
Is that another instance of the same EPackage?

> in the runtime instance(with CDO support)
> it works under CDO. This is my question.
Actually I don't see a question here. If you want to ask if your models, when generated for CDO, can still be used with
XML persistence, then yes, they can.

> So, I believe that the functionality of Ecore itself is extended/overridden by CDO.
I suspect that you're using the term Ecore wrongly, too generally. But in some sense CDO extends Ecore because EObject
is a concept of the Ecore meta meta model.

> Where has this happened. This is my question.
All starts here:

http://git.eclipse.org/c/cdo/cdo.git/tree/plugins/org.eclipse.emf.cdo/src/org/eclipse/emf/internal/cdo/CDOObjectImpl.java

Cheers
/Eike

----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper


Re: etypes.ecore [message #1247829 is a reply to message #1245089] Sun, 16 February 2014 17:16 Go to previous messageGo to next message
UmaShankar Subramani is currently offline UmaShankar SubramaniFriend
Messages: 194
Registered: December 2011
Location: SWEDEN
Senior Member
>> Hi Eike,
>>
>> I am really sorry. The problem is that, my question was not clear enough.
>> My question is not about using CDOMigrator. I am asking how CDO source works.
>CDOObjectImpl extends EObjectImpl (more or less) and the CDO migrator modifies the >GenModels to generate your model
>classes as subclasses of CDOObjectImpl instead of EObjectImpl.

Okay. I understand this. But this process happens when I migrate my Ecore model using CDOMigrator. I want to know how the same thing happens when I create a new Ecore Model. How is the newly created Ecore model related to CDO. Where is this done in the plugin project org.eclipse.emf.cdo

>> Consider, I have CDO source installed on my computer. When I create an Ecore >>model, it works normally.
>Do you want to say that you can save and load XML files? Or what is "normally"?
>> But, when I create another Ecore model
>Is that another instance of the same EPackage?
>> in the runtime instance(with CDO support)
>> it works under CDO. This is my question.
>Actually I don't see a question here. If you want to ask if your models, when >generated for CDO, can still be used with
>XML persistence, then yes, they can.

If I have no CDO installed, during addition of an Ecore object, ResourceImpl.attached(EObject object) method is invoked. (This is what I call Normally)

If I have CDO installed, addition of Ecore object invokes CDOResourceImpl.attached(EObject object) method. (This is what I call-Ecore with CDO Support)

When Ecore model is created inside a CDO environment, the EObjects are created as CDOObjects.
Where is this happenning?, How the CDO classes are notified, when an Ecore model is created, when a new object is added/deleted? This is what I wanted to ask.


>> So, I believe that the functionality of Ecore itself is extended/overridden by >>CDO.
>I suspect that you're using the term Ecore wrongly, too generally. But in some sense >CDO extends Ecore because EObject
>is a concept of the Ecore meta meta model.

>> Where has this happened. This is my question.
>All starts here:
http://git.eclipse.org/c/cdo/cdo.git/tree/plugins/org.eclipse.emf.cdo/src/org/eclipse/emf/internal/cdo/CDOObjectImpl.java

Thanks. This is the most useful CDO class.


/Uma

[Updated on: Sun, 16 February 2014 17:38]

Report message to a moderator

Re: etypes.ecore [message #1247895 is a reply to message #1247829] Sun, 16 February 2014 19:02 Go to previous messageGo to next message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6682
Registered: July 2009
Senior Member
Uma,

If your model is generated for CDO then CDOObjects are created and if it is not generated for CDO then no CDOObjects are
created.

Cheers
/Eike

----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper


Am 16.02.2014 18:16, schrieb UmaShankar Subramani:
>>> Hi Eike,
>>>
>>> I am really sorry. The problem is that, my question was not clear enough.
>>> My question is not about using CDOMigrator. I am asking how CDO source works.
>> CDOObjectImpl extends EObjectImpl (more or less) and the CDO migrator modifies the >GenModels to generate your model
>> classes as subclasses of CDOObjectImpl instead of EObjectImpl.
>
> Okay. I understand this. But this process happens when I migrate my Ecore model using CDOMigrator. I want to know
> how the same thing happens when I create a new Ecore Model. How is the newly created Ecore model related to CDO.
>
>>> Consider, I have CDO source installed on my computer. When I create an Ecore >>model, it works normally.
>> Do you want to say that you can save and load XML files? Or what is "normally"?
>>> But, when I create another Ecore model
>> Is that another instance of the same EPackage?
>>> in the runtime instance(with CDO support)
>>> it works under CDO. This is my question.
>> Actually I don't see a question here. If you want to ask if your models, when >generated for CDO, can still be used
>> with XML persistence, then yes, they can.
>
> If I have no CDO installed, during addition of an Ecore object, ResourceImpl.attached(EObject object) method is
> invoked. (This is what I call Normally)
>
> If I have CDO installed, addition of Ecore object invokes CDOResourceImpl.attached(EObject object) method. (This is
> what I call-Ecore with CDO Support)
>
> When Ecore model is created inside a CDO environment, the EObjects are created as CDOObjects. Where is this
> happenning?, How the CDO classes are notified, when an Ecore model is created, when a new object is added/deleted?
> This is what I wanted to ask.
>
>
>>> So, I believe that the functionality of Ecore itself is extended/overridden by >>CDO.
>> I suspect that you're using the term Ecore wrongly, too generally. But in some sense >CDO extends Ecore because
>> EObject is a concept of the Ecore meta meta model.
>
>>> Where has this happened. This is my question.
>> All starts here:
> http://git.eclipse.org/c/cdo/cdo.git/tree/plugins/org.eclipse.emf.cdo/src/org/eclipse/emf/internal/cdo/CDOObjectImpl.java
>
>


Re: etypes.ecore [message #1248672 is a reply to message #1247829] Mon, 17 February 2014 14:28 Go to previous message
Christian Damus is currently offline Christian DamusFriend
Messages: 1270
Registered: July 2009
Location: Canada
Senior Member

Hi,

Ecore is handled by CDO as a "legacy model": because Ecore is
generated without native CDO support (its implementation classes do not
implement the CDOObject interface, neither by extending CDOObjectImpl
nor by other means), CDO has to "adapt" the objects in an Ecore model
instance. This is accomplished by means of an Adapter (in the EMF
sense) attached to each object. It is this adapter that implements the
CDOObject protocol, providing the bridge that integrates Ecore into the
CDO framework.

You will see this if you look into the eAdapters() list of any element
of an Ecore model loaded from a CDO repository. You will find a
CDOLegacyAdapter attached to each.

All "model" resources in a CDO repository necessarily are CDOResources:
that's just what the resource factory associated with a CDO view's
resource-set will create, and what is required for persistence in CDO.
Whether it contains CDO-native (generated for CDO) models or "legacy
models" such as Ecore is immaterial.

HTH,

Christian


On 2014-02-16 17:16:23 +0000, UmaShankar Subramani said:

>>>
>>> Hi Eike,
>>>
>>> I am really sorry. The problem is that, my question was not clear enough.
>>> My question is not about using CDOMigrator. I am asking how CDO source works.
>> CDOObjectImpl extends EObjectImpl (more or less) and the CDO migrator
>> modifies the >GenModels to generate your model classes as subclasses of
>> CDOObjectImpl instead of EObjectImpl.
>
> Okay. I understand this. But this process happens when I migrate my
> Ecore model using CDOMigrator. I want to know how the same thing
> happens when I create a new Ecore Model. How is the newly created
> Ecore model related to CDO.
>
>>> Consider, I have CDO source installed on my computer. When I create an
>>> Ecore >>model, it works normally.
>> Do you want to say that you can save and load XML files? Or what is "normally"?
>>> But, when I create another Ecore model
>> Is that another instance of the same EPackage?
>>> in the runtime instance(with CDO support)
>>> it works under CDO. This is my question.
>> Actually I don't see a question here. If you want to ask if your
>> models, when >generated for CDO, can still be used with XML
>> persistence, then yes, they can.
>
> If I have no CDO installed, during addition of an Ecore object,
> ResourceImpl.attached(EObject object) method is invoked. (This is what
> I call Normally)
>
> If I have CDO installed, addition of Ecore object invokes
> CDOResourceImpl.attached(EObject object) method. (This is what I
> call-Ecore with CDO Support)
>
> When Ecore model is created inside a CDO environment, the EObjects are
> created as CDOObjects. Where is this happenning?, How the CDO classes
> are notified, when an Ecore model is created, when a new object is
> added/deleted? This is what I wanted to ask.
>
>
>>> So, I believe that the functionality of Ecore itself is
>>> extended/overridden by >>CDO.
>> I suspect that you're using the term Ecore wrongly, too generally. But
>> in some sense >CDO extends Ecore because EObject is a concept of the
>> Ecore meta meta model.
>
>>> Where has this happened. This is my question.
>> All starts here:
> http://git.eclipse.org/c/cdo/cdo.git/tree/plugins/org.eclipse.emf.cdo/src/org/eclipse/emf/internal/cdo/CDOObjectImpl.java
>
Previous Topic:Modifying EMF createPages()
Next Topic:Reflection, class not found [SOLVED]
Goto Forum:
  


Current Time: Thu Mar 28 20:21:23 GMT 2024

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

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

Back to the top