Hallo @AndreasB,
du hattest nach einer Skizze der Schnittstelle, einem konkreten Anwendungsfall und die Frage gefragt, wie das ohne UI funktionieren soll. Um das nicht nur auf dem Papier zu beantworten, habe ich es in meinem Fork ausprobiert:
Kurz gesagt: Es funktioniert, und die UI ist gar kein Problem.
Warum die UI kein Problem ist
Ein PDF-Importer liefert heute schon nur Buchungen zurück und hat selbst keine Oberfläche. Das Anzeigen und Bestätigen übernimmt der bestehende Import-Dialog. Ein Plugin muss also nichts weiter tun, als zusätzliche Importer bereitzustellen.
Die Schnittstelle
public interface ExtractorProvider {
List<Extractor> create(Client client);
}
@Component(service = ExtractorProvider.class)
public class MorganStanleyProvider implements ExtractorProvider {
public List<Extractor> create(Client client) {
return List.of(new MorganStanleyPDFExtractor(client));
}
}
Das Plugin meldet seinen Provider als OSGi-Service an. Bei jedem PDF-Import holt PP diese Services ab und probiert ihre Importer nach den eingebauten aus – der Core hat also immer Vorrang.
Wofür man das braucht
Der wichtigste Fall ist für mich ein Importer, der nur eine kleine Gruppe betrifft – etwa der Morgan-Stanley-Aktienplan, den nur Mitarbeiter eines einzelnen Unternehmens brauchen. So ein Importer ließe sich innerhalb der Gruppe verteilen, ohne dass ihr ihn pflegen müsst. Ähnlich sieht es bei Dokumenten aus, die sich nicht sinnvoll anonymisieren lassen, bei schnellen Korrekturen nach Layout-Änderungen einer Bank und bei neuen Importern, die man erst mal ein paar Leuten zum Testen gibt, bevor sie per PR in den Core wandern.
Ein- und Ausschalten
Eingebaute Importer habe ich „Stable“ genannt, Plugin-Importer „Incubator“. In den Einstellungen gibt es eine neue Seite „Importer“, auf der man Plugins und einzelne Importer ein- und ausschaltet – das wirkt sofort, ohne Neustart. Einen Incubator-Importer kann man außerdem als „bevorzugt“ markieren, dann wird er vor dem eingebauten probiert. So lässt sich eine korrigierte Fassung testen und bei Bedarf mit einem Klick wieder abschalten. Plugins werden grundsätzlich nur geladen, wenn man das ausdrücklich aktiviert.
Versionierung
Nur das neue API-Paket bekommt eine eigene Version (1.0.0), unabhängig von der PP-Version. Ein Plugin gibt an, mit welchen Versionen es zurechtkommt. Passt das nicht, lädt PP das Plugin einfach nicht und läuft normal weiter.
Testen
Plugin-Importer lassen sich genauso testen wie die eingebauten: PDF-Debug-Text als Fixture, dazu die bekannten Matcher. OSGi braucht es dafür nicht. Zusätzlich schlage ich einen Negativtest vor: Ein Plugin-Importer darf keines der rund 2.700 Test-Dokumente der eingebauten Importer erkennen. Weil der erste Treffer gewinnt, würde ein zu großzügiger Importer sonst Dokumente anderer Banken an sich ziehen. Der Morgan-Stanley-Importer besteht diesen Test – er erkennt keines der 2.684 Dokumente.
Was sich beim Ausprobieren gezeigt hat
Das Morgan-Stanley-Plugin wird aus einem Ordner im Arbeitsbereich geladen, importiert die Release Reports und lässt sich im laufenden Betrieb abschalten. Alle bestehenden Tests von PP sind grün.
Dabei sind zwei Hürden aufgefallen. Erstens ist die PDF-DSL (PDFParser, DocumentType, Block usw.) nur innerhalb des Pakets sichtbar. Ein Plugin kommt deshalb nur über einen Umweg (ein Fragment des Core-Bundles) an sie heran und ist damit an genau eine PP-Version gebunden. Zweitens liegen die Test-Helfer (ExtractorMatchers usw.) im internen Test-Bundle. Wer ein Plugin schreibt, kommt an sie nicht heran.
Meine Fragen an euch
- Könntet ihr euch vorstellen, die PDF-DSL als versionierte API zu öffnen? Das wäre die Grundlage für stabile Plugins.
- Sollen Plugins aus einem eigenen Ordner geladen werden (so habe ich es gemacht) oder über den p2-Mechanismus?
- Reicht ein ausdrückliches Einschalten, oder sollen Plugins signiert sein?
- Wäre es in Ordnung, die Test-Helfer in das öffentliche
name.abuchen.portfolio.junit zu verschieben und dort auch den Negativtest anzubieten?
Wenn euch die Richtung zusagt, würde ich zuerst nur die Schnittstelle und die Einstellungsseite als PR einreichen – die DSL und die Test-Helfer getrennt davon.