Package umbenennen von org.kapott in org.hbci4j

[willuhn]

Das eigentliche Umbenennen ist nicht das Problem - das machen die Refactoring-Werkzeuge der IDEs ja automatisch.
Damit würden aber alle Integrationen kaputt gemacht werden, die HBCI4Java verwenden. Es gibt etliche Klassen, die über die HBCI4Java API von anderen Projekten verwendet werden. Das sind z.B.:

org.kapott.hbci.manager.HBCIUtils
org.kapott.hbci.passport.HBCIPassport
org.kapott.hbci.GV.HBCIJob
org.kapott.hbci.callback.HBCICallback

Aber auch unzählige weitere.

Ich habe das Ticket eher als Platzhalter erstellt, damit keiner auf die Idee kommt, mal eben per IDE-Refactoring das Package umzubenennen und das Ganze dann als Pull-Request einzureichen. Denn das ist der kleinste Teil der Arbeit. HBCI4Java wird von vielen anderen Projekten (oft in der Öffentlichkeit gar nicht bekannte) verwendet, die dann alle angepasst werden müssten. Ich bin mir nicht sicher, ob es überhaupt sinnvoll ist, das umzubenennen, weil es abgesehen von der Ästhetik keinen Mehrwert hat aber für viele Beteiligte eine Menge Arbeit bedeuten würde.

[carlbecker]

Package umbenennen ist halt am API inkompatibel. Deshalb besser nicht.

[willuhn]

Ich habe testweise mal einen Branch 5.0 erstellt, in dem das Package von "org.kapott" in "org.hbci4java" umbenannt wurde. Außerdem habe ich dort auch sämtlichen alten C-Code (hier insb. den in C geschriebenen Support für DDV-Chipkarten per CTAPI und SIZ-RDH-Schlüsseldateien) und veraltete Dokumentation entfernt.

[kicktipp]

Ich finde das gut. Je aufgeräumter die Codebasis ist, desto besser. Die Umstellung für einen Developer ist ja wirklich easy.

Das JAR heißt am Ende hbci4j-core-VERSION.jar, weil es so in settings.gradle festgelegt ist. Sollte man das dann auch hbci4java-VERSION.jar nennen? Oder gibt es das hbci4j-server Projekt noch? Wenn ja, dann würde ich die Pakete in org.hbci4java.core umbenennen. Das hätte auch die Möglichkeit, zusätzliche Pakete später zu erstellen. Zumindets sollte man darüber mal nachdenken, damit man nicht in Zukunft nochmal was umbenennen muss.

[willuhn]

Das Server-Paket gibt es nicht mehr. Ich habe im 5.0 Branch jetzt aber gerade alle Packages umbenannt und habe noch arge Probleme, die existierenden Passports damit zu laden, da hierbei Java-Objekte serialisiert wurden. Das Deserialisieren geht jetzt nicht mehr, weil die Package-Namen nicht mehr passen. Meine gerade implementierte Migrationsstrategie funktioinert auch nicht. Bevor ich mich weiteren Aufräumaktionen widme, muss das erstmal funktionieren.

Das ist übrigens genau das, was ich befürchtet hatte und was das Umbenennen des Packages eben nicht trivial macht.

[carlbecker]

Aufräumen der Codebasis ist schön und gut, aber bitte nicht auf Kosten der Kompatibilität. Es stört doch keinen, wenn der Name org.kapott bis in alle Ewigkeit weiterlebt.

[willuhn]

Deswegen ja meine Arbeit an der automatischen Migration, um die Kompatibilität sicherzustellen. Es ist erstmal ein Experiment. Deswegen in einem extra Branch. Wenn es nicht vernünftig funktioniert, werde ich das alte Package belassen.

[willuhn]

Das Deserialisieren geht jetzt nicht mehr, weil die Package-Namen nicht mehr passen. Meine gerade implementierte Migrationsstrategie funktioinert auch nicht.

Funktioniert jetzt. Ich habe eine neue interne Versionsnummer des internen Speicher-Formats für die Passport-Dateien eingeführt. Die Passports werden automatisch und on-the-fly migriert. Der neue Unit-Test https://github.com/hbci4j/hbci4java/blob/5.0/src/test/java/org/hbci4java/hbci/passport/storage/TestPassportStorage.java validiert das.

Ich lasse die Version mit dem neuen Package-Namen mal noch im Branch "5.0" und überlege, wie man den Rollout machen könnte, ohne existierende Integrationen reihenweise zu zerbrechen. Man könnte übergangsweise sogar beide Versionen (4.x und 5.x) parallel im Classpath haben.

[kicktipp]

@willuhn is King of HBCI