Auflistung der Dependencies samt Lizenz #1487
Conversation
modified: build.gradle modified: dependencies.gradle new file: license-report-example.md
|
@cagix wie versprochen, schon einmal der pull-request. |
|
@tgrothe 🙏 wow, der findet aber echt viel 🫣 kann man das so einstellen, dass er nur die runtime-sachen findet, also die sachen, die auch ins jar gehen? |
hm, ich lese mir mal die plugin docs dazu durch, dauert aber ein wenig. |
keinen stress, das läuft ja nicht weg ... |
modified: .gitignore modified: build.gradle renamed: license-report-example.md -> licenses/third-party-libs.md
schau dir das nun einmal an, es war schon auf "runtime libs" mit |
|
was genau sehe ich jetzt? |
Die Ausgabe ist im Prinzip gleich belieben. Aber ich habe die default Konfigurationsoptionen hinzugefügt. Die Konfiguration war schon auf |
|
d.h. es gibt eigentlich nichts für mich zu sehen. wenn du die übersicht anschaust, dann taucht dort junit auf. das sollte aber nichts mit dem jar-file zu tun haben. |
man kann glaube ich auch bestimmte dependencies aus- oder einschließen, mit: wobei ich nicht weiß, was mit "bom" gemeint ist. |
|
bill of materials |
jedenfalls, auch wenn man |
|
@tgrothe naja, es kann mehrere ursachen geben:
(1) was ändert sich, wenn du (2) gibt es im bug-tracker vom plugin irgendwelche hinweise? gibt es auf stackoverflow irgendwelche hinweise? (3) wie haben wir junit bei uns eingebunden, ist das am ende tatsächlich im starter.jar drin? |
Keine Änderung:
Mit Zu JUnit (4) und dem license plugin hab ich nix in der Plugin-Beschreibung und auf Stack Overflow gefunden. Es gibt aber ein Issue dazu, dass JUnit 5 nicht im Report enthalten war: jk1/Gradle-License-Report#201 , also quasi der genau umgedrehte Fall.
Ja, das und Mockito ist mit in der Starter.jar enthalten: Wir könnten versuchen, die dependencies oder den jar task anzupassen, dass JUnit nicht mehr mit "eingepackt" wird. |
…er.jar and licenses report: modified: build.gradle modified: game/build.gradle modified: licenses/third-party-libs.md
F*ck. Dann ist unsere Gradle-Konfiguration tatsächlich noch kaputt. JUnit/Mockito haben im Starter.jar nix zu suchen 👀 |
Mit ccc14bc sollte es jetzt eigentlich passen. JUnit/Mockito sollten hinterher nicht mehr in der jar sein und tauchen jetzt auch nicht mehr im Report auf. :) |
zum lokalen testen ist das ok - aber das gehört in einen eigenen pr. das ist etwas, was ich sehen will und ggf. zurückdrehen möchte, also nix, was ich in einem feature-pr einfach mal so nebenbei mache/verstecke. die diskussion hatten wir nun schon ein paar mal. edit: sorry, ich habe vorhin versehentlich deinen kommentar editiert, statt ein "quote-reply" zu machen :/ |
Aber dieser PR steht doch noch auf Draft. Ich kann später einen neuen Feature-Pull-Request öffnen, der dann zuerst gemerged werden sollte, wenn das ok wäre? |
modified: game/build.gradle (reset to master)
draft: ich sag ja, zum ausprobieren finde ich es ok. nur will ich so eine änderung nicht am ende hier in diesem pr haben :) und ja, den anderen pr müsste man dann vor diesem hier mergen... ich frage mich grad, warum ich junit damals in die game-build.gradle und dann noch als "api" gepackt hatte 🫣 ... ich kann mich nur erinnern, dass es mit dem üblichen "testImpl" irgendwie probleme gab. hmmm. |
Das ist wieder so ein Gradle-Doc-Kuddelmuddel. Das
|
|
hmm, aber da wir ja eh testImpl brauchen, ist das doch kein problem? |
nein, kein problem ... :) Potest manere quod est. :D |
Die Testabhängigkeiten wurden bislang im `build.gradle` von Sub-Projekt `game` als `api` definiert, um transitiv auch in `dungeon` etc. verfügbar zu sein und dort nicht noch einmal konfiguriert werden zu müssen. Dadurch landen die JUnit- und Mockito-Bibliotheken aber unnötig im `Starter.jar` für den Dungeon (Probleme: Größe des JARs, Lizenzen der eingepackten Bibliotheken). (siehe auch Diskussion in #1487) Zusätzlich haben bisher nur zwei der Sub-Projekte auch wirklich Tests: `game` und `dungeon`, die anderen benötigen die JUnit- und Mockito-Abhängigkeiten nicht. Dieser PR korrigiert dies: - Setze die Konfiguration für die Test-Dependencies auf `testImplementation`, damit die JUnit- und Mockito-Abhängigkeiten nicht im JAR landen (vgl. https://docs.gradle.org/current/userguide/java_plugin.html#sec:java_plugin_and_dependency_management) - Füge Dependencies für JUnit und Mockito auch in die lokale `build.gradle` des Sub-Projekts `dungeon` ein --------- Co-authored-by: Carsten Gips <cagix@hsbi.de>
|
@cagix ich würde hier gerne weitermachen. soll der (beispiel-) license report eingecheckt werden? soll dieser von der ci generiert werden? wenn ja, wann? immer, wenn sich eine gradle build ändert? also, neuer pull request && änderung an einer build.gradle -> neuer report? |
wirklich brauchen tun wir das hier in diesem repo nicht. das wird erst relevant, wenn wir ein fertiges artefakt irgendwo anbieten, welches bibliotheken von drittanbietern (physisch) enthält => starter.jar bzw. das starter-repo (siehe beschreibung in #1478). oder andersherum: der bericht plus die lizenzfiles sollten immer zusammen mit dem starter.jar erzeugt/zusammengesammelt werden, aber nicht hier in diesem repo eingecheckt werden. das muss man dann beim rüberkopieren des starter.jar in das starter-repo entsprechend mit kopieren und dort einchecken. zusätzlich sollte das starter.jar den bericht und die lizenzfiles mit enthalten (sicherheitshalber). |
alles klar, dann ist aus meiner sicht hier zurzeit nix zun tun. die starter.jar generieren wir ja manuell bzw. über einen gradle task. ... ich füge mal das later label hinzu. |
@tgrothe ich verstehe dich grad nicht. ist denn das problem gelöst? wenn ja, worin besteht die lösung? wenn nein, was soll "later" passieren, was nicht bereits auch jetzt passieren kann? |
ich weiß momentan nicht, was hier noch zu tun wäre. der bericht kann ja (zurzeit manuell) erstellt werden. soll dieser automatisch in die jar gelegt werden, wenn der starter jar tasks angestoßen wird? |
@tgrothe ich glaube, das ist exakt das, was ich im kommentar obendrüber dazu geschrieben hatte?! |
oh, und dann wie immer: bitte eine vernünftige beschreibung dessen, was hier passiert, in den ersten kommentar packen. |
|
ok, ich bin hier dran, aber es dauert noch etwas. das plugin verwendet anscheinend den gradle cache und erstellt nicht jedes mal den report. deshalb muss der gradle cache geleert werden. hab später wieder zeit hierfür. gradle ist merkwürdig. |
🤣 |
modified: build.gradle modified: dungeon/build.gradle
modified: dungeon/build.gradle Examples added: new file: 1.md new file: 2.md new file: 3.md new file: 4.md new file: 5.md new file: 6.md new file: 7.md new file: 8.md new file: 9_current.md
|
@tgrothe Danke. Hast Du mal geschaut, ob das wirklich alle Libs sind, die im JAR landen? Also fehlt da noch was? Oder findet das Plugin irgendwas zu viel?
An sich müsste ja als "dungeon" reichen, da vom Classpath her dort auch alles aus "game" gezogen wird. Wenn ich das richtig sehe, möchten Apache und BSD den Lizenztext auch vorgehalten haben. Also nicht nur eine Datei mit dem Namen und dem Link drin, sondern auch den konkreten Text. Kriegen wir das irgendwie hin? |
So auf die Schnelle ... ich glaube net.
See https://www.apache.org/licenses/LICENSE-2.0 Also eine Lizenzdatei hätten wir, und in dieser ist doch auch eine Referenz/ein Link enthalten ...
Ich glaube, es ist alles dabei und landet im jar. Ich kann aber nur vermuten, dass das stimmt. 75 % 🤪 |
Muss ja nicht schnell sein. Aber es muss - wenn ich auf die Lizenz klicke, steht da unter (4a) eindeutig, dass man eine Kopie der Lizenz mit verteilen muss. Und (4d) will dann darüber hinaus noch irgendwelche "Notice"-Files sehen (sofern es im ursprünglichen Projekt welche gibt) - hier ist mir aber nicht klar, ob sich das auch auf das Verteilen von Binärklumpen bezieht oder nur, wenn Du die Sourcen nochmal auslieferst. Edit: Vielleicht lässt sich das in Groovy/Gradle halbwegs vernünftig ausdrücken und damit automatisieren. Vielleicht kann das Plugin das aber auch schon, anderen geht es ja genau wie uns. Und es reicht, hier zunächst mal ne grobe Skizze zu machen - damit kann ich abschätzen, ob man das am Ende doch lieber manuell machen möchte. Man muss halt "nur" beim Hinzufügen neuer Dependencies die Augen offen halten und ab und an mal die alte generierte Liste gegen eine frische generierte Liste halten, falls sich innerhalb der Dependencies mal was ändert.
Wo genau ist denn diese Datei? Ich habe bisher immer nur eine Summary gesehen, wo der Name und ein Link drin waren. Das ist prima und gut, aber eben dann nicht ganz ausreichend.
An der Stelle kommst Du in Deiner Rolle als SHK ins Spiel: Bitte analysiere die im Starter.jar enthaltenen fremden Projekte und vergleiche das mit der erzeugten Summary. 75% ist leider nicht gut genug. Und ja: Das muss nicht jetzt sofort sein, das kannst Du gern über ein paar Wochen strecken - so wie es die Zeit erlaubt. |
|
@cagix okay, danke für deine antwort. ich schaue mir die sache in ruhe noch einmal an. eine andere sache wäre, das hat aber nicht direkt mit diesem pr zu tun, ob man die das mehr oder weniger nur laut gedacht (hoffentlich nicht abwegig), zu dem ich ein issue anlegen könnte. |
@tgrothe ich meine, darüber hätte @AMatutat nachgedacht. allerdings sind mir die gründe für das extra repo grad auch nicht mehr transparent. an sich finde ich das extra starter-repo etwas schöner, weil hier wirklich nur auf den einen use-case bezug genommen wird (nutzung durch lehrende fern der informatik), während hier im hauptrepo eine fast erschlagende fülle an (immer noch nicht besonders gut dargestellten) informationen direkt auf der startseite wartet - das ist sicher nix für außenstehende. dennoch, das problem mit den lizenz-dateien besteht ja so oder so. |
|
Da ich aktiv gementiont wurde:
Soweit ich mich erinnere, war genau das der Grund. |
Dieser PR fügt beim Generieren der
Starter.jareinen Lizenz-Report zum.jar-File hinzu.closes #1478