Was gibt es Neues in Groovy-Eclipse 2.5.0?

Groovy-Eclipse wird "Groovier"

Das Groovy-Eclipse-Plug-in ist kürzlich in Version 2.5.0 erschienen. Projektleiter Andrew Eisenberg gibt einen Überblick über das Release und spricht über Herausforderungen und die für Ende Juni geplante Veröffentlichung von 2.5.1.

JAXenter: Groovy 2.5.0 ist erschienen. Eines der neuen Features ist die Unterstützung für DSL-Deskriptoren. Was hat es damit auf sich?

Andrew Eisenberg: Groovy DSLs werden in fast allen Groovy-Bibliotheken und dem Core-GDK verwendet. Bisher wurden allerdings nur einige wenige dieser DSLs ausdrücklich in Groovy-Eclipse unterstützt. Um Content-, Navigations-, Such- oder Editier-Support für diese DSLs zu erhalten, musste man selbst erstellte Erweiterungen von Groovy-Eclipse auf Basis der Eclipse-Plug-in-APIs nutzen.

Seit Version 2.5.0 unterstützt Groovy-Eclipse nun DSL-Deskriptoren (DSLDs). Sie erlauben es den Nutzern, ihren eigenen Editier-Support für spezifische DSLs mittels Groovy-Scripting zu entwickeln. Es gibt bereits einen DSLD-Deskriptor für Griffon und bald soll einer for Gaelyk folgen. Die DSLDs für diese Frameworks wurden von der Community erstellt, was eine der Stärken dieses Features zeigt: Weil jeder DSLDs bauen kann, können nicht nur Bibliothek-Designer, sondern auch Endverbraucher einen Teil beitragen. Am Ende steht somit ein sehr viel intelligenterer Editor und ein besseres Anwendungsverhalten für Endverbraucher.

JAXenter: Wie hat sich die OutlineView in Version 2.5.0 verändert?

Andrew Eisenberg: Die OutlineView ist in dieser Version sozusagen „Groovier“ geworden. Vor 2.5.0 zeigte die OutlineView einer Skript-Datei einfach eine Dummy-Klasse, ein paar Methoden und einige Konstruktoren – nichts, was wirklich im Quellcode existierte. Diese Outline war direkt aus Eclipse Java Model des Skripts generiert worden, und das scheint einige Nutzer verwirrt zu haben.

Mit der Veröffentlichung von 2.5.0 zeigt die OutlineView jetzt aber interne Groovy-Strukturen in Skripten an. Das Eclipse Java Model wurde entfernt, stattdessen werden Skript-Variablen und Methoden-Deklarationen angezeigt. Das macht das Navigieren durch die Skripte einfacher.

Diese Verbesserung wurde von der Community realisiert. Das JSpresso-Team wollte sicherstellen, programmatische Kontrolle über die OutlineView zu erhalten, um ihre DSLs domänenspezifisch anzeigen zu können. Wir sind dankbar für das starke Engagement der Community in Groovy-Eclipse, das dabei hilft, das Projekt weiter voran zu bringen.

JAXenter: Was war die größte Herausforderung bei der Entwicklung von Groovy-Eclipse?

Andrew Eisenberg: Die größte Herausforderung war bisher, die Eclipse Java Development Tools (JDT) so umzuschreiben, dass auch nicht-Java-Quellcode erkannt wurde – in unserem Fall Groovy. Die JDT verfügen über einen toll konzipierten Compiler und ein qualitativ hochwertiges Werkzeug-Set, das aber speziell für die Java-Entwicklung gebaut wurde. Weder der Compiler noch die Tools (Refactoring, Suche, Content Assist, etc. ) wurden dazu entwickelt, polyglott, also mehrsprachig zu arbeiten.

Wir haben das grundlegende Integrationsproblem vor etwa zwei Jahren mit dem Release von Groovy-Eclipse 2.0.0 gelöst. In dieser Version war ein veränderter JDT Compiler und ein angepasster Groovy Compiler enthalten, die gemeinsam in der Lage waren, Java- und Groovy-Code mittels inkrementeller Kompilierung zu übersetzen.

Ein Vorteil dieses Compilers besteht darin, dass er keine Java-Stubs für Groovy Quellcode erstellt, so wie gemeinsame Groovy- und Java-Projekte auf der Kommandozeile kompiliert werden. Obwohl dies das Problem auf Compiler-Ebene gelöst hat, kämpfen wir immer noch mit der fehlenden Flexibilität in den Tools. Beispielsweise setzt ein Rename-Refactoring mit JDT voraus, dass alle umzunennenden Bezeichner identisch sind. Bei Groovy allerdings kann auf die Getter- und Setter-Methoden durch den Property-Namen und ohne die Get/Set-Präfixe zugegriffen werden, was mit den Refactoring-Konventionen von JDT bricht. Obwohl das JDT einige Möglichkeiten zur Erweiterung im Refactoring-Framework bietet, ist es einfach nicht genau so erweiterbar, wie wir es benötigen. Deshalb werden wir wohl eine eigene Lösung dafür finden müssen.

In der Zusammenarbeit mit dem JDT-Team ging es darum, Wege zu finden, wie die Java Development Tools geöffnet und besser für andere Sprachen zugänglich gemacht werden können. Diese Arbeit steht aber noch am Anfang. Das größte Problem im Moment ist, wie wir einige der Groovy-Eclipse-Patches zurück in JDT einbringen und dabei rückwärtskompatibel bleiben können, ohne das API zu brechen. Eine wirklich große Herausforderung.

JAXenter: Groovy-Eclipse 2.5.1 ist für Ende Juni geplant. Was dürfen wir von diesem Release erwarten?

Andrew Eisenberg: Wir arbeiten an einigen sehr aufregenden Features. Als erstes planen wir eine offizielle Veröffentlichung des Groovy-Eclipse-Compiler-Plug-ins für Maven. Das Maven Plug-in gibt es schon seit einer Weile, es ist aber nur eine Rohversion und nicht auf Groovy 1.8 abgestimmt. Die Community hat sich in der letzten Zeit aber vermehrt über GMavens Probleme mit der Stub-Generierung in gemischten Groovy/Java-Projekten geäußert, die einigen Usern viel Kopfzerbrechen beschert hat. Da Groovy-Eclipse keine Stubs benötigt, wird dieses Problem vermieden.

Wir planen außerdem einen vollen UI-Support für das Hinzufügen dynamischer Methoden und Properties zu Groovy-Typen. Dieses Feature soll das Anpassen von Type-Inferencing im Editor vereinfachen und lästige Unterzeilen vermeiden, wenn der Editor die Type-Infomationen für eine Referenz nicht bestimmen kann, der Nutzer aber schon.

Der DSLD-Support wird außerdem verbessert. Wir befinden uns derzeit im Gespräch mit IntelliJ, um an einer Integration zwischen unserer DSLD-Unterstützung und deren GDSL-Support (ein vor Kurzem erschienenes Feature, das unserem ähnelt) zu arbeiten.

Zusätzlich planen wir einige kleinere Verbesserungen im Bereich des Contents Assist, Type Inferencing und Klassenpfad Management. Genaue Details werden folgen.

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

Andrew Eisenberg ist Leiter des Groovy-Eclipse Projekts und arbeitet darüber hinaus am Grails-Tooling der SpringSource Tool Suite. Andrew entwickelt IDE Tools, um die kognitive Belastung beim Bauen komplexer Programme zu verringern. Er ist nicht zufrieden, bis die Nutzung eines Programms so einfach und unterhaltsam ist, wie das Spielen mit Legosteinen. Andrew verfügt über einen PhD in Computer Science an der Univerity of British Columbia, wo er die Überschneidungen von Programmiersprachen und Tools untersucht hat.
Kommentare

Schreibe einen Kommentar

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