| GMF support for / Eclipse APIs for model versioning [message #15981] |
Fri, 11 August 2006 12:55  |
Eclipse User |
|
|
|
Originally posted by: michael.schifferdecker.gmail.com
Hi,
This post is about a more general question regarding model versioning
support in GMF editors / related basic Eclipse technologies that might
underpin such a feature "somewhen" / theoretically in the GMF runtime.
I would appreciate your input on my questions below very much.
Cheers and thanks in advance,
Michael
------------------------------
In my diploma thesis project I am currently evaluating means / tools
to enhance & migrate an existing model-driven software development
tool chain. I using the "openArchitectureWare" framework (part of the
GMT / Eclipste Modeling Project) which leverages EMF technologies and
can be combined with GMF editors as modeling front-end. My current
recommendation for the tooling support in the modeling frontend is to
use MagicDraw UML 11.5 though. This decision is partly driven by the
ability of UML tools to support concurrent multi-user editing of
models / versioning support for UML modeling (e.g. MagicDraw offers a
"Team Server" support to "coordinate" concurrent updates made by users
on different client working on the same model).
Widening my scope for model versioning support in general & not only
for UML-based modeling I would like to throw in a question in the
direction of Eclipse / GMF / EMF-based models & respective model
versioning support here....
As of my current understanding of the model versioning matter, there
is no such versioning support available for EMF (be it Ecore or EMF
UML2 models) in general or in a (future) GMF editor / the GMF runtime.
Therefore if I am not able to come to very small / "atomic" EMF model
files (which are XMI files of course in the end) I will always run
into versioning problems when "offering" EMF-based modeling to a
"bigger" team of software developers which leverage from MDSD.
In my thesis I pointed this out as one of the current "practical
lackings" for real-world use of GMF editors in a scaled MDSD
environment since there is only a "purely XMI file based repository"
for EMF available at the moment (always resulting in one BIG XMI file
in which you cannot lock atomic model elements for editing etc.).
So even if there was the perfect GMF editor for the UML2 metamodel and
the "dream" of a UML- + 100% Eclipse IDE-based MDSD environment had
come true, there still might be no mutli-user model versioning support
available.
Therefore some general questions regarding "real-life" model versioning
support:
QUESTIONS:
1) Can somebody tell which Eclipse APIs could underpin / drive a
versioning support for EMF models in the near future / could be
leveraged from in GMF editors somewhen? (I have come across the EMF
Transaction API (part of EMFT project) -- but I was not able to grasp
its real long-term intent at the first look at it).
2) Is model versioning support "on the radar" for future GMF feature
development?
3) Which means do you use in your "real-world projects" to support
model versioning support?
4) How do you slice down a big EMF model into more atomic pieces /
files and still represent / "join" these submodels transparenty into a
big comprehensive model for the modeling user (e.g. something like
many small model subfiles that are joined together "on the fly"
transparently so that this "still file-based approach" might become
okay to be handled with "traditional" CVS (file-based) versioning
approaches?
[this is how Borland Together and older Rational Rose UML tools work
in the background: --> Borland Together 6 "interprets" Java class
skeletons which are annotated with the necessary info for "full" UML
representation (e.g. "@stereotype" etc. --> some Rational Rose
versions allow you to use an "include" statement with which you can
wire together many small model diagram files into one big
comprehensive model,... so in both cases used edit actions only affect
a very small file which is managed by CVS in a very traditional /
classic versioning kind of way]] ==> by using such an approach even
bigger EMF models might be usable in a multi-users environment using
"classic" CVS versioning.
Thank you in advance for your inputs!
|
|
|
| Re: GMF support for / Eclipse APIs for model versioning [message #16870 is a reply to message #15981] |
Sun, 13 August 2006 11:26  |
| Eclipse User |
|
|
|
Originally posted by: merks.ca.ibm.com
Michael,
My comments, from an EMF perspective are below.
Michael Schifferdecker wrote:
> Hi,
>
> This post is about a more general question regarding model versioning
> support in GMF editors / related basic Eclipse technologies that might
> underpin such a feature "somewhen" / theoretically in the GMF runtime.
>
> I would appreciate your input on my questions below very much.
>
> Cheers and thanks in advance,
>
> Michael
>
> ------------------------------
>
> In my diploma thesis project I am currently evaluating means / tools
> to enhance & migrate an existing model-driven software development
> tool chain. I using the "openArchitectureWare" framework (part of the
> GMT / Eclipste Modeling Project) which leverages EMF technologies and
> can be combined with GMF editors as modeling front-end. My current
> recommendation for the tooling support in the modeling frontend is to
> use MagicDraw UML 11.5 though. This decision is partly driven by the
> ability of UML tools to support concurrent multi-user editing of
> models / versioning support for UML modeling (e.g. MagicDraw offers a
> "Team Server" support to "coordinate" concurrent updates made by users
> on different client working on the same model).
>
> Widening my scope for model versioning support in general & not only
> for UML-based modeling I would like to throw in a question in the
> direction of Eclipse / GMF / EMF-based models & respective model
> versioning support here....
>
> As of my current understanding of the model versioning matter, there
> is no such versioning support available for EMF (be it Ecore or EMF
> UML2 models) in general or in a (future) GMF editor / the GMF runtime.
Yes, EMF provides nothing directly in the way of versioning support. It
simply provides access to resources via URIs. The contents accessed by
those URIs can be in a versioned backing store and the URIs can encode
versioned access.
>
> Therefore if I am not able to come to very small / "atomic" EMF model
> files (which are XMI files of course in the end) I will always run
> into versioning problems when "offering" EMF-based modeling to a
> "bigger" team of software developers which leverage from MDSD.
Yes, the design and management of your units of versioning are an
important consideration as the model is defined.
>
> In my thesis I pointed this out as one of the current "practical
> lackings" for real-world use of GMF editors in a scaled MDSD
> environment since there is only a "purely XMI file based repository"
> for EMF available at the moment (always resulting in one BIG XMI file
> in which you cannot lock atomic model elements for editing etc.).
XMI is just one possible serialization backing mechanism. Models are
self describing and that description is used to produce an XMI
serialization in EMF. It could just as well be used to produce any
serialization, e.g., one that is far more compact and efficient to
read. The EMFT projects Teneo and CDO demonstrate other persistence
techniques in action.
>
> So even if there was the perfect GMF editor for the UML2 metamodel and
> the "dream" of a UML- + 100% Eclipse IDE-based MDSD environment had
> come true, there still might be no mutli-user model versioning support
> available.
Large multi-user Java systems are versioned using files backed by CVS.
I think a reasonable level of team support can be provided by taking
advantage of cross resource containment to create smaller units of
control. For example, each EClassifier of an EPackage can be stored in
a separate file and individual classes seems like a reasonably small unit...
>
> Therefore some general questions regarding "real-life" model
> versioning support:
>
> QUESTIONS:
>
> 1) Can somebody tell which Eclipse APIs could underpin / drive a
> versioning support for EMF models in the near future / could be
> leveraged from in GMF editors somewhen? (I have come across the EMF
> Transaction API (part of EMFT project) -- but I was not able to grasp
> its real long-term intent at the first look at it).
As far as I know, no one is planning to contribute any type of versioned
repository support, if that's what you are envisioning. The Teneo and
CDO projects are looking to provided database persistence, so perhaps
that addressed the issue from a different angle...
>
> 2) Is model versioning support "on the radar" for future GMF feature
> development?
That's for GMF to answer, but it would seem their needs would not be so
different from most anyone's needs...
>
> 3) Which means do you use in your "real-world projects" to support
> model versioning support?
For our own work, models are managed as files and those files are
versioned using file-based versioning systems.
>
> 4) How do you slice down a big EMF model into more atomic pieces /
> files and still represent / "join" these submodels transparenty into a
> big comprehensive model for the modeling user (e.g. something like
> many small model subfiles that are joined together "on the fly"
> transparently so that this "still file-based approach" might become
> okay to be handled with "traditional" CVS (file-based) versioning
> approaches?
Proxy resolving containment references can cross resource boundaries, so
supporting this is just a matter of enabling it for the references in
the model (along with the setting the GenModel's Containment Proxies
property to true to respect these settings, since it's new to 2.2 to
support cross resource containment). It works transparently just like
non-containment cross references always have.
> [this is how Borland Together and older Rational Rose UML tools work
> in the background: --> Borland Together 6 "interprets" Java class
> skeletons which are annotated with the necessary info for "full" UML
> representation (e.g. "@stereotype" etc. --> some Rational Rose
> versions allow you to use an "include" statement with which you can
> wire together many small model diagram files into one big
> comprehensive model,... so in both cases used edit actions only affect
> a very small file which is managed by CVS in a very traditional /
> classic versioning kind of way]] ==> by using such an approach even
> bigger EMF models might be usable in a multi-users environment using
> "classic" CVS versioning.
>
> Thank you in advance for your inputs!
|
|
|
Powered by
FUDForum. Page generated in 0.03388 seconds
Home