Pentaho Data Integration: Systemdialog für Dateien per Plugin nachrüsten

Von / 17. September 2026 / Schreibe einen Kommentar / Apache Hop, Dateidialog, PDI, Pentaho Data integration, UX

Anwendungen, Open Source

Zwei Dateidialoge übereinander

Wer mit Pentaho Data Integration arbeitet (immer noch ein äußerst hilfreiches Tool), öffnet und speichert am Tag ein paar Dutzend Dateien. Genau an dieser Stelle hat Pentaho seit Version 8 einen eigenen Dateibrowser eingebaut, der in Spoon aufgeht, sobald man eine Transformation öffnet, “Speichern unter” wählt oder in einem Step auf “Durchsuchen” klickt. Der Dialog ist in Java nachgebaut und kennt vom Betriebssystem nichts außer den Laufwerksbuchstaben.

Das Problem: viele Klicks für wenig Ergebnis

Der Pentaho-Dialog zeigt links einen Baum und rechts eine Dateiliste. Um in einen tiefer liegenden Ordner zu kommen, klappt man Ebene für Ebene auf oder klickt sich rechts durch die Liste. Eine Pfadzeile gibt es, sie arbeitet aber nicht wie im Explorer: Der Dialog läuft die Baumebenen nach und wählt sie einzeln aus, was bei verschachtelten Pfaden und auf Netzlaufwerken dauert.

Was der Windows-Dialog von sich aus mitbringt, fehlt hier: Favoriten und Schnellzugriff, die Historie der letzten Ordner, die gewohnten Tastenkürzel, die Einbindung von Netzlaufwerken und OneDrive, dazu alle Kleinigkeiten, an die man sich über Jahre gewöhnt hat. Wenn die Projekte in verschachtelten Verzeichnissen liegen, kommen pro Datei mehrere Klicks zusammen, die im Systemdialog zwei gewesen wären.

Ärgerlich ist das vor allem deshalb, weil Spoon den Systemdialog weiterhin benutzt, nur eben an anderen Stellen. Im Quellcode von Version 9.4 finden sich rund 70 Java-Dateien, die den nativen Dialog von SWT aufrufen, also den Explorer-Dialog unter Windows und die GTK-Auswahl unter Linux. Für das Öffnen und Speichern von Transformationen und Jobs hat Pentaho diesen Weg verlassen und eine Einstellung, mit der man umschalten könnte, gibt es nicht. In den Optionen von Spoon steht dazu nichts, und im Code von 9.4 existiert kein Schalter, der den alten Weg zurückholt. Eine Begründung dafür ist mir nicht bekannt.

Die Lösung: ein kleines Plugin

PDI ruft für diese Dialoge einen Erweiterungspunkt namens SpoonOpenSaveNew auf. Bedient wird er normalerweise vom mitgelieferten Plugin file-open-save-new-plugin. Da Plugins in PDI austauschbar sind, lässt sich das auch anders bedienen, ohne PDI selbst anzufassen.

Genau das macht mein Plugin. Es nimmt den Pentaho-Dialog beim Start von Spoon aus der Aufrufliste, ohne ihn zu deinstallieren, und beantwortet den Erweiterungspunkt selbst. Damit kommt der Dateidialog des Betriebssystems: unter Windows den Explorer-Dialog, unter Linux die GTK-Auswahl, unter macOS den Cocoa-Dialog. Im Menü “Tools” sitzt ein Haken, mit dem man jederzeit zurück zum Pentaho-Dialog wechselt, ohne Spoon neu zu starten. Das ist auch nötig, denn VFS-Verbindungen zu S3 oder HDFS und der Zugriff auf ein Pentaho-Repository laufen weiter über den Pentaho-Dialog. Der Systemdialog kennt diese Quellen nicht.

Das Plugin besteht aus drei Java-Klassen, liegt unter der Apache License 2.0 und braucht nur eine JAR-Datei im Ordner plugins. Getestet habe ich es mit PDI 9.4.0.0-343 unter Windows 11. Quellcode und JAR liegen hier: https://codeberg.org/xanathon/PDI_OS_Save_Dialog

Hitachi Vantara tilgt die Community Edition von PDI aus dem Netz

Wer so ein Plugin baut, merkt schnell, in welchem Zustand die Community Edition von PDI ist. Für das Übersetzen braucht man die JAR-Dateien einer bestehenden Installation, weil sich PDI aus den Quellen nicht mehr bauen lässt. Der Quellcode selbst liegt weiter offen auf GitHub, das Repository pentaho-kettle ist aktiv und hat Tags bis 11.1 aus dem Mai 2026. Nur die Bausteine dazu bekommt man nicht. Alle Pentaho-POMs beziehen ihre Abhängigkeiten aus einem eigenen Maven-Repository, und das ist geschlossen: Die in den 9.4-POMs eingetragene Adresse repo.orl.eng.hitachivantara.com existiert nicht mehr, und die aktuelle Adresse repo.pentaho.com verlangt eine Anmeldung. Jede Abfrage endet dort mit HTTP 401, auch die nach Artefakten der Version 9.4. Dazu fehlen einzelne Build-Plugins von Pentaho komplett, unter anderem das license-helper-maven-plugin, das bei jedem Modul mitläuft. Fertige CE-Pakete gibt es auch nicht mehr: Im SourceForge-Projekt von Pentaho, über das die Community Edition jahrelang verteilt wurde, liegt heute genau eine Datei, ein PDF von Januar 2025. Wer PDI 9.4 noch braucht, findet es bei privaten Spiegeln.

Lizenzrechtlich ist das in Ordnung, und das ist der unangenehme Teil. Die Apache License 2.0 verpflichtet niemanden, weiterhin Quellcode oder Build-Infrastruktur zu veröffentlichen. Der Code von 9.4 bleibt Apache-lizenziert, und was Hitachi Vantara danach entwickelt, darf hinter einer Bezahlschranke bleiben. Beworben wird Pentaho aber weiter mit dem guten Namen eines Open-Source-Projekts, während die Gegenleistung wegfällt. Die Community hat jahrelang Plugins, Dokumentation und Antworten in Foren geliefert und steht nun vor einer Version, die sie nicht mehr selbst bauen kann. Dazu verschwindet ein großer Teil dieser Arbeit aus dem Netz. Das alte Wiki unter wiki.pentaho.com antwortet nur noch mit einem Fehler, forums.pentaho.com leitet auf die Startseite von pentaho.com um, und help.pentaho.com weist Zugriffe ab (geprüft im September 2026). Damit sind Anleitungen und Forenthreads weg, auf die jahrelang verlinkt wurde und die in vielen Fällen die einzige Dokumentation zu einem Step oder einer Fehlermeldung waren. Das ist keine Vernachlässigung. Wer eine Community Edition nicht mehr pflegen will, kann sie liegen lassen und die Community weiterarbeiten lassen. Einen Maven-Server abzuschalten, Build-Plugins nicht zu veröffentlichen und Wiki, Forum und Handbücher aus dem Netz zu nehmen, sind dagegen aktive Schritte. Das Ergebnis ist eine CE, die sich nicht mehr bauen lässt und deren Dokumentation fehlt. Wer das kostenlose Produkt unbenutzbar macht, schafft Bedarf für das kostenpflichtige.

Praktisch bedeutet das zwei Dinge. Erstens sollte man sich das Binary und die passenden Quellen der eingesetzten Version sichern, solange beides erreichbar ist. Zweitens lohnt der Blick auf Apache Hop, den Fork des Projekts, der bei der Apache Software Foundation liegt und seine Abhängigkeiten aus öffentlichen Quellen bezieht. Dass Hop bei der Bedienung so seine Eigenheiten hat und etliche UX-Entscheidungen abseits von Standards in meinen Augen fragwürdig sind, ist ein Thema für einen anderen Artikel. Ebenso, dass die Hop-Entwickler nach meinen Erfahrungen auf Wünsche und Fehlermeldungen bisweilen etwas … harsch reagieren.

Quellen

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Nach oben scrollen