Open bernhardbeyl opened 1 year ago
verstehe ich Sie richtig, dass Ihnen eine explizite "Bill of Materials" (BOM) wie z.B. hier dargestellt: https://reflectoring.io/maven-bom/ eine ausreichende Lösung darstellen würde?
Hallo! tl;dr; nein, leider nicht Warum Wir arbeiten mit sbt (nicht maven). Das nutzt Coursier/oder Ivy zum Aufloesen von Dependencies, nicht Maven. Daher wuerde uns ein BOM tatsaechlich ueberhaupt nicht weiterhelfen, denn meines Wissens supported Coursier BOMs nicht korrekt. Aber selbst bei Nutzung von Maven wuerden doch im Leaf-POM nur die Versionsangaben wegfallen, richtig ? Wenn im Library-POM dessen benoetigte Dependencies nicht spezifiziert sind - was hier die Ursache des Problems ist -, muss das Leaf-POM (also die Applikation) die immer noch angeben. Bei Vorliegen einer BOM halt nur ohne Versionsangabe und nur, wenn sie denn in der BOM explizit auftauchen. Und selbst dann wuerde noch die Versionsselektion verfaelscht. Man spart also nur dann was, wenn man durchgaengig maven nutzt. Alle anderen (Gradle?; Mill, SBT) muessen sich dann noch die korrekten Versionsnummern aus mehreren BOMS heraussuchen.
Die Version 1.5.0 des Kositvalidators in der in oeffentlichen Maven-Repositories publizierten Form spezifiziert die Laufzeitabhaengigkeiten nicht - anders als noch in der Version 1.4.2 und auch ansonsten ueblich. Wir moechten Sie bitten, sobald moeglich, eine Version zu publizieren, die ihre Laufzeitabhaengigkeiten im maven-POM.xml in handelsueblicher Weise mit spezifiziert.
Der Grund ist der, dessentwegen alle modernen Build-Systeme (nach ANT) das Handling transitiver Abhaengigkeiten der jeweiligen Library ueberlassen. Der alternative Ansatz haette zur Folge, dass die finale Applikation sich um alle Laufzeit-Dependencies aller genutzten Libraries kuemmern muesste. Das ist nicht nur unnoetig aufwendig sondern auch auf mittlere Sicht laum wartbar. Denn neben der Versionspflege muesste auch nachgehalten werden, welche Library von welchen anderen abhaengt um im Zweifelsfall Upgrades planbar implementieren zu koennen. Unsere Applikation hat - der IDE nach zu urteilen - ca 300 Dependencies. Der Aufwand, die versionstechnisch sauber und kompatibel zu halten verbietet sich.
Wir (Die Bitmarck, die Techniker Krankenkasse, die AOK und alle weiteren Dienstleister im Bereich DiGA) moechten Sie bitten, die vorgeschlagene Aenderung vorzunehmen oder uns Gelegenheit zu geben, die Problematik mit Ihnen zu diskutieren.