Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[gmf-dev] GMF support for / Eclipse APIs for model versioning

Hi,

I hope this is the right "arena" to throw in my question :-)

This email 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 appreaciate 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.

Thanks for your inputs!


Back to the top