Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » History of EMF
History of EMF [message #1818307] Thu, 12 December 2019 08:44 Go to next message
Clever Alves is currently offline Clever AlvesFriend
Messages: 70
Registered: August 2019
Member
Hello, everyone!

I'd like to know a little bit about the timeline of EMF, particularly regarding Ecore, Sirius, EMF UI forms and Episilon.

I've found out a very interesting URL https://www.eclipse.org/ecoretools/overview.html, however, it stops mentioning years at 2009 and I'd really like to know in a roughly year-by-year basis how the EMF tools development has been taking place. Could someone help me out with it, please?

Thank you for your attention.

Regards,

Clever.
Re: History of EMF [message #1818319 is a reply to message #1818307] Thu, 12 December 2019 13:28 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 31048
Registered: July 2009
Senior Member
It's a rather unspecific question that would require detective work from multiple teams and the purpose of having such answers isn't clear. Certainly you can look at the Git history of any repository via the web views of each repository:

https://git.eclipse.org/c/
Re: History of EMF [message #1818426 is a reply to message #1818319] Mon, 16 December 2019 01:07 Go to previous messageGo to next message
Clever Alves is currently offline Clever AlvesFriend
Messages: 70
Registered: August 2019
Member
Thank you for your reply, Ed!

I'd just like to understand the motivation for building DSL from scratch (e.g. https://specifications.openehr.org/releases/LANG/latest/bmm.html) rather than using EMF, a timeline could perhaps help prove the conjecture it happened in the past decade just because EMF wasn't well-developed at the time such DSLs were kicked-off.

Regards,

Clever.
Re: History of EMF [message #1818427 is a reply to message #1818426] Mon, 16 December 2019 07:10 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 31048
Registered: July 2009
Senior Member
The common general reason people do things from scratch is that they believe that their hand written code will be simpler, easier to understand, and more efficient than using some other framework. It's just human nature to believe this. Using a framework will require learning that framework and initially one will question why that framework seems so much more complex than is completely necessary. Of course over time, the hand written code will need to solve all the same problems and all the same complexity will be reinvented. But, it will well understood by the author, because the author wrote it. But to everyone else, it will be yet another complex framework.

The referenced document it states:
Quote:
This document describes the Basic Meta-Model (BMM), a model of object models. It may be considered as an approximate replacement for the UML XMI. It is human-readable and writable, and supports generic types (open and closed), container types, and multiple inheritance.

Clearly these folks know of UML, and describe in detail its shortcomings and complexities, so they decided to create something just like it, but simpler and better. But there are certainly no technical reasons (e.g., immaturity of the frameworks at Eclipse) why they wouldn't do this using EMF and other downstream frameworks. After all, UML's defacto standard implementation is the Eclipse UML2 implementation, based on EMF and described with Ecore. Moreover, these frameworks are what IBM uses to build its commercial tools as far back so 2000. It brings back memories of IBM where they "pushed" their customers to use profiled UML as the way to design a DSL, rather than to use EMF to design a lightweight DSL. Not only that, the technical leaders were of the opinion that a model is "just a model" not a language. Why? Because a model has no concrete syntax, arguing that an XML serialization is not a concrete syntax. The underlying reason (in my opinion) was that UML sold tools while EMF was free and although EMF is used to build said commercial tools, EMF had its own free tools that anyone could use for free.

I expect that there were purely political reasons for the BMM design/implementation approach, but you should ask them for the reasons. It will definitely not be technically justified by the immaturity or lack of functionality in the available Eclipse frameworks at the time those decisions were made.
Re: History of EMF [message #1818436 is a reply to message #1818427] Mon, 16 December 2019 09:18 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 6627
Registered: July 2009
Senior Member
Hi

Yet another reason for a 'new' framework is that the 'old' one doesn't work for real users and that a 'new' framework will be the Utopian solution.

A recent discussion on [1] referenced the excellent [2].

While there was surprising consensus among UML experts that UML 2 has got it badly wrong by fully supporting both analysis and synthesis requirements, there was no real consensus as to what would be better. Just depression that software technology seems to be moving away from models. Some correspondents pin their hopes on SysML 2 being the new Utopia.

Sadly at Eclipse too, modeling is failing; there is a catastrophic lack of industrial support with far too many projects hanging on by the skin of their teeth dependent on the enthusiasm of single individuals. Certainly no sign of any consistent commitment or investment to fill the functionality chasms between different projects that inhibit use of Eclipse as a diverse integrated modeling platform.

Regards

Ed Willink

[1] uml2-rtf@omg.org
[2] https://wolandscat.net/2019/03/07/the-long-slow-death-of-uml/
Re: History of EMF [message #1818437 is a reply to message #1818436] Mon, 16 December 2019 10:06 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 31048
Registered: July 2009
Senior Member
Ed,

As usual, UML remains the focus as well as the point of comparison. But Ecore actually provides the pragmatic solutions, has a huge stack of frameworks to do everything one might imagine doing with models, can be used to build UML, SysML, and anything else (DSL) imaginable, and, along with Eclipse's many non-modeling frameworks, can be leveraged to build rich tools around these things. The lack of clear vision (model snow-blindness) is the unfortunate domain of big organizations with grandiose visions working with other big organizations with alternative grandiose visions. Meanwhile the anti-modeling bigots long with the Luddites are sure they can do everything better by hand. Alas, such is how the really world works.

I would not characterize the dysfunctional funding model for modeling technologies as a failure of modeling but rather a reflection of the simple fact that Eclipse modeling is a victim of its own success. Why invest in technologies that are perceived to be stable, robust, and mostly complete? Investment goes into new cool things because executives (who hold the purse) are like children: they are enamored by new toys and the old toys are pushed to the side. Even developers generally much prefer to develop new cool things rather than support old things. So the investment and interest is focused on all the cool things you can do with the wide variety of frameworks that already exist with the underlying (baseless) assumption that the free goodness will always just keep flowing forever because someone else will do that. That part is definitely dysfunctional and could ultimately lead to failure of the whole...
Re: History of EMF [message #1818444 is a reply to message #1818437] Mon, 16 December 2019 11:51 Go to previous message
Ed Willink is currently offline Ed WillinkFriend
Messages: 6627
Registered: July 2009
Senior Member
Hi Ed

Indeed. If UML had separated its distinct analysis and synthesis/implementation requirements, the synthesis/implementation sub-UML might be remarkably similar to Ecore. It even had a name (EMOF) but was discarded as UML 2 bloated out.

Determined UML users are forced to struggle with the bloat and while Eclipse's UML2Ecore rescues something useful from a UML model, it is had to answer the question why bother with conversion from a perverse UML abstraction when Ecore does the job much more directly and is consequently so much better?

Perhaps the answer comes from diagrams that on a good day can be very helpful and where this thread started.

Ecore had no diagrams for ages, and just as the old Ecore Tools got useful, it died. I find the new Sirius based Ecore Tools very unsatisfactory because it has a Sirius world *.aird lock-in that fights the standard edit-a-file Eclipse ergonomics. It seems you share this view since the Ecore diagram files have never been updated from the old Ecore Tools.

When editing Ecore files, I probably use the Ecore Tree editor 90% of the time, the OCLinEcore text rendering 6% of the time, an XML text editor 3% of the time and Ecore Tools 1%. I only use UML in so far as I need test cases for UML tooling support.

Ecore is great, but the tools around it don't provide an integrated UI. Ecore Tools is painful to use. Ecore supports reflective XML editing, but no tool supported reflective diagram drawing until I developed one to draw diagrams for a conference paper. (It's part of QVTd and on offer to Sirius where it belongs.)

When Ecore's implementation utility is stretched to a no-Java model specification role, sadly some cracks start to appear in particular in regard to inconsistent treatment of dynamic model inheritance of EObject.

If we had time/commitment to address the above comparatively minor issues we could Make Eclipse Great Again.

Regards

Ed

Previous Topic:[CDO] Schema Locked Exception after update to CDO 4.4
Next Topic:Adding feature to dynamic instance model
Goto Forum:
  


Current Time: Fri Apr 10 06:04:31 GMT 2020

Powered by FUDForum. Page generated in 0.05063 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top