Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [gmf-dev] GMF support for / Eclipse APIs for model versioning 
Hi Richard,

thanks for your reply.

I just posted my message to the eclipse.modeling.gmf newsgroup.

Cheers,

Michael

On 8/11/06, Richard Gronback <richard.gronback@xxxxxxxxxxx> wrote:

Hi Michael,

These are good questions that would be best asked/answered on the GMF and/or
EMF newsgroup(s): eclipse.modeling.gmf and eclipse.tools.emf

A broader audience will benefit from the discussion there.

Thanks,
Rich


On 8/11/06 12:22 PM, "Michael Schifferdecker"
<michael.schifferdecker@xxxxxxxxx> wrote:

> 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!
> _______________________________________________
> gmf-dev mailing list
> gmf-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/gmf-dev

--
Richard C. Gronback
Borland Software Corporation
richard.gronback@xxxxxxxxxxx
+1 860 227 9215

_______________________________________________
gmf-dev mailing list
gmf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/gmf-dev




--
------------------------------------------------
Michael Schifferdecker
Speyerer Strasse 43
68199 Mannheim
Germany

+49 1212 384934305 (fest, SIP)
+49 621 4269588 (fest, Mannheim)
+49 176 24906284 (mobil, D)
+44 785 4874023 (mobil, UK)

michael.schifferdecker@xxxxxxxxx
skype user id: mschiffe
ICQ id: 89356522

Back to the top