Das Eclipse Modeling Framework in Eclipse Indigo

Ed Merks: EMF Status Quo

Innovationsschmieden gibt es viele bei Eclipse – der Bereich Softwaremodellierung gehört sicherlich dazu. Fast sämtliche Eclipse-Modeling-Technologien basieren dabei auf EMF, dem Eclipse Modeling Framework. Maßgeblich beteiligt an der Entwicklung von EMF ist Ed Merks, der einen Überblick über den aktuellen Stand von EMF im Eclipse Indigo Release Train gibt.

JAXenter: Wenn man alle Unterprojekte mitzählt, gibt es inzwischen mehr als 60 Projekte unter dem Eclipse-Modeling-Top-Level-Projekt. Wird die Zahl der Projekte weiter zunehmen oder ist der Zenit bereits erreicht?

Ed Merks: So viele Projekte sind es gar nicht, denn die Subprojekte sind in elf direkte Unterprojekte des Top-Level-Projekts unterteilt, die als Sammelbecken mit relativ breitem Themenumfang für die vielen Projekte dienen. Ich denke also nicht, dass diese Zahl in Zukunft stark ansteigen wird. Aber auch die Gesamtzahl der Projekte würde wohl in Zukunft nicht so stark wachsen, wenn wir inaktive Projekte zeitnah terminieren würden. Im Moment ist es so, dass die erfolgreichen Projekte aus EMFT (EMF Technologies) zu EMF aufsteigen.

JAXenter: Was ist das innovativste Projekt, das erfolgreichste Projekt und was der Top Newcomer im Modeling?

Merks: Ich denke, Xtext ist und bleibt mit der Implementierung von Xtend als Ersatz für Xpand eines der innovativsten Projekte. Was den Top Newcomer angeht, ist das schwierig zu sagen, da müsste ich alle neuen Projekte aufzählen.

JAXenter: Und was ist mit dem erfolgreichsten Projekt?

Merks: Auch schwer zu sagen. Ich denke nicht, dass sich irgendeines der Projekte wirklich signifikant mehr als die anderen bewährt hat. Das würde ich nach dem Interesse am Projekt in der Newsgroup beurteilen.

JAXenter: EMF wird auch in immer mehr Eclipse-Kernprojekten wie e4 eingesetzt, die gar nichts mit Modellierung zu tun haben. Worin könnte ein Grund liegen, EMF nicht in anderen Projekten einzusetzen?

Merks: Ich habe in der p2 Mailingliste interessante Diskussionen gelesen über die Idee, p2 Repositories als EMF-Modelle abzubilden. Auch gab es Anregungen, für die plugin.xml EMF einzusetzen. Trotzdem finden die Leute immer wieder die gleichen Gründe, EMF nicht einzusetzen:

  • EMF sei zu komplex
  • EMF sei schwierig zu erlernen
  • Ich will keine zusätzlichen Abhängigkeiten einführen
  • Ich will all diese zusätzlichen Funktionen nicht, zu denen mich EMF zwingt
  • Ich mag keine Modellierung
  • Ich mag keine Codegenerierung
  • Ich will meinen Code von Hand komplett selbst schreiben, da ich ihn dann wirklich gut verstehe und zu 100 Prozent Kontrolle behalte.

Natürlich versteht dann niemand anders diesen Code gut, und niemand anders hat die Kontrolle.

JAXenter: Es gibt selten neue Features in EMF. Was ist der Grund dafür? Wo steht EMF in seinem Lebenszyklus, wo steht EMF in fünf oder zehn Jahren?

Merks: Die meisten geforderten Features sind nur noch kleine inkrementelle Verbesserungen. Es gibt kaum noch die Nachfrage nach großen neuen Features. Viele dieser kleinen Verbesserungen werden wahrscheinlich nicht umgesetzt, denn es gibt kaum jemanden, der noch bereit ist, Zeit zu investieren. Aus meiner Sicht liegt das daran, dass diese kleinen Änderungen kaum mehr den Aufwand wert sind, vor allem weil man immer beachten muss, dass Änderungen keinen Einfluss auf andere Anwender haben dürfen. Die Abwägung ist immer: Wer kann davon profitieren, wer hat davon eventuell einen Nachteil? Und natürlich auch, wie viel zusätzlichen Pflegeaufwand erfordert das in Zukunft? Überhaupt nimmt die Frameworkpflege inzwischen den größten Teil meiner Arbeit ein. Und ich bin fast der einzige, der noch Änderungen am Kern vornimmt. Man kann also definitiv sagen, EMF ist eine reife Technologie, vergleichbar mit Java selbst. Das ist umgekehrt auch der Grund dafür, warum Innovation inzwischen vor allem außerhalb des Kerns stattfindet. Die Subprojekte und auch alle anderen Nutzer können sich dadurch auf einen stabilen Kern verlassen.

JAXenter:Wenn es ohne Kompatibilitätsprobleme möglich wäre, was wären die wichtigste Änderungen, die man vornehmen sollte?

Merks: Ich würde keine Subpackages von EcorePackage mehr erlauben. Das ist so aufwändig und bringt keinen richtigen Vorteil. Das ist semantisches Gift. Immer wenn neue Tools geschrieben werden, vergessen die Entwickler die Funktionen auch mit Subpackages zu testen, und es funktioniert immer wieder nicht.

JAXenter: O.K., nochmal in die Zukunft: Was wird die wichtigste Neuigkeit bei EMF in einem Jahr sein?

Merks: Ein textueller Editor für Ecore und XBase als Sprache, um Methodenkörper zu beschreiben, sodass das Model auch ausführbar wird. Damit würde ich mich sehr gerne beschäftigen.

JAXenter: Vielen Dank für das Gespräch!

Ed Merks ist Projektleiter des Eclipse Modeling Projects sowie des Eclipse Modeling Frameworks. Nach Tätigkeiten bei IBM und im IBM Rational Toronto Lab ist er zurzeit bei der itemis AG engagiert. Ed Merks ist Absolvent der Simon Fraser Universität und Doktor der Informatik.

Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.