Automatische Task Execution im Buildship Plugin

Wenn Sie mit Eclipse arbeiten, dann kennen Sie das Buildship Plugin. Das Plugin ist der Kleber der das Buildsystem Gradle in die IDE integriert. Mit der Version 3.1 des Plugins ist es nun möglich Tasks in Gradle bei der Projektsynchronisation und während des automatischen Builds zu starten. Dieses waren die höchsten bewerteten Wünsche auf GitHub. Hier will ich kurz die Möglichkeiten die sich daraus ergeben kurz darstellen.

Tasks während der Projekt Synchronisation ausführen

Die Gradle Projektsynchronisation importiert das Gradle Projekt in den Workspace und konfiguriert die Java Toolchain, damit alles zusammen funkioniert. Wie bereits angesprochen, wollen viele User während dessen eigene Tasks ausführen, um zum Beispiel Konfigurationen zu erstellen oder updaten. Das manuelle Ausführen dieser Aufgaben ist störend und auch fehleranfällig. Durch die automatische Ausführung der Aufgaben, kann der Entwickler sich auf das Coden konzentrieren.

Wie nutzt man das Feature?

Damit man das Feature nutzen kann, muss Gradle in der Version 5.4 oder höher vorhanden sein und Buildship mindestens in der Version 3.1. Ab Gradle 5.4 wurde ein neues Attribut synchronizationTasks in dem Eclipse Plugin eingeführt.

plugins {
    id 'eclipse'
}

task generateCustomConfig {
    doLast {
          println "Generating custom configuration..."
    }
}

eclipse {
    synchronizationTasks generateCustomConfig
}

Das war es auch schon. Wenn Sie nun das Projekt importieren oder synchronisieren, dann wird der Task generateCustomConfig ausgeführt und die Meldung erscheint in der Konsole.

Hinweis: Task synchronsization ist mit einer Referenz auf Task deklariert. Es können also unterschiedliche Typen verwendet werden: Strings um den Task Pfad zu spezifizieren, eine Liste von Tasks und vieles mehr. Grundsätzlich kann jeder task dependency Typ verwendet werden.

Ausführung von Tasks während des Eclipse build Vorgangs

Neben den bereits ober vorgestellten Feature ist als zweite Einstiegsmöglichkeit, dass einklinken in den Buildprozess nun möglich. Wenn also der Benutzer eine Resource ändert und ein Build angestoßen wird, kann man nun Aufgaben durchführen lassen. Zum Beispiel kann man einen Code Generator anwerfen oder Validierungen durchführen.

Der Aufruf erfolgt sehr ähnlich:

plugins {
    id 'eclipse'
}

task generateCode {
    doLast {
        println 'Generating some code...'
    }
}

eclipse {
    autoBuildTasks generateCode
}

Zusammenfassung

Die neuen Möglichkeiten die das Eclipse Buildship Plugin nun bietet sind sehr interessant und nehmen dem Entwickler viel Arbeit ab und können möglich Fehler vermeiden zu helfen, indem man Aufgaben automatisieren kann.

Eclipse und Gradle

Leider ist das Debuggen bzw. die Anlage einer Debugkonfiguration in Eclipse nicht ganz so trivial, wenn man das Java Modulesystem verwendet und Gradle als Buildsystem einsetzt. Dann liegt die Verantwortung der Dependencies bei Gradle und das Buildship Plugin von Eclipse stellt diese dann in Eclipse zur Verfügung.

Fehlermeldung beim Start

Startet man eine neu angelegte Debugkonfiguration (im Buildpath von ist JUnit 5 nicht angelegt und braucht sie auch nicht), dann erhält man eine Could not run test Fehlermeldung auf der Konsole:

java.lang.IllegalAccessError: class org.junit.platform.launcher.core.LauncherFactory (in unnamed module @0x3f200884) cannot access class org.junit.platform.commons.util.Preconditions (in module org.junit.platform.commons) because module org.junit.platform.commons does not export org.junit.platform.commons.util to unnamed module @0x3f200884

JUnit5 anpassen

Der ist das die Packages org.junit.platform.commons.util und org.junit.platform.commons.logging die ALL-UNNAMED Packages exportieren. Daher muss in den Debugkonfiguration die folgenden VM Parameter anhängen, dann verschwinden die Start Fehlermeldungen unter Eclipse und das Programm kann debugged werden.

--add-exports org.junit.platform.commons/org.junit.platform.commons.util=ALL-UNNAMED --add-exports org.junit.platform.commons/org.junit.platform.commons.logging=ALL-UNNAMED

Nun lässt sich mit Klick auf Debug die Anwendung debuggen.

Spring Tools 4 Update

Am 22.01.2020 wurde das neue Update der beliebten Spring Tools 4 Suite veröffentlicht. Im allgemeinen sind Verbesserungen und Fehlerbeseitigung in Eclipse vorhanden. Ausnahme bildet der Hover Mechanismus, der nun auch Connection Failures anzeigen kann.

Spring Boot

  • Live hover können nun Connection Failures anzeigen

Eclipse

  • Completions werden nun asynchron durchgeführt
  • Early access builds für Eclipse 4.15 verfügbar
  • Bei der Autovervollständigung für Parameter in @Value Annotationen wurde immer ein zusätzliches NewLine eingefügt
  • Das Spring Boot Dashboard konnte Projekte die ein Leerzeichen enthalten nicht starten
  • Eine NPE in PropertiesJavaDefinitionHandler.adjustedHighlightRangeForKey wurde gefixt
  • Neueste m2e Snapshot um Probleme mit JUnit 5 Tests zu beseitigen

Buildship does not support JDK 13

In einem Test wollte ich mit den aktuellen Spring Tool Suite die neuen Features von Java 13 testen. Also habe ich die sourceCompatibility in build.gradle kurzerhabnd auf 13 gesetzt. Doch Eclipse konnte das Project nicht bauen. Nach kurzem suchen im Netz bin ich auf das Issue 1196 gestoßen. Das Eclipse Buildship Plugin wird erst in der Version 3.1.3 JDK 13 erkennen und unterstützen.

sourceCompatibility = 11 // can't use JDK 13 as buildship 3.1.3. See https://github.com/eclipse/eclipse.jdt.ls/issues/1196

Buildship 3

Die neue Version des Buildship Plugins wird die Version 3 sein. Die aktuelle stable Version ist 2.2.1.

Offen Punkte die noch zu fixen sind, sind in den Issues zu finden.

Neue Installationsquelle hinzufügen

http://download.eclipse.org/buildship/updates/e49/snapshots/3.x/

Installation überprüfen

Die erfolgreiche Installation kann in About Eclipse überprüft werden.

Neues Projekt mit Spring Tool Suite 4 erstellen

Nach dem Neustart von Eclipse kann jetzt ein Projekt mit dem Starter erstellt werden. Es kann nun Gradle Buildship 3.x ausgewählt werden.

Eclipse und der Modulepath

Mit Java 9 wurden die Module neu eingeführt (Projekt Jigsaw). Wenn man ein Projekt mit Modulen baut, dann müssen die Module auch in dem Modulepath vorhanden sein.

Das Buildship-Plugin von Eclipse setzt leider nicht alle Module automatisch auf den Modulepath, sodass bei jeder Änderung am gradle.build Skript man von Hand die Einträge im Buildpath Konfigurationsdialog verschieben muss.

Folgendes kleines Skript erledigt die Aufgabe für uns, wenn der Gradle Task eclipse ausgeführt wird.

//
// Will be executed when gradle Task Eclipse was called
//

eclipse {
    project {
        natures 'org.eclipse.buildship.core.gradleprojectnature'
    }

    classpath {
        file {
            whenMerged {
                entries.findAll { isModule(it) }.each {
                    it.entryAttributes['module'] = 'true'
                }

                entries.findAll { isSource(it) && isTestScope(it) }.each {
                    it.entryAttributes['test'] = 'true'
                }

                entries.findAll { isLibrary(it) && isTestScope(it) }.each {
                    it.entryAttributes['test'] = 'true'
                }
            }
        }

        defaultOutputDir = file('build')
        downloadSources = true
        downloadJavadoc = true
    }
}

boolean isLibrary(entry) { return entry.properties.kind.equals('lib') }
boolean isTestScope(entry) { return entry.entryAttributes.get('gradle_used_by_scope').equals('test'); }
boolean isModule(entry) { isLibrary(entry) && !isTestScope(entry); }
boolean isSource(entry) { return entry.properties.kind.equals('src'); }

Spring Tools 4.4.1

Am 24.10.2019 ist die neue Version der Spring Tools 4.4.1 erschienen. Neben Bugs die behoben worden sind, gibt es Änderungen bei den Live Informationen (s.u.).

Spring Boot

  • In Eclipse funktioniert nun das Goto Symbol auch in XML Bean Dateien
  • Der Fehler das in der Autovervollständigung in der application.properties manchmal Zeichenmüll hinterlässt wurde behoben
  • Die Performance für das Scannen der XML Symbole wurde verbessert
  • CVE-2019-18212 und CVE-2019-18213 wurden behoben

Live Data anzeigen

Mit Spring Boot 2.2 wurde das JMX per default abgeschaltet. D.h. möchte man weiterhin die Liveinformationen der Anwendung angezeigt bekommen, so muss man JMX Actuator Endpoint wieder mit -Dspring.jmx.enabled=true aktivieren. Ab Spring Tools 4.2.0 wird der in Eclipse integrierte Spring Boot Lauch Configuration diese Einstellung automatisch setzen, so dass das alte Verhalten wiederhergestellt ist und die Live Informationen abgerufen werden können.

OpenAPI 3.0.2

OpenAPI 3.0.2 ist der Nachfolger von Swagger API in der Version 2. OpenAPI erfreut sich immer der Beliebtheit und rückt den API Frist Designansatz immer mehr in den Focus. Der Contract der API ist der zentrale Dreh- und Angelpunkt. Es eigent sich gleichermaßen Server und Clientcode in beliebigen Sprachen über Codegeneratoren zu erstellen.

Eclipse Tools für OpenAPI

Für Eclipse gibt es zwar ein paar Tools, jedoch sind einige davon kommerziell und daher nicht in meinem Interesse. Diese sind aber durchaus gut für Anfänger, da sie dass Bearbeiten der API in einer UI in Eclipse ermöglichen, ohne das man wirklich OpenAPI in all seinen Fassetten kennen muss.

KaiZen OpenAPI Editor

Zunächst möchte ich den unter der EPL frei verfügbaren Editor KaiZen vorstellen. Neben den Syntaxhighlighting bietet der Editor kontextbasierte Codevervollständigung, so dass man immer weiß was an der Stelle erlaubt ist.

https://marketplace.eclipse.org/content/kaizen-openapi-editor

Codewind Codegenerator

Das Projekt Codewind ist noch sehr jung und befindet sich im Alphastadium. Ermöglicht aber die Codegenerierung anhand der OpenAPI spec anzustoßen.

https://marketplace.eclipse.org/content/codewind-openapi-tools

Spring Tool Suite 4.2.0

Hier kurz die wichtigsten Änderungen der neuen Version vom 28.03.2019.

  • Bislang gab es keine Möglichkeit der VM für den Language Server Procol process Parameter zu übergeben. Dieses kann notwendig sein, wenn zum Beispiel der Heap zu klein ist.

    -Dboot.ls.custom.vmargs=-Xmx2G

    Kann man den Heap für das LSP auf 2G anheben.

  • Stark verbesserte Performance. Der Cache der Symboleindizierung des LSP wird nun über Neustarts des LSPs hinweg gespeichert.

  • Die interne Kommunikation mit dem JDT wurde ersetztz, was auch zu einer erhöhten Performance durch zeit- und Speichersparmaßnahmen geführt hat.
  • Update auf Eclipse 2019-03.
  • In den Lauch-Configs wird JMX Unterstüzung nun per default gesetzt.
  • Ein out of sync Fehler bei den Live Hoover wurde behoben.
  • Verschiedene Fehler in der Navigation in den Live Bean wurde behoben.
  • Weitere kleinere Eclipse Probleme wurden behoben.

Spring Tool Suite mit Gradle unter JDK 11

Im allgemeinen funktioniert die Spring Tool Suite 4 (Version 4.0.2) unter dem aktuellen Java 11 LTS. Leider ist die Erkennung Java Versionen anscheinend sehr fragil, da zum Beispiel die aktuelle Version 11.0.1 nicht erkannt wird.

Dadurch funktioniert das Gradle Tooling (Eclipse Buildship Plugin) nicht und es wird das öffnen eines Gradle Projektes mit einer Fehlermeldung der Editoren quittiert.

An internal error occurred during: "Initializing Java Tooling".
Could not determine java version from '11.0.1'.

Bestimmung der JVM

Unter Arch Linux oder Manjaro werden die verschiedenen Java Versionen parallel unterhalb /usr/lib/jvm abgelegt. Mit dem kleinen Hilfsprogramm archlinux-java kann die Default JVM angezeigt und bestimmt werden. Ist diese nun zum Beispiel auf die aktuelle Version 11 eingestellt, dann läuft auch Eclipse bzw. die RCP und somit auch die Spring Tool Suite unter der JVM. Abhilfe schafft die .ini Datei im Root-Verzeichnis. Hier lässt sich u.a. die zu verwendende JVM angegeben.

[sp@Laptop ~]$ sudo archlinux-java status
Available Java environments:
  java-11-openjdk (default)
  java-8-graal
  java-8-openjdk

Der Parameter vm bestimmt den Pfad zur JVM. Dieser muss unbedingt vor dem Parameter vm-args angegeben werden!

-vm
/usr/lib/jvm/java-8-graal/bin/java
-vmargs
-Dosgi.requiredJavaVersion=1.8

In diesem Beispiel läuft Spring Tool Suite unter der GraalVM, obwohl die Default VM auf JDK 11 zeigt.