| Re: [modeling-pmc] Clarification regarding the remark from Miles w.r.t. GMF Tooling / Runtime, Re: modeling-pmc Digest, Vol 75, Issue 12 |
Philipp, Thanks for that correction. While I've seen and expressed both positive and negative things about GMF over the years, I've tried to do that in the most constructive way I can. I do understand that a great amount of work is anticipated for the GMF Tooling, and I think that will be extremely valuable and is much needed -- especially the part of the effort that has been put to simplify and rationalizing the model design. That's probably where went wrong with my interpretation, as my bias is that many of the resulting deep levels of indirection in the GMF Runtime architecture were often the result of trying to serve two masters -- a model and a very general programmatic API. My thinking is that greater clarity in the model will support more direct API in some places. I also think there is a lot of room for enhancements and improvements in the runtime UX, so maybe that was wishful thinking and perhaps Graphiti will be a better target for that. Again, I hope my comments were not excessively critical. Creating great software is a community learning experience. I do think we can get better at being willing to voice critiques when we have them, as this is the only way that tools will get better. cheers, Miles On 2012-07-15, at 11:04 PM, Philipp W. Kutter | Montages AG wrote: Let me please do a small clarification w.r.t. the remark of Miles regarding GMF Tooling / Runtime. I want to do this, because there where unfair and unprofessional remarks regarding GMF Tooling both in talks and blogs, thus I hope you forgive me the rather lengthy mail. Miles: I know you only had the best intentions. +1 to all of this. I think it's the right way to go and will have a really positive effect on acceptance of modeling. I think there are areas where it makes sense to keep sub-projects and or umbrella projects but that should be guided by real affinity or obvious coordination. GMF Runtime and Tooling be handled is one interesting example. On the one hand they have very obvious affintiy and coordination needs, but OTOH, GMF Runtime is and I think should be evolving more to a clean graphical API that isn't so much driven by being a target for generated code. Actually the situation between the two projects is exactly the contrary: GMF Tooling is and will evolve more into a clean MDA Architecture from a platform independent domain model (PIM) for diagram editors to a given platform (GMF Runtime) with all its limitations. The PIM of the domain of diagram editors is the right basis for a clean graphical API in my opinion. The splitting IS a success, but NOT because it allowed GMF Runtime to evolve (GMF-R has almost no funding behind, and activity is low), BUT becuase it allowed GMF Tooling (which as 3 FTEs working longtime on the open source framework, without commercial obligations) to evolve it to cover not only the GMF Runtime platform, but as well the Graphiti platform (first prototypes being here), and as well to start covering the HTML5/Web platform, based on an own runtime. Last remark: IF anyone really has funding and plans to evolve GMF Runtime into a clean graphical API, this should be done in cooperation with the GMF Tooling team, and not independently. The GMF Tooling team is always happy to share experience and welcome Eclipse people to work with them in their Prag office. _______________________________________________ modeling-pmc mailing list modeling-pmc@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/modeling-pmc ______________________________ Miles T. Parker Senior Solutions Architect Tasktop Committer, Eclipse Mylyn and Virgo Project Lead, Model Focussing Tools and AMP |