Home » Modeling » EMF » [CDO]: simple usage scenario?
|
| Re: [CDO]: simple usage scenario? [message #419805 is a reply to message #419783] |
Sat, 07 June 2008 04:09   |
|
Hi André,
CDO does not constrain too much the way you can build clients on top.
You can use any of the EMF APIs plus the ones that CDO offers to manage
the session, the views and transactions. You should myke yourself
familiar with the respective interfaces CDOSession, CDOView and
CDOTransaction to be able to write own clients.
If you want to you could even derive from the shipped CDO UI, i.e.
CDOSessionView and CDOEditor. It is meant as an exemplary, generic user
interface to demonstrate the usage of the client side API.
Currently it is not yet possible togenerate a CDO enabled EMF editor out
of the box. It would be a nice exercise to provide the needed JET
templates. I must admit that I did not manage, due to time constraints,
to learn how to use the new contributeable JET templates (sorry Dave).
If you are to start analyze my modifications to the generated editor
that led to the CDOEditor, note that I added the JavaDoc tag "@ADDED" to
each new editor member. The changed ones carry a "@generated NOT". If
you configure the Java compiler to create Java Tasks you'll get a
helpful overview in the rulers. Another trick I heard of is the usage of
Mint (http://www.eclipse.org/modeling/emft/?project=mint).
More comments below...
André Dietisheim schrieb:
> Hi Eike
>
> now that I could create my resources on the repo I started wondering
> how a simple client could look like and how it could be used (CRUD).
> The CRUD operations are handled in the CDO-sessions view by creating
> objects in a resource, viewing a resource and editing/deleting its
> objects. If I get your concepts right a resource is a schema in the
> RDBMS world, right?
I don't think so. Basically it depends on the store implementation you
are using on server side (you are still using the default DBStore?). But
usually the database *schema* represents the committed *packages* in
addition to some "system" tables.
In CDO a *resource* is a first class *object*. It is only special in
that you may not further subclass it or nest it into other objects.
Think of them as named entry points into the multi-rooted tree of
persistent objects of the repository.
> If I'd like something more handy than the generic EMF Editor, I'll
> have to create one or does anything already exist?
> One further question that pops up to my humble mind is the purpose of
> the creation wizard.
Actually I can't see a question mark ;-)
Which creation wizard do you mean, the EMF generated one or the CDO
generic one?
Cheers
/Eike
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: [CDO]: simple usage scenario? [message #419812 is a reply to message #419805] |
Sat, 07 June 2008 12:10 |
 Andre Dietisheim
Messages: 131
Registered: July 2009 |
Senior Member |
|
|
Hi Eike
thanks, I start getting the big picture...
further comments inline:
> CDO does not constrain too much the way you can build clients on top.
> You can use any of the EMF APIs plus the ones that CDO offers to manage
> the session, the views and transactions. You should myke yourself
> familiar with the respective interfaces CDOSession, CDOView and
> CDOTransaction to be able to write own clients.
okay, got it.
>
> If you want to you could even derive from the shipped CDO UI, i.e.
> CDOSessionView and CDOEditor. It is meant as an exemplary, generic user
> interface to demonstrate the usage of the client side API.
If I get things right, the CDO Editor is the one that pops up when
editing resources selected in the sessions view.
What I don't understand yet is the purpose of the plugin that gets
generated out of the genmodel (*.editor). The code shows a
multipage-editor.
Related to this are the functionalities I discovered in my
runtime-Workbench: I now have a EMF Model Creation Wizard that may
create my own types. The models are created in the workspace. If I
understand this right, the editing counterpart of this wizard is the
editor I talk of above. What is the puropose of this wizard and the
editor (I'm defenitively a EMF Rookie).
>
> Currently it is not yet possible togenerate a CDO enabled EMF editor out
> of the box. It would be a nice exercise to provide the needed JET
> templates. I must admit that I did not manage, due to time constraints,
> to learn how to use the new contributeable JET templates (sorry Dave).
> If you are to start analyze my modifications to the generated editor
> that led to the CDOEditor, note that I added the JavaDoc tag "@ADDED" to
> each new editor member. The changed ones carry a "@generated NOT". If
> you configure the Java compiler to create Java Tasks you'll get a
> helpful overview in the rulers. Another trick I heard of is the usage of
> Mint (http://www.eclipse.org/modeling/emft/?project=mint).
I had a quick look and things look very interesting there. Another very
interesting component for editing Ecore-Models is the Ecore Diagram
Editor RFE.
One more thing (I have plenty of them ;-)) I need to know is how to
access the CDO-Resources by another client. I Have a JBPM-Workflow and
I'll have to implement nodes that manipulate the CDO-Resources (CDO is
intended to be an inventory, the CDO enabled client shall be a resource
manipulation GUI). Reading thorugh the posts in here I found out that a
possible strategy would be to have CDO on top of Teneo-Hibernate. The
workflow-nodes could the access the storage on behalf of their own
hibernate-layer. If I get things right, I could also use CDO client code
in those. The major issue here would be how to operate jBPM in a OSGI
enabled environment. Any hints here?
Cheers
André
>
> More comments below...
>
>
> André Dietisheim schrieb:
>> Hi Eike
>>
>> now that I could create my resources on the repo I started wondering
>> how a simple client could look like and how it could be used (CRUD).
>> The CRUD operations are handled in the CDO-sessions view by creating
>> objects in a resource, viewing a resource and editing/deleting its
>> objects. If I get your concepts right a resource is a schema in the
>> RDBMS world, right?
> I don't think so. Basically it depends on the store implementation you
> are using on server side (you are still using the default DBStore?). But
> usually the database *schema* represents the committed *packages* in
> addition to some "system" tables.
>
> In CDO a *resource* is a first class *object*. It is only special in
> that you may not further subclass it or nest it into other objects.
> Think of them as named entry points into the multi-rooted tree of
> persistent objects of the repository.
>
>> If I'd like something more handy than the generic EMF Editor, I'll
>> have to create one or does anything already exist?
>> One further question that pops up to my humble mind is the purpose of
>> the creation wizard.
> Actually I can't see a question mark ;-)
> Which creation wizard do you mean, the EMF generated one or the CDO
> generic one?
>
> Cheers
> /Eike
|
|
|
| Re: [CDO]: simple usage scenario? [message #419814 is a reply to message #419812] |
Sat, 07 June 2008 13:14 |
|
Hi André
Comments below...
André Dietisheim schrieb:
> Hi Eike
>
> thanks, I start getting the big picture...
> further comments inline:
>
>> CDO does not constrain too much the way you can build clients on top.
>> You can use any of the EMF APIs plus the ones that CDO offers to
>> manage the session, the views and transactions. You should myke
>> yourself familiar with the respective interfaces CDOSession, CDOView
>> and CDOTransaction to be able to write own clients.
>
> okay, got it.
>
>>
>> If you want to you could even derive from the shipped CDO UI, i.e.
>> CDOSessionView and CDOEditor. It is meant as an exemplary, generic
>> user interface to demonstrate the usage of the client side API.
>
> If I get things right, the CDO Editor is the one that pops up when
> editing resources selected in the sessions view.
Right.
> What I don't understand yet is the purpose of the plugin that gets
> generated out of the genmodel (*.editor). The code shows a
> multipage-editor.
> Related to this are the functionalities I discovered in my
> runtime-Workbench: I now have a EMF Model Creation Wizard that may
> create my own types. The models are created in the workspace. If I
> understand this right, the editing counterpart of this wizard is the
> editor I talk of above. What is the puropose of this wizard and the
> editor (I'm defenitively a EMF Rookie).
Yes, the multi page editor and the model creation wizard are in the
....model.editor plugin that you generated.
You can't use this editor (or the wizard) out of the box with CDO.
So if you don't plan on investigating how to make it work with CDO just
don't generate the editor.
To disable generation of the editor plugin, go to the editor category in
the genmodel properties and set the source directory to the empty string.
>> Currently it is not yet possible togenerate a CDO enabled EMF editor
>> out of the box. It would be a nice exercise to provide the needed JET
>> templates. I must admit that I did not manage, due to time
>> constraints, to learn how to use the new contributeable JET templates
>> (sorry Dave). If you are to start analyze my modifications to the
>> generated editor that led to the CDOEditor, note that I added the
>> JavaDoc tag "@ADDED" to each new editor member. The changed ones
>> carry a "@generated NOT". If you configure the Java compiler to
>> create Java Tasks you'll get a helpful overview in the rulers.
>> Another trick I heard of is the usage of Mint
>> (http://www.eclipse.org/modeling/emft/?project=mint).
>
>
> I had a quick look and things look very interesting there. Another
> very interesting component for editing Ecore-Models is the Ecore
> Diagram Editor RFE.
>
>
> One more thing (I have plenty of them ;-)) I need to know is how to
> access the CDO-Resources by another client. I Have a JBPM-Workflow and
> I'll have to implement nodes that manipulate the CDO-Resources (CDO is
> intended to be an inventory, the CDO enabled client shall be a
> resource manipulation GUI). Reading thorugh the posts in here I found
> out that a possible strategy would be to have CDO on top of
> Teneo-Hibernate. The workflow-nodes could the access the storage on
> behalf of their own hibernate-layer. If I get things right, I could
> also use CDO client code in those. The major issue here would be how
> to operate jBPM in a OSGI enabled environment. Any hints here?
Puuh, I have absolutely no experience with jBPM (and almost none with
other BPM tools) so I can't help you here.
I think the main question here for me was the one about how to access a
CDOResource. To access a CDOResource you always need a CDOView (for
read-only access) or a CDOTransaction (for read-write access). Both can
be obtained from a CDOSession which encapsulates a Net4j IChannel for
data transfers to/from the CDO repository. Btw. this is going to be
changed soon, as we're working on abstracting the CDO core completely
from Net4j (and providing an optional Net4j implementation of that
abstraction along with a direct implementation for local repositories).
Once you have a handle to a CDOTransaction you can use the methods no
matter of how the underlying session manages to connect to the repository:
CDOResource getResource(String path)
CDOResource createResource(String path)
CDOResource getOrCreateResource(String path)
Cheers
/Eike
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
| | | |
| Re: [CDO]: simple usage scenario? [message #419822 is a reply to message #419818] |
Sun, 08 June 2008 04:25 |
|
Hi André,
Comments below...
André Dietisheim schrieb:
> Hi Eike
>
>> You can't use this editor (or the wizard) out of the box with CDO.
>> So if you don't plan on investigating how to make it work with CDO
>> just don't generate the editor.
>
> okay, got that. So this is the editor you talked of in your last post
> and this is started but unfinished work.
Hmm, not even started ;-)
Did I say that?
> What are the benefits of this compared to the CDOEditor?
The CDOEditor is also a generated one (and then modified).
I think the question should not be "what is the difference between the
CDOEditor and a particular generated editor?" but rather "what is the
benefit of generating a dedicated editor for each particular model?".
This question has been addressed in several newsgroup threads already.
Forgive me that I'll only repeat my point in this discussion: I see more
harm than benefit in coupling the UI to the model. Most of the
modifications that are usually applied to the generated editors would
better be kept in the model.edit layer which is, strictly spoken, not
UI. In my opinion it'd be better to modify the UI as a dimension
orthogonal to the model (for example by subclassing an existing editor)
so that all models can automatically benefit from the modifications.
Model specific actions can stilll be contributed via the edit layer.
>> Puuh, I have absolutely no experience with jBPM (and almost none with
>> other BPM tools) so I can't help you here.
> One more thing (I have plenty of them ;-)) I need to know is how to
> access the CDO-Resources by another client. I Have a JBPM-Workflow and
> I'll have to implement nodes that manipulate the CDO-Resources (CDO is
> intended to be an inventory, the CDO enabled client shall be a
> resource manipulation GUI). Reading thorugh the posts in here I found
> out that a possible strategy would be to have CDO on top of
> Teneo-Hibernate. The workflow-nodes could the access the storage on
> behalf of their own hibernate-layer. If I get things right, I could
> also use CDO client code in those. The major issue here would be how
> to operate jBPM in a OSGI enabled environment. Any hints here?
>
> No prob, I didn't expect that ;-) I just tried to explain my current
> context. What I try to solve (in the big picture) is the following:
> I have 2 clients that shall access the same CDO-Server:
> - RCP client
> - jBPM-Node(s)
> The RCP client is mostly delivered out-of-the-box by CDO, so what
> we'll have to implement are jBPM-Nodes that access (CRUD) the
> CDO-Repository.
My problem is that I still have no clue what exactly a jBPM-Node is.
> If I understand things correctly the current CDO client classes are
> implemented as Bundles aka a OSGI-context. JBPM on the other hand is a
> non-OSGI component running in a JBoss (JBoss-OSGI is not ready yet and
> there are currently no JBPM Bundles). I assume I'll have to OSGI-ify
> JBPM so that it may access the CDO-classes. Do you see any other
> strategies?
Ah, thanks to the 0.8 stream redesign of both Net4j and CDO they are now
capable of running standalone (i.e. without OSGi running) as well. In
CVS there is even an example how to setup a standalone CDO server
through a Spring Framework application context. So this should not be of
a problem in combination with any non-OSGi container.
>> Once you have a handle to a CDOTransaction you can use the methods no
>> matter of how the underlying session manages to connect to the
>> repository:
>> CDOResource getResource(String path)
>> CDOResource createResource(String path)
>> CDOResource getOrCreateResource(String path)
>>
> I think the main question here for me was the one about how to access
> a CDOResource. To access a CDOResource you always need a CDOView (for
> read-only access) or a CDOTransaction (for read-write access). Both
> can be obtained from a CDOSession which encapsulates a Net4j IChannel
> for data transfers to/from the CDO repository. Btw. this is going to
> be changed soon, as we're working on abstracting the CDO core
> completely from Net4j (and providing an optional Net4j implementation
> of that abstraction along with a direct implementation for local
> repositories).
>
> great!! That's almost a howto! :-)
>
> Thanks again for the rapid roundtrip of your answers!!
You're welcome! You can see this as a compensation for the awful weather
that you seem to have in Bern, which started right after I left IIRC ;-)
Cheers
/Eike
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: [CDO]: problem with RC3 [message #419823 is a reply to message #419819] |
Sun, 08 June 2008 04:32 |
|
Mark,
This looks like the problem André experienced (see
http://www.eclipse.org/newsportal/article.php?id=32771&g roup=eclipse.tools.emf#32771).
It seems to be caused by a mixture of RC3 and pre-RC3 plugins in your
installation. Is that possible?
I took your suggestion to tackle some APIs before the first proper
release seriously ;-)
The former protocl plugin was renamed into "common" and all internal
packages (everywhere) are now really x-internal.
Maybe you have to install freshly or run -clean?
Cheers
/Eike
Mark Geib schrieb:
> Eike,
>
> Just downloaded cdo RC3 and netj4 RC3a and when I run my app I get the
> error below..
>
> Thanks,
> Mark.
>
> org.eclipse.net4j.util.lifecycle.LifecycleException:
> java.lang.ClassNotFoundException:
> org.eclipse.emf.cdo.internal.protocol.id.CDOIDLongFactoryImp l
> at
> org.eclipse.net4j.util.lifecycle.Lifecycle.activate(Lifecycl e.java:61)
> at
> org.eclipse.emf.internal.cdo.CDOSessionConfigurationImpl.ope nSession(CDOSessionConfigurationImpl.java:134)
> at
> srd.util.EchostarModelManager.createResource(EchostarModelMa nager.java:84)
> at srd.util.EchostarModelManager.load(EchostarModelManager.java :153)
> at
> srd.view.navigator.ServiceNavigator.<init>(ServiceNavigator.java:182)
>
>
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: [CDO]: simple usage scenario? [message #419824 is a reply to message #419822] |
Sun, 08 June 2008 13:21 |
Andre Dietisheim
Messages: 131
Registered: July 2009 |
Senior Member |
|
|
Hi Eike!
> The CDOEditor is also a generated one (and then modified).
>
> I think the question should not be "what is the difference between the
> CDOEditor and a particular generated editor?" but rather "what is the
> benefit of generating a dedicated editor for each particular model?".
> This question has been addressed in several newsgroup threads already.
> Forgive me that I'll only repeat my point in this discussion: I see more
> harm than benefit in coupling the UI to the model. Most of the
> modifications that are usually applied to the generated editors would
> better be kept in the model.edit layer which is, strictly spoken, not
> UI. In my opinion it'd be better to modify the UI as a dimension
> orthogonal to the model (for example by subclassing an existing editor)
> so that all models can automatically benefit from the modifications.
> Model specific actions can stilll be contributed via the edit layer.
your arguments make sense to me! That's the approach I chose in the SBB
project. I never used an approach where I generated the editor so I do
not have a strong opinion on that.
I thought the CDOEditor is a modified generic EMFEditor and is supplied
by cdo.ui. Do I understand things right if I assume that it's not being
generated when I generate the classes on behalf of my genmodel? My
problem here is probably that I have no knowledge what's being
generated and how it's done.
> My problem is that I still have no clue what exactly a jBPM-Node is.
that's probably off topic and does not contribute to the discussion, but
anyhow:
jbpm is a workflow engine created by jboss.
> Ah, thanks to the 0.8 stream redesign of both Net4j and CDO they are now
> capable of running standalone (i.e. without OSGi running) as well. In
> CVS there is even an example how to setup a standalone CDO server
> through a Spring Framework application context. So this should not be of
> a problem in combination with any non-OSGi container.
>
great! I saw that plugin and it looks fairly cool. Do I understand you
right, that the CDO client classes might work outside a OSGI container,
too? So I'd have no troubles running a CDO client in a non-OSGI app?
That would be great news!!
>> Thanks again for the rapid roundtrip of your answers!!
> You're welcome! You can see this as a compensation for the awful weather
> that you seem to have in Bern, which started right after I left IIRC ;-)
;-)) I heard of it from my collegues that are still in Berne! I moved to
the south of France (Antibes) in the beginning of May, but the weather
here only gets better now. Looks like Berlin's quite privileged! Your
compensation is more that welcome, brainfood for a hungry techguy! :-)
Cheers
André
>
> Cheers
> /Eike
|
|
|
| Re: [CDO]: problem with RC3 [message #419825 is a reply to message #419823] |
Sun, 08 June 2008 16:17 |
Mark Geib
Messages: 432
Registered: July 2009 |
Senior Member |
|
|
Eike,
I have a new fresh install of Eclipse 3.4RC3, EMF 2.4RC3, CDO 1.0RC3 and
NET4J 1.0RC3a. I still have the same error at runtime.
I also tried a -clean, no luck.
Unless there is something in the workspace I don't know of anything that
is not RC3 now.
Thanks,
Mark.
On Sun, 2008-06-08 at 06:32 +0200, Eike Stepper wrote:
> Mark,
>
> This looks like the problem André experienced (see
> http://www.eclipse.org/newsportal/article.php?id=32771&g roup=eclipse.tools.emf#32771).
> It seems to be caused by a mixture of RC3 and pre-RC3 plugins in your
> installation. Is that possible?
>
> I took your suggestion to tackle some APIs before the first proper
> release seriously ;-)
> The former protocl plugin was renamed into "common" and all internal
> packages (everywhere) are now really x-internal.
>
> Maybe you have to install freshly or run -clean?
>
> Cheers
> /Eike
>
>
>
>
> Mark Geib schrieb:
> > Eike,
> >
> > Just downloaded cdo RC3 and netj4 RC3a and when I run my app I get the
> > error below..
> >
> > Thanks,
> > Mark.
> >
> > org.eclipse.net4j.util.lifecycle.LifecycleException:
> > java.lang.ClassNotFoundException:
> > org.eclipse.emf.cdo.internal.protocol.id.CDOIDLongFactoryImp l
> > at
> > org.eclipse.net4j.util.lifecycle.Lifecycle.activate(Lifecycl e.java:61)
> > at
> > org.eclipse.emf.internal.cdo.CDOSessionConfigurationImpl.ope nSession(CDOSessionConfigurationImpl.java:134)
> > at
> > srd.util.EchostarModelManager.createResource(EchostarModelMa nager.java:84)
> > at srd.util.EchostarModelManager.load(EchostarModelManager.java :153)
> > at
> > srd.view.navigator.ServiceNavigator.<init>(ServiceNavigator.java:182)
> >
> >
|
|
|
| Re: [CDO]: problem with RC3 [message #419826 is a reply to message #419825] |
Sun, 08 June 2008 17:20 |
|
Mark Geib schrieb:
> Eike,
>
> I have a new fresh install of Eclipse 3.4RC3, EMF 2.4RC3, CDO 1.0RC3 and
> NET4J 1.0RC3a. I still have the same error at runtime.
>
> I also tried a -clean, no luck.
>
> Unless there is something in the workspace I don't know of anything that
> is not RC3 now.
>
That's weird, the class is now
org.eclipse.emf.cdo.spi.common.CDOIDLongFactoryImpl
I think you must have some compiled code that still refers to the old
location.
I run out of ideas, can you paste the full stack trace please?
Cheers
/Eike
> Thanks,
> Mark.
>
>
> On Sun, 2008-06-08 at 06:32 +0200, Eike Stepper wrote:
>
>> Mark,
>>
>> This looks like the problem André experienced (see
>> http://www.eclipse.org/newsportal/article.php?id=32771&g roup=eclipse.tools.emf#32771).
>> It seems to be caused by a mixture of RC3 and pre-RC3 plugins in your
>> installation. Is that possible?
>>
>> I took your suggestion to tackle some APIs before the first proper
>> release seriously ;-)
>> The former protocl plugin was renamed into "common" and all internal
>> packages (everywhere) are now really x-internal.
>>
>> Maybe you have to install freshly or run -clean?
>>
>> Cheers
>> /Eike
>>
>>
>>
>>
>> Mark Geib schrieb:
>>
>>> Eike,
>>>
>>> Just downloaded cdo RC3 and netj4 RC3a and when I run my app I get the
>>> error below..
>>>
>>> Thanks,
>>> Mark.
>>>
>>> org.eclipse.net4j.util.lifecycle.LifecycleException:
>>> java.lang.ClassNotFoundException:
>>> org.eclipse.emf.cdo.internal.protocol.id.CDOIDLongFactoryImp l
>>> at
>>> org.eclipse.net4j.util.lifecycle.Lifecycle.activate(Lifecycl e.java:61)
>>> at
>>> org.eclipse.emf.internal.cdo.CDOSessionConfigurationImpl.ope nSession(CDOSessionConfigurationImpl.java:134)
>>> at
>>> srd.util.EchostarModelManager.createResource(EchostarModelMa nager.java:84)
>>> at srd.util.EchostarModelManager.load(EchostarModelManager.java :153)
>>> at
>>> srd.view.navigator.ServiceNavigator.<init>(ServiceNavigator.java:182)
>>>
>>>
>>>
>
>
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: [CDO]: simple usage scenario? [message #419827 is a reply to message #419824] |
Sun, 08 June 2008 17:30 |
|
Hi André,
Comments below...
André Dietisheim schrieb:
> Hi Eike!
>
>> The CDOEditor is also a generated one (and then modified).
>>
>> I think the question should not be "what is the difference between
>> the CDOEditor and a particular generated editor?" but rather "what is
>> the benefit of generating a dedicated editor for each particular
>> model?". This question has been addressed in several newsgroup
>> threads already. Forgive me that I'll only repeat my point in this
>> discussion: I see more harm than benefit in coupling the UI to the
>> model. Most of the modifications that are usually applied to the
>> generated editors would better be kept in the model.edit layer which
>> is, strictly spoken, not UI. In my opinion it'd be better to modify
>> the UI as a dimension orthogonal to the model (for example by
>> subclassing an existing editor) so that all models can automatically
>> benefit from the modifications. Model specific actions can stilll be
>> contributed via the edit layer.
>
> your arguments make sense to me! That's the approach I chose in the
> SBB project. I never used an approach where I generated the editor so
> I do not have a strong opinion on that.
> I thought the CDOEditor is a modified generic EMFEditor and is
> supplied by cdo.ui. Do I understand things right if I assume that it's
> not being generated when I generate the classes on behalf of my
> genmodel? My problem here is probably that I have no knowledge what's
> being generated and how it's done.
Hm, I think "generic EMFEditor" is not the correct term. Both the
CDOEditor and the EMF editor that we mean are generic. But the EMF
editor is also *reflective*:
protected void initializeEditingDomain()
{
adapterFactory = new
ComposedAdapterFactory(ComposedAdapterFactory.Descriptor.Reg istry.INSTANCE);
adapterFactory.addAdapterFactory(new
ReflectiveItemProviderAdapterFactory());
}
The CDOEditor is generic but nor reflective:
protected void initializeEditingDomain()
{
Registry registry =
EMFEditPlugin.getComposedAdapterFactoryDescriptorRegistry();
adapterFactory = new ComposedAdapterFactory(registry);
}
And yes, the CDOEditor is not being generated when you generate your
models. It's simply part of the CDO distribution and is regenerated by
me from time to time out of a dummy model.
> [...]
>> Ah, thanks to the 0.8 stream redesign of both Net4j and CDO they are
>> now capable of running standalone (i.e. without OSGi running) as
>> well. In CVS there is even an example how to setup a standalone CDO
>> server through a Spring Framework application context. So this should
>> not be of a problem in combination with any non-OSGi container.
>>
>
> great! I saw that plugin and it looks fairly cool. Do I understand you
> right, that the CDO client classes might work outside a OSGI
> container, too? So I'd have no troubles running a CDO client in a
> non-OSGI app? That would be great news!!
Exactly. Only the UI plugins need Eclipse UI running underneath.
>
>>> Thanks again for the rapid roundtrip of your answers!!
>> You're welcome! You can see this as a compensation for the awful
>> weather that you seem to have in Bern, which started right after I
>> left IIRC ;-)
>
> ;-)) I heard of it from my collegues that are still in Berne! I moved
> to the south of France (Antibes) in the beginning of May, but the
> weather here only gets better now. Looks like Berlin's quite
> privileged! Your compensation is more that welcome, brainfood for a
> hungry techguy! :-)
Hehe ;-)
Enjoy the rest of your Sunday!
/Eike
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: [CDO]: problem with RC3 [message #419830 is a reply to message #419826] |
Sun, 08 June 2008 21:57 |
Mark Geib
Messages: 432
Registered: July 2009 |
Senior Member |
|
|
Eike,
I have it working again. I finally created a new workspace and that
seems to have resolved the issue. I have to admit that workspaces are
still a bit of mystery to me...
Thanks,
Mark.
Eike Stepper wrote:
> Mark Geib schrieb:
>> Eike,
>>
>> I have a new fresh install of Eclipse 3.4RC3, EMF 2.4RC3, CDO 1.0RC3 and
>> NET4J 1.0RC3a. I still have the same error at runtime.
>>
>> I also tried a -clean, no luck.
>>
>> Unless there is something in the workspace I don't know of anything that
>> is not RC3 now.
>>
> That's weird, the class is now
> org.eclipse.emf.cdo.spi.common.CDOIDLongFactoryImpl
> I think you must have some compiled code that still refers to the old
> location.
> I run out of ideas, can you paste the full stack trace please?
>
> Cheers
> /Eike
>
>
>
>> Thanks,
>> Mark.
>>
>>
>> On Sun, 2008-06-08 at 06:32 +0200, Eike Stepper wrote:
>>
>>> Mark,
>>>
>>> This looks like the problem André experienced (see
>>> http://www.eclipse.org/newsportal/article.php?id=32771&g roup=eclipse.tools.emf#32771).
>>>
>>> It seems to be caused by a mixture of RC3 and pre-RC3 plugins in your
>>> installation. Is that possible?
>>>
>>> I took your suggestion to tackle some APIs before the first proper
>>> release seriously ;-)
>>> The former protocl plugin was renamed into "common" and all internal
>>> packages (everywhere) are now really x-internal.
>>>
>>> Maybe you have to install freshly or run -clean?
>>>
>>> Cheers
>>> /Eike
>>>
>>>
>>>
>>>
>>> Mark Geib schrieb:
>>>
>>>> Eike,
>>>>
>>>> Just downloaded cdo RC3 and netj4 RC3a and when I run my app I get the
>>>> error below..
>>>>
>>>> Thanks,
>>>> Mark.
>>>>
>>>> org.eclipse.net4j.util.lifecycle.LifecycleException:
>>>> java.lang.ClassNotFoundException:
>>>> org.eclipse.emf.cdo.internal.protocol.id.CDOIDLongFactoryImp l
>>>> at
>>>> org.eclipse.net4j.util.lifecycle.Lifecycle.activate(Lifecycl e.java:61)
>>>> at
>>>> org.eclipse.emf.internal.cdo.CDOSessionConfigurationImpl.ope nSession(CDOSessionConfigurationImpl.java:134)
>>>>
>>>> at
>>>> srd.util.EchostarModelManager.createResource(EchostarModelMa nager.java:84)
>>>>
>>>> at
>>>> srd.util.EchostarModelManager.load(EchostarModelManager.java :153)
>>>> at
>>>> srd.view.navigator.ServiceNavigator.<init>(ServiceNavigator.java:182)
>>>>
>>>>
>>
>>
|
|
| |
| Re: [CDO]: simple usage scenario? [message #419832 is a reply to message #419827] |
Sun, 08 June 2008 22:36 |
Andre Dietisheim
Messages: 131
Registered: July 2009 |
Senior Member |
|
|
Hi Eike,
comments inlined:
> Hm, I think "generic EMFEditor" is not the correct term. Both the
> CDOEditor and the EMF editor that we mean are generic. But the EMF
> editor is also *reflective*:
>
> protected void initializeEditingDomain()
> {
> adapterFactory = new
> ComposedAdapterFactory(ComposedAdapterFactory.Descriptor.Reg istry.INSTANCE);
>
> adapterFactory.addAdapterFactory(new
> ReflectiveItemProviderAdapterFactory());
> }
>
> The CDOEditor is generic but nor reflective:
>
> protected void initializeEditingDomain()
> {
> Registry registry =
> EMFEditPlugin.getComposedAdapterFactoryDescriptorRegistry();
> adapterFactory = new ComposedAdapterFactory(registry);
> }
>
> And yes, the CDOEditor is not being generated when you generate your
> models. It's simply part of the CDO distribution and is regenerated by
> me from time to time out of a dummy model.
great! Now I understand it. So the best solution to provide a more
comfortable editing experience (considering your args against generating
domain-specific editors) is to extend (or fork) the CDOEditor. Thanks
for your extensive explanations!
>> great! I saw that plugin and it looks fairly cool. Do I understand you
>> right, that the CDO client classes might work outside a OSGI
>> container, too? So I'd have no troubles running a CDO client in a
>> non-OSGI app? That would be great news!!
> Exactly. Only the UI plugins need Eclipse UI running underneath.
great! This issue's solved, too.
Okiedokie, I'm still in a early stage of our project and we try to
provide a proof of concept. I now have answers to all issues that popped
to my mind and I'll now evaluate a concurrent solution (Sculptor, a
minimalistic MDA-Framework by the CSC guys). We'll decide afterwards
what framework fist the projects needs. I personally hope CDO's the
right choice, because that would open doors to a long-term contribution.
Nevertheless I think I could contribute a Installation (or a Server
configuration Howto).
Best regards to Berlin and all the Eclipse enthusiast around you :-))
Hear ya, Cheers
André
|
|
|
| Re: [CDO]: simple usage scenario? [message #419833 is a reply to message #419832] |
Sun, 08 June 2008 23:10 |
|
Hi André,
Comments below...
André Dietisheim schrieb:
> Hi Eike,
>
> comments inlined:
>
>> Hm, I think "generic EMFEditor" is not the correct term. Both the
>> CDOEditor and the EMF editor that we mean are generic. But the EMF
>> editor is also *reflective*:
>>
>> protected void initializeEditingDomain()
>> {
>> adapterFactory = new
>> ComposedAdapterFactory(ComposedAdapterFactory.Descriptor.Reg istry.INSTANCE);
>>
>> adapterFactory.addAdapterFactory(new
>> ReflectiveItemProviderAdapterFactory());
>> }
>>
>> The CDOEditor is generic but nor reflective:
>>
>> protected void initializeEditingDomain()
>> {
>> Registry registry =
>> EMFEditPlugin.getComposedAdapterFactoryDescriptorRegistry();
>> adapterFactory = new ComposedAdapterFactory(registry);
>> }
>>
>> And yes, the CDOEditor is not being generated when you generate your
>> models. It's simply part of the CDO distribution and is regenerated
>> by me from time to time out of a dummy model.
>
> great! Now I understand it. So the best solution to provide a more
> comfortable editing experience (considering your args against
> generating domain-specific editors) is to extend (or fork) the
> CDOEditor. Thanks for your extensive explanations!
Or just copy it and make your own (monkey see monkey do). If you copy
the dummy model as well you could keep up with the EMF framework changes.
>
>>> great! I saw that plugin and it looks fairly cool. Do I understand
>>> you right, that the CDO client classes might work outside a OSGI
>>> container, too? So I'd have no troubles running a CDO client in a
>>> non-OSGI app? That would be great news!!
>> Exactly. Only the UI plugins need Eclipse UI running underneath.
>
> great! This issue's solved, too.
>
> Okiedokie, I'm still in a early stage of our project and we try to
> provide a proof of concept. I now have answers to all issues that
> popped to my mind and I'll now evaluate a concurrent solution
> (Sculptor, a minimalistic MDA-Framework by the CSC guys). We'll decide
> afterwards what framework fist the projects needs. I personally hope
> CDO's the right choice, because that would open doors to a long-term
> contribution. Nevertheless I think I could contribute a Installation
> (or a Server configuration Howto).
Cool idea ;-)
Cheers
/Eike
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
Goto Forum:
Current Time: Mon May 06 01:42:14 GMT 2024
Powered by FUDForum. Page generated in 0.04408 seconds |
] 
Search
Help
Register
Login
Home
