GMF Kickoff Meeting

The GMF project kickoff meeting was held at the Corinthia Panorama Hotel, located in Prague, Czech Republic from Tuesday, July 19^th to Thursday, July 21^st.

These notes were exported from a mind map tool used during the meeting. The original map file can be obtained here and viewed with a free viewer for those interested.

Attendees

Borland

Richard Gronback richard.gronback@borland.com

Artem Tikhomirov artem.tikhomirov@borland.com

Max Feldman max.feldman@borland.com

Alexander Shatalin alexander.shatalin@borland.com

Pavel Feldman pavel.feldman@borland.com

Andrei Ivanov andrei.ivanov@borland.com

IBM

Daniel Leroux dleroux@ca.ibm.com

Fred Plante fplante@ca.ibm.com

ILOG

Joel Cheuoua jcheuoua@ilog.fr

Tiger

Gabriele Taentzer gabi@cs.tu-berlin.de

Karsten Ehrig karstene@cs.tu-berlin.de

Stefan Hansgen haensgen@cs.tu-berlin.de

Protos

Henrik Rentz-Reichert hrr@protos.de

Schedule

Tuesday

9:30 - 10:00 Welcome and Introductions

The GMF Kickoff meeting started on time, with those in attendance as listed elsewhere in this document.

10:00 - 12:30 Requirements Review

The list of posted GMF requirements was reviewed and updated based on anticipated milestone dates, but with only specificity of either M1 or M+. M1 is anticipated to be possible by the Q4 timeframe, 2005 while no dates are practical to estimate regarding future milestones at this time.

12:30 - 1:30 Lunch

1:30 - 3:30 Contribution Review Discussion

A brief review and discussion of each of GMF's contribution presentations took place. It was generally agreed that projects which were not based already on EMF were inappropriate to form a basis for GMF, as the amount of work required to refactor was equal or greater than to start from the Borland prototype in combination with the IBM runtime contribution.

3:30 - 4:00 Break

4:00 - 6:00 Contribution Review Discussion

Updated Tiger Presentation

The Tiger Project team gave an update to their contribution presentation, along with a demonstration of the work they have done integrating with EMF. Upon further discussion by the end of the meeting, it became apparent that the Tiger and AGG functionality could be applied to EMF in a general way to provide a valuable complement to the EMF runtime in terms of pattern-based command definition and graph manipulation.

Additionally, it was discussed how the Tiger project could integrate with the IBM contributed runtime components.

7:00 - 10:00 Team Dinner

Borland sponsored a team dinner at Ambiente (a Brazilian restaurant selected by Max).

Wednesday

9:30 - 11:00 Design Discussion

Diagram Definition

The concept of diagram definition and the models required for GMF was discussed at length. Another section of this document outlines the discussion in detail.

11:00 - 12:30 Borland Prototype walk through

Artem demonstrated his work to date on the Borland prototype, including an end- to-end process of diagram definition, domain model mapping, generation and runtime models. It was discussed later in the context of the IBM runtime contribution, to which a refactoring to support seems rather straightforward.

In general, it seems the group came to early consensus on the overall design and flow of GMF functionality, as it is apparent the approaches taken by each team was similar. One difference which was discussed at length was the reuse of the "runtime" model for diagram definition. More detail on this topic is found elsewhere in this document.

12:30 - 1:30 Lunch

1:30 - 3:30 Design Discussion

Generation

On the topic of mapping definition, the concept of using QVT technologies, Merlin-like mapping models and BSH scripts, or plain Java were discussed. It was agreed that plain Java would be effective for use on a first release, while other more advanced (likely OCL- based) techniques are possible in the future.

On the topic of generation, the Borland prototype provided for a generation metamodel which included all aspects of diagram, domain, tooling, etc. information for final use in code generation with JET templates. This generation model was created with inputs from separate diagram definition, mapping, and domain model(s). The question of whether or not you can achieve all from a single mapping definition was raised, and presented as an option in an IBM prototype. The majority seem to believe that it is more conceptually pure and in keeping with the EMF genmodel approach to have a genmodel only be provided for code generation parameters and runtime configuration options.

Runtime

The runtime component of GMF was discussed in the context of the IBM contribution.

3:30 - 4:00 Break

4:00 - 6:00 IBM Contribution walk through

Fred provided a review of the contribution material and also demonstrated the samples created to illustrate its different aspects, including a version of the GEF Logic diagram which uses the runtime.

It is clear that to target this runtime in the generation of GMF is desired, while it was also agreed that a Toolsmith may wish to bypass certain pieces in favor of a custom implementation. This flexibility should be allowed for in GMF.

Thursday

As the meeting proceeded smoother than was anticipated, the meeting concluded early on Thursday (~1:00 pm). Well done, and thanks to all who participated!

9:30 - 12:30 Design Discussion

The main design discussion occurred on Wednesday, leaving only a review and agreement on chosen models and naming conventions.

12:30 - 1:30 Lunch

1:30 - 2:00 Requirements Reloaded

This revisit to the requirements was very brief, as it was determined that the initial milestone determinations were correct. However, an update to the requirements document is now required to conform with the agreed naming conventions.

Also, it may make sense to classify each requirement by the applicable "themes and priorities" as described in the overall Eclipse requirements for the next release.

2:00 - 3:30 Project Plan & Milestones

It was agreed that at this stage, there is not enough data to determine milestone dates. However, it was decided that the GMF project will "opt in" to the overall strategy to align the 1.0 release with the scheduled platform release (3.2) due end of Q2 2006. Furthermore, GMF will target Q4 2005 (or sooner) for an M1 milestone and determine the remaining milestone goals and dates once development begins.

Checkpoint Review

In accordance with the Eclipse development process, a Checkpoint review is required to enter the Implementation Phase. This review will be scheduled with the Technology PMC following approval of these minutes and a draft of the project plan is produced.

3:30 - 4:00 Break

4:00 - 4:30 Project Administration

A discussion of general project administration topics occurred and is documented elsewhere in this document.

4:30 - 5:00 Wrap up

Discussion Items

Technical

Is XMI[DI] to be the default serialization syntax?� Or, just an export option?

Agreed to provide export only, not natively persist to XMI[DI].

Builds

See document: readme.html

CruiseControl?� Alternative?

See document: eclipse-tpi

It was agreed that CruiseControl is a reasonable place to start. Note that the Technology Project Infrastructure proposal intends to provide support for builds, an CruiseControl in particular.

Audits/Metrics?

A set of automated audits and metrics will be run on all source code during the build process and results published.

Ship as jars?

No issues are known with current method of shipping as jars, but it is agreed that both forms should be made available. In some cases, as with templates, it is necessary to ship with a folder structure.

Frequency of daily, weekly, integration builds and what time (zone)?

It was agreed that GMF should follow the platform example regarding periodicity, while our dependencies must also be taken into consideration for Integration builds (EMF and GEF at present).

Generate source from models?

The possbility to only maintain model definitions and therefore always precede a build process with a code generation step needs to be examined.

Build machine

Until the Technology Project Infrastructure proposal is underway and a common build machine and process is available, Borland will provide build machines for the project. With that, the build process instructions will be documented and tested on machines in Prague and the US, where the builds will run.

Component list and assignments (owners)?

It seems reasonable that since the IBM contribution is the runtime, that their team will initially own that component. Borland contributors and others can therefore focus effort on the definition and generation components.

The web, doc, and releng components will be looked after by the project lead, while it is still too early to consider the tools component.

TODO: Update Bugzilla to reflect this list. [status: sent request to Denis Roy 07/22/2005]

doc

releng

tools

definition

generation

runtime

web

CVS project structure

/home/technology

/org.eclipse.gmf

/doc

/features

/org.eclipse.gmf-feature

/plugins

/org.eclipse.gmf.diadef

/org.eclipse.gmf.diagen

/org.eclipse.gmf.runtime

/releng

/org.eclipse.gmf.releng

/org.eclipse.gmf.releng.builder

/tests

/org.eclipse.gmf.tests.*

/tools

/org.eclipse.emf.ecore.*

/org.eclipse.uml2.*

/home/cvs/org.eclipse

/www

/gmf

/contributions

/development

/images

EMF Technology Proposal

See document: index.html

IBM Contribution?

The IBM contribution will initially all go into the GMF project as planned, and as agreed upon by the IBM legal organization. However, there are components in the contribution which will logically migrate into the EMF Technology project proposal, or into EMF itself. There is also the possibility that portions will end up in the GEF project.

Model mapping technologies

A number of model mapping technologies are, or will become, available in the future which are options for GMF. A brief discussion of these took place, with consensus being that in the absence of a true standard or available open source toolset, GMF would rely initially on Java- based definition for model mappings.

Java

Scripting language (Groovy, BSH, etc.)

QVT-ish

GMT

GMT was looked at as an option, and it was hoped that Jean Bezivin of the GMT project would make the meeting to clarify a few questions. Initial investigation into GMT indicated that it may not be appropriate for a first release of GMF.

MTF (plans to open source?)

MTF was explored (prototyped) as an option, but without a clear understanding of the project's direction or intention to open source.

AGG Rules

A high level pattern-based definition of editor commands for diagram modification could be provided in further releases by AGG Rules extending the EMF runtime.

Platform common command infrastructure?

It was agreed that as EMF and GEF adopt the new command infrastructure of the platform, GMF would also leverage these capabilities. Until such time, the functionality of the contributed runtime will be used and modified as required.

Localization... WWDI?

A question regarding localization was raised, particularly, "who will do it"?

TODO: inquire if Borland can support l10n efforts for GMF, at least for its standard list of supported languages. IBM may be able to help as well, particularly

Administrative

Does Eclipse need a top-level modeling project?

The possibility of GMF rolling under a top-level modeling project, if one to be created, was discussed briefly. It is generally thought that at present, there is not likely a need for such a project, but that with an increase in model- centric projects it may one day be a logical development within the community.

EMF, GMT, MDDi, GMF

PMCs, Councils, etc. : how it works?

See document: roadmap.html

A brief discussion of how the Eclipse Foundation operates occurred, focusing on GMF's position under the Technology project as a incubator.

How to become a Committer?

A general explanation of the Technology project's charter and its philosophy of Committer voting took place. Basically, with the exception of the 3 initial Committers from Borland, which were appointed by the PMC, there would likely be a number of voted-in Committers for the IBM contribution. Other Committers will be added to the project using the same meritocracy approach as described in the charter (including subsequent Borland and IBM contributors).

Communication

IM?

ECF?

The Eclipse Communication Framework may provide a way to communicate, although it would require a server to be set up and maintained. For now, we will give Skype a try.

Skype?

We decided to try and use Skype for synchronous communication within the group. Information on Skype will be sent out to the developer mailing list (done).

Development resources

See document: GMF Development

A list of resources is presented on the new web page dedicated to Developers on the project. It was briefly shown and discussed.

Fluff topics

These topics were saved until last (well, nearly last), after we were all tired of discussing contributions, design, etc.

Logo?

Does GMF need a logo? GEF has one, and it would seem appropriate for any project with "Graphical" in its name to have a logo. Perhaps a graphic artist will contribute time to create one? A lot of ideas come to mind, particularly combining the letters of EMF, GEF, and GMF in some pattern.

Project T-shirts?

The group seemed to agree that to have project T-shirts made by the next EclipseCon is a good goal, and of course should have whatever logo we create.

Project nickname?

Although other projects have adopted nicknames in addition to their official Eclipse project names, it seems nobody has any to offer for GMF at this time.

Learning from other Eclipse projects

To emulate

Viewlets (e.g. VEP)

It was recommended that our tutorials and/or help system include Viewlets

Performance metrics (part of build)

It was recommended by Fred that GMF adopt a similar automated performance testing process as part of the build as do other projects, including the platform.

TODO: investigate implementation as part of already started releng work.

What's new? documents

It was recommended that GMF always generate "What's New?" documents for releases.

What's next and when?

In addition to "What's New?" documents, it was recommended by Artem that we produce documents that indicate what's coming, and when.

RSS Feed? (optional)

For those that would like to be notified of updates to the "What's next and when?" document, an RSS Feed option should be provided.

In general, GMF should provide RSS feeds to appropriate items.

Breaking builds: strict conformance

As with other projects, GMF's Developer Resources page should include information regarding how to avoid breaking the build, and what the protocol is for when it is broken by a code check-in.

TODO: update Developer Resources page

To avoid

Poor documentation (code comments, help, tutorials, etc.)

It is agreed that GMF should strive to provide adequate documentation, in all forms. Eclipse projects vary greatly in this aspect, currently.

Endless repeated newsgroup postings

GMF needs to avoid spending effort on repeated newsgroup postings. It seems many newsgroups suffer from reader software limitations on local persistence and search capabilies (in addition to posters that just don't think to look).

FAQ?

One possible (partial) solution to repeated newsgroup answers (if not questions), is to point the post to a well-maintained FAQ document.

TODO: add FAQ document (once a download is available)

Standard dev mailing list reply: "Please post these questions to the newsgroup..."

Although a familiar pattern on developer mailing lists, no obvious solution seems to exist, aside from moderated mailing lists. Currently, GMF does not suffer from this or the newsgroup issues found on projects like EMF.

Diversity in contributors

It is agreed that projects benefit from a diverse set of contributors. GMF has started with a broad range of interested parties, so it is not anticipated the project will have a problem with this, at least initially.

Less-than-exemplary tools

The TPTP project is now making a concerted effort to improve its "exemplary tools". From the beginning, it is agreed that GMF should strive to provide high-quality examples, not only in those provided to Toolsmiths for use in GMF, but also in those products generated using GMF.

Lack of update site

Update sites are valuable to the community, and it is agreed that GMF should utilize one as soon as an initial download is available.

Terminology

� Models

Graphical Definition Model (.gmfgraph)

Similar to Borland's diagram definition model (.diagramdefinition)

IBM's notation model (.ddm) was used both for "runtime" and definition.

Tooling Definition Model (.gmftool)

Mapping Model (.gmfmap)

Generation Model (.gmfgen)

**Runtime Diagram Model (.*-diagram)**

Similar to Borland's diagram runtime model (.diagramrt)

Renaming of IBM's notation model

A lengthy discussion took place on the topics of user (toolsmith) workflow and the (meta)models required for GMF. Below is a summary of the conversation in a Q&A format:

Q: Does the metamodel used to define a diagram need to be the same as the one leveraged in the runtime?

A: Not necessarily, and in fact it may be beneficial to not have them the same. Although it is conceptually more simple to have them the same, we have chosen to not restrict tooling in this requirement from the beginning, while it may yet become apparent that having them the same is the best approach.

Q: Why not combine the notion of mapping, tooling, and generation into a single model?

A: This is again more conceptually simplistic and goes along with the "keep it simple" mindset. However, it is not felt that having separate, decoupled models for mapping, tooling, and generation is a problem (other than the need to maintain them in synch). Again, it may turn out that they are combined to some extent in the end, but to start we will proceed with multiple models, as exists in the Borland prototype.

Q: Doesn't the large number of models present unnecessary complication to the Toolsmith in the development of GMF- based products?

A: The goal is to mask the number of models and their potential complexity with a well-designed user interface where related concepts will be presented in an integrated fashion.

Q: Should GMF's generated functionality always be required to leverage general, extensible facilities of the runtime, or should it be possible to also generate straight to code (or a combination)?

A: It is certain that targeting the provided runtime with its extensibility mechanisms is a requirement, although the framework should not mandate this in all cases. Indeed, a combination of generative and runtime extensibility approaches may be preferred in some cases.

Q: What mapping technologies are to be used?

A: It is thought that straight Java will be used to define rules in mappings and runtime constraints where required at first, while OCL-based or QVT- based (in the case of mapping definition) approaches may be used in the future.

Q: Where does the definition of commands take place?

A: At first, it is believed that hand-crafted Java implementation will be used, while GMF may be augmented with Tiger Project functionality for the definition of rules for the interpreted and possibly generated implementation of runtime command execution on the model(s).

Q: How are model semantic characteristics of the domain's abstract syntax defined and represented in the graphical environment?

A: Initially, until the availability of OCL is present in the EMF, these will remain Java-coded aspects. It is believed that a fair number of additional constraints defined in OCL will allow for the generation of behavior in the diagram runtime environment.

Roles

Toolsmith

It was agreed that requirements and documents regarding GMF workflow will use the title "Toolsmith" when referring to the individual utilizing GMF tooling for the design of diagram definitions, mappings, tooling, etc.

User

To provide distinction between the user of a generated application based on GMF, and the individual developing the application using GMF, it was agreed that "User" refers to the former, while "Toolsmith" refers to the latter.

Requirements Legend

These are the agreed upon abbreviations for terms found (or to be found) in GMF requirement documents.