mir ist aufgefallen, dass alle Importer (v. a. PDF- und CSV-Importer) derzeit fest in den PP-Code eingebaut sind. Das macht es schwer, eigene/bank-spezifische Importer zu entwickeln, zu pflegen oder privat einzusetzen.
Idee:
Einen Extension-Point im Eclipse-Framework definieren, sodass Importer als eigenständige Plugins (Bundles) entwickelt und über „Dropins“ nachgeladen werden können.
Kern bleibt unverändert: bestehende Importer laufen wie bisher.
Drittentwickler könnten eigene (auch private) Importer schreiben, ohne den gesamten PP-Code zu forken.
Entkopplung: PP muss nicht jede Bank sofort aufnehmen.
Flexibilität für private/experimentelle Lösungen.
Bessere Wartbarkeit (Importer können in eigenem Repo gepflegt werden).
Offene Fragen:
API-Umfang: wie schlank/stabil soll das SPI sein?
Governance: sollen nur signierte/approved Plugins geladen werden?
Migration: welche Kern-Importer könnten als Referenz-Plugins dienen?
Frage an Andreas Buchen:
Hättest du Interesse, so eine Plugin-Architektur für Importer aufzunehmen?
Falls ja, könnte ich einen konkreteren RFC mit API-Vorschlag und Beispiel-Plugin ausarbeiten.
die Idee das aus zugliedern gibt es schon lange Andreas hatte dazu auch mal was gepostet finde das grade aber nicht. Damit er und Alex auch deinen Post sicher mit bekommt @AndreasB@Nirus
@Nirus hat auch schon vorgeschlagen, die PDF Importer zu entkoppeln. Vor allem könnte man dann schneller (vor jedem Import?) Änderungen veröffentlichen.
Was mir allerdings nicht klar ist: inwieweit kommt so ein Importer ohne UI aus? Denn Eclipse UI auf mehrere Plug-ins zu verteilen erfordert dann Kompatibilität. Und dann wird es langsamer und aufwändiger.
Ohne jetzt ein komplettes RFC zu machen, skizziert doch mal (gerne auch als pseudo code) wie Du Dir das Importer interface vorstellst und welchen Use case Du damit implementieren könntest.