Materialdrawer: [Funktionsanfrage] Kotlin DSL

@AllanWang oh das ist eigentlich etwas, worüber wir nachgedacht haben, hatten nur noch keine Zeit.

Die Idee, mit @zsmb13 zusammenzuarbeiten,

@zsmb13 bitte lassen Sie mich wissen, ob es in Ordnung wäre, Ihr tolles DSL zu integrieren?

Dies ist sicherlich ein interessanter Vorschlag.

Ich betreue die DSL-Bibliothek immer noch aktiv. Es gab eine Weile nicht viel zu tun, um mit der Basisbibliothek Schritt zu halten, aber ich habe bereits damit begonnen, Dinge für die Version 7.0.0 zu aktualisieren.

Ich wäre natürlich begeistert, wenn meine Bibliothek irgendwie "offiziell" gemacht würde (wenn es eine Organisation für diese Bibliotheken gäbe, könnte sie dorthin verschoben werden, aber es gibt keine) und würde mehr Benutzer und möglicherweise Mitwirkende sehen see .

Ich bin mir nicht sicher, ob es mit der Basisbibliothek gebündelt werden sollte, selbst wenn diese auf Kotlin umgestaltet wurde. Es bietet eine völlig neue Benutzeroberfläche für die Nutzung der Bibliothek. Es muss auch nicht gebündelt werden, um zu funktionieren, da es nur auf Erweiterungen angewiesen ist. Ich denke, es wäre sehr sinnvoll, dies immer noch als separates Artefakt zu haben, das für Benutzer optional ist, insbesondere wenn jemand die Basisbibliothek aus einer Java-Codebasis verwendet. Sie möchten nicht all diese zusätzlichen Funktionen einbeziehen, die sie nie verwenden werden.

Dann ist da natürlich die Frage der Namensgebung. MaterialDrawerKt macht nicht mehr viel Sinn, wenn die Basisbibliothek auch Kotlin ist (wenn ich das nur erwartet habe, aber na ja), stattdessen sollte MaterialDrawer-DSL oder so ähnlich sein. Das Umbenennen ist ein bedeutendes Unterfangen, das ich nicht auf die leichte Schulter nehmen würde. Besonders wenn das Artefakt umbenannt wird, befürchte ich, dass viele Leute von Updates abgeschnitten werden, die sie sonst erhalten würden - es gibt keine gute Möglichkeit, alle Benutzer über die Änderungen zu informieren.

TL; DR:

• Ich denke, die DSL sollte immer noch separat gebündelt werden, da die Kernbibliothek diese völlig andere API nicht enthalten muss. Insbesondere Java-Benutzer sollten nicht all diesen Code einlesen müssen.
• Der Name der DSL-Bibliothek macht keinen Sinn mehr, was traurig, aber auch scheinbar sehr schwer zu reparieren ist.

Ich bin offen für alle Gedanken & Meinungen dazu, sollte eine spannende Diskussion werden!

@zsmb13 es ist wirklich toll zu sehen, dass Sie die Bibliothek immer noch pflegen.

• Aufgrund der aktuellen Details habe ich mir überlegt, die DSL als neues Modul in das Projekt aufzunehmen. und es ist ein neues Artefakt neben der Kernbibliothek, die das DSL bereitstellt.
• Sein Quellcode würde direkt neben dem Kern in diesem Repository leben, was ihn für die Benutzer des MaterialDrawers vollständig sichtbar macht.
• Ich würde Sie gerne als Mitwirkenden zu diesem Repository hinzufügen, damit Sie weiterhin direkt warten und möglicherweise Pull-Requests ausführen können oder was am besten passt.

Sie haben Angst, dass Leute, die Ihre Bibliothek benutzen, abgeschnitten werden. Ich würde annehmen, da der MaterialDrawer die Unterabhängigkeit Ihres Projekts ist, überprüfen die Leute dieses Repository regelmäßig, da es die Kernbibliothek enthält.

Wenn die Umbenennung von Paketen unvermeidlich ist, wäre es meiner Meinung nach am besten, alles mit einer Warnung abzulehnen, die auf die neue Quelle verweist. Das Aktualisieren würde bedeuten, die Importe zu ändern, wenn sich der dsl nicht ändert.

Ich denke, ein zusätzliches Modul für Erweiterungen wäre großartig, angesichts der offiziellen Unterstützung und der besseren Sichtbarkeit.
Das Problem wird ein Eigentümerwechsel, den ich nicht kommentieren kann.

Die anderen Hauptabhängigkeiten wie FastAdapter und Iconics benötigen möglicherweise ebenfalls dsl (oder zumindest einige Kotlin-Verbesserungen), aber es gibt keine wirklich gute Organisation, um sie zu bündeln, außer dass sie alle von Mike Penz geleitet werden

Sein Quellcode würde direkt neben dem Kern in diesem Repository leben, was ihn für die Benutzer des MaterialDrawers vollständig sichtbar macht.

Dies macht Sinn, es könnte in diesem Repo als separates Modul und daher als separates Artefakt leben :+1:

Ich würde Sie gerne als Mitwirkenden zu diesem Repository hinzufügen, damit Sie weiterhin direkt warten und möglicherweise Pull-Requests ausführen können oder was am besten passt.

Ich würde auf jeden Fall gerne der Hauptverwalter dieses Moduls bleiben und so direkt wie möglich dazu beitragen. Dies ist mein bisher größter Anspruch auf Ruhm in der Open-Source-Community, daher ist es ein sehr, sehr wichtiges Projekt für mich. Ich nehme an, Sie möchten die Gruppen-ID so ändern, dass sie mit der der Basisbibliothek übereinstimmt, anstatt co.zsmb ? Wie sieht es mit dem Paketnamen aus? Es wäre schön, wenn man beides behalten könnte, aber ich denke, ich bin auch bereit, sie bei Bedarf aufzugeben und einfach zufrieden zu sein, dass meine Arbeit mehr Menschen erreicht.

Ich würde annehmen, da der MaterialDrawer die Unterabhängigkeit Ihres Projekts ist, überprüfen die Leute dieses Repository regelmäßig, da es die Kernbibliothek enthält.

Ich bin mir nicht sicher, ob die Leute sogar die Seite meines Repositorys überprüfen. Ich kann mir viele Leute vorstellen, die die Abhängigkeit einmal hinzufügen und sie dann nur basierend auf IDE-Hinweisen aktualisieren.

Wenn die Umbenennung von Paketen unvermeidlich ist, wäre es meiner Meinung nach am besten, alles mit einer Warnung abzulehnen, die auf die neue Quelle verweist. Das Aktualisieren würde bedeuten, die Importe zu ändern, wenn sich der dsl nicht ändert.

Ich denke, dies wäre der bestmögliche Ansatz, ich kenne leider keine Möglichkeit, Personen nach einer Änderung der Koordinaten umzuleiten. Ich könnte also eine gefälschte Version veröffentlichen, die viele veraltete Meldungen enthält und vielleicht auch einige -DEPRECATED Postfix im Versionsnamen hat.

Abgesehen von der koordinierten Migration ist eine weitere technische Überlegung, dass ich meine Bibliothek auf MavenCentral veröffentlicht habe, und ich würde es sehr bevorzugen, wenn sie nach Möglichkeit weiterhin von diesem Repository verfügbar wäre - ich habe sogar einen Artikel unter geschrieben Ein Punkt zu Problemen, mit denen ich persönlich bei der Verwendung von jcenter konfrontiert war. Sie konnten es natürlich nicht unter meiner Gruppen-ID veröffentlichen, da ich meine eigenen GPG-Schlüssel zum Signieren der Artefakte verwendet habe, aber wenn die Gruppen-ID geändert würde, wäre es möglich.

Dies ist kein Problem, wenn Sie alle diese Bibliotheken nur über jcenter veröffentlichen möchten, aber ich würde den MavenCentral-Ansatz wirklich empfehlen (obwohl er zugegebenermaßen sehr mühsam ist) und wäre glücklicher, wenn meine Arbeit dort verteilt würde.

Auf die ersten Themen werde ich später eine lange Antwort geben.

Bezogen auf Ihre Kommentare zu MavenCentral . Ich stimme absolut zu. Ich veröffentliche meine Bibliotheken auch weiterhin in Maven Central und signiere meine Bibliotheken immer noch mit einem GPG-Schlüssel, um ihre Integrität zu gewährleisten. Denn meiner Meinung nach ist es sehr wichtig, diese Art der Überprüfung zu haben, dass das Artefakt aus einer vertrauenswürdigen Quelle veröffentlicht wurde.
Ich habe die Option gerade über jCenter hinzugefügt, da sie eine schnellere und direktere Möglichkeit bietet, Updates bereitzustellen. Die Aktualisierung von maven central nimmt manchmal einige Zeit in Anspruch. Auch die Synchronisierung von mavenCentral zu jCenter bereitete den Leuten manchmal Probleme. Also habe ich mich gerade entschieden, auf beiden zu veröffentlichen. und habe die Artefakte auf jcenter mit der richtigen Beschreibung und so. :)

Ah, okay, das sind dann tolle Neuigkeiten. Ich wusste nie, dass ich auch die Basisbibliothek von MavenCentral abrufen kann!

Im Allgemeinen würde ich also denken, dass es am besten wäre, das Artefakt in derselben Gruppe zu hosten, da es üblich ist (zumindest tue ich das regelmäßig), um Artefakte aus derselben Gruppe zu finden, um zu sehen, ob eine Bibliothek andere Module hat oder so. Es macht es auch einfacher für die Leute zu verstehen, dass es zusammenarbeitet.
Zugehöriger Paketname. Im Allgemeinen würde ich es vorziehen, es wie die Hauptbibliothek zu verwenden, nur um es für die Leute verständlich zu machen, was sie tatsächlich in ihre Quelldateien importieren.

Aber aufgrund der Reichweite Ihrer Bibliothek und der Tatsache, dass viele Leute sie bereits verwenden, könnten wir der Einfachheit halber für das Upgrade den Paketnamen für die vorhandenen Klassen beibehalten und langsam mit neuen Klassen auf den Paketnamen der Hauptbibliotheken migrieren .
Eine Sache, die wir auf jeden Fall tun sollten, ist in den Quelldateien Ihrer DSL einen richtigen Lizenz-Header mit Ihrem Namen zu haben, damit diese Sichtbarkeit gewährleistet ist. Credits dafür auch direkt in der README hinzufügen

Verbunden mit der Deprecation-Phase. Mein Gefühl wäre, dass es ausreichen würde, einen Hinweis im Repo zu haben und Leute zu verlinken und ein Update mit einer Deprecation für die Hauptklasse durchzuführen, um zu bemerken, dass Dinge verschoben wurden und dass die Abhängigkeit jetzt woanders beibehalten wird.
Es gibt irgendwie die Möglichkeit auf Maven Central anzugeben, dass eine Bibliothek in eine andere Gruppe verschoben wurde, aber ich habe keine Ahnung, wie das geht :D

(nur ein Kopf hoch)
Ich schätze, diese Diskussion wird noch etwas länger andauern, also werde ich höchstwahrscheinlich v7.0.0 veröffentlichen, ohne noch eine DSL einzubinden.

Ich denke, wir haben die meisten Dinge zum Zusammenführen herausgefunden, aber ich muss noch die DSL für die neue Basisbibliotheksversion aktualisieren. Wer demnächst 7.0.0 veröffentlichen will, sollte das alleine machen, da ich mit dem DSL etwas im Rückstand bin.

Wenn ich damit fertig bin, können wir die Details, wie wir es in dieses Repo verschieben, schnell herausfinden. Es scheint keine blockierenden technischen Probleme mehr zu geben, wir müssen nur ein paar kleine Details ausarbeiten, wahrscheinlich über Chat oder so.

@zsmb13 hört sich gut an.

btw. Ich hatte eine andere Idee, die eine mögliche Variante sein könnte, die wir gehen könnten.

Sie behalten Ihren Repository- und Paketnamen. aber wir passen das Modul so an, dass es der Modulstruktur folgt, die für die Freigabe als Teil der Hauptbibliothek erforderlich ist. Fügen Sie es dann als git-Submodul in das Haupt-Repository ein. Danach veröffentlichen wir es unter demselben Maven-Paket. und lassen Sie die Haupt-README-Datei ordnungsgemäß dokumentieren und die Benutzer informieren.

Aber all dies können wir in einem Chat besprechen, wie Sie es vorgeschlagen haben.

Irgendwelche Aktualisierungen? Mit den jüngsten Breaking Changes aufgrund anderer Bibliotheksaktualisierungen kann der dsl nicht verwendet werden, bis auch er einen Versionsstoß hat

Lustige Geschichte. @zsmb13 und ich haben uns diese Woche tatsächlich auf der kotlinconf getroffen 😂

Schließen Sie dies bei Inaktivität. Außerdem verwendet v8 eine neue API, die kotlin-freundlicher ist und die kotlin-DSL im Grunde überflüssig machen sollte. :)

Offen für Verbesserungen.

Vielen Dank für die tolle Diskussion hier.

Auch in dieser Anmerkung. Herzlichen Glückwunsch @zsmb13, dass

Zugegeben, ich habe die Kt-Wrapper-Bibliothek nach 7.x nicht aktualisiert, weil ich nicht sehe, wie sie viel besser funktionieren könnte als die reguläre Bibliothek. Außerdem konnte es jetzt nicht mehr so ​​nahtlos sein, da Sie die XML-Setup-Teile für die Verwendung der Bibliothek sowieso ausführen müssten.