| [CDO] Cohabitation of both standard EMF and CDO-Native implementations [message #893320] |
Tue, 03 July 2012 14:24  |
|
Hi everyone,
I'm facing an architectural issue with CDO. Here's my need: I've got a
plugin A that provides a set of Packages implementation through the
org.eclipse.emf.ecore.generated_package extension point.
What I would like to do is to define a plugin A_native that requires A,
containing :
- the CDO-Native version of the genmodel contained in A
- the CDO-Native generated code
The idea is that when A_native is active, it overrides the A
implementation and provide a CDO-Native version of my meta-model.
The trick is that to be fully compatible, the code generation in
A_native should only generate Implementation classes, and not the
Interfaces. After an "organize import", the referenced interface will be
found in A and my CDO-Native code will be compatible with A.
I did not manage to do that through genmodel properties, and after
having studied the "test.model6" plugin of cdo tests that seemed to do
what I wanted, I realized that the Interfaces of the legacy code had to
be deleted manually.
Is there any kind of tool (like a custom "generate Model" action) in CDO
that could do that for me? Otherwise I do not see any other solution
than providing my own Action, that will :
- reload the cdo-native genmodel from the A genmodel
- launch the code generation
- delete the Interfaces
- organize imports
Any idea ?
Cheers,
Alex
|
|
|
| Re: [CDO] Cohabitation of both standard EMF and CDO-Native implementations [message #893333 is a reply to message #893320] |
Tue, 03 July 2012 15:01  |
|
Hi Alex,
Unfortunately we're still doing this manually because we don't have such a tool, yet. If you contribute one, we'd be
happy to maintain it ;-)
Please note that our tests models (all of them, AFAIK) are designed "upside down", compared to your proposal. The normal
X.genmodel is used to generate the CDO native code and an additional X.legacy-genmodel generates the legacy code in
subpackages.
You may also want to have a look at
http://wiki.eclipse.org/CDO_Development_Guidelines#How_to_regenerate_the_test_models_for_legacy
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
Am 03.07.2012 16:24, schrieb Alex Lagarde:
> Hi everyone,
>
> I'm facing an architectural issue with CDO. Here's my need: I've got a plugin A that provides a set of Packages
> implementation through the org.eclipse.emf.ecore.generated_package extension point.
>
> What I would like to do is to define a plugin A_native that requires A, containing :
> - the CDO-Native version of the genmodel contained in A
> - the CDO-Native generated code
>
> The idea is that when A_native is active, it overrides the A implementation and provide a CDO-Native version of my
> meta-model.
>
> The trick is that to be fully compatible, the code generation in A_native should only generate Implementation classes,
> and not the Interfaces. After an "organize import", the referenced interface will be found in A and my CDO-Native code
> will be compatible with A.
>
> I did not manage to do that through genmodel properties, and after having studied the "test.model6" plugin of cdo
> tests that seemed to do what I wanted, I realized that the Interfaces of the legacy code had to be deleted manually.
>
> Is there any kind of tool (like a custom "generate Model" action) in CDO that could do that for me? Otherwise I do not
> see any other solution than providing my own Action, that will :
> - reload the cdo-native genmodel from the A genmodel
> - launch the code generation
> - delete the Interfaces
> - organize imports
>
> Any idea ?
> Cheers,
> Alex
>
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: [CDO] Cohabitation of both standard EMF and CDO-Native implementations [message #893339 is a reply to message #893333] |
Tue, 03 July 2012 15:23 |
|
Hi Eike,
thanks for your fast answer, as usual!
Yes I noticed that the test models were doing my use case backward.
I'll try to write a generic action for that purpose. It may take the
following forms :
a) an action "generate without interfaces", which has nothing to do in
cdo according to me
b) an action "update cdo-native code", that will be available on any
"Stantard EMF" genmodel that has a variable "cdo-native-genmodel=<PATH
FROM STANTARD TO NATIVE GENMODEL>".
As I said in the previous post, this action will :
- reload the cdo-native genmodel from EMF Standard gen model (if we
choose to plug the action as explained in b)
- launch the code generation
- delete the Interfaces
- organize imports
Best Regards,
Alex
|
|
|
|
Powered by
FUDForum. Page generated in 0.02010 seconds
Search
Help
Register
Login
Home
