Änderung jar Datei herausfinden.

  • Hey,


    ich habe eine Frage:

    ich bin als Developer-Leitung Administrator eines Minecraft-Servers. Nun möchte ich bei neuen Devs immer kontrollieren das die keine scheiße einbauen.

    Das decompilen des Plugins ist eh kein Problem, nur wollte ich jetzt wissen ob es ein Programm gibt, das Änderungen an einer jar Datei sofort anzeigt.

    Kennt jemand so ein Programm bzw. hat jemand eine Lösung dafür, weil ich mir nicht jede Klasse jedes mall einzel ansehen möchte.


    MFG CheeseTastisch

  • Interessanter Ansatz den du da verfolgst.

    Soweit ich weiß gibt es für dein Problem nicht direkt eine Lösung,

    aber für dein größeres Vorhaben einen besseren Ansatz.

    Generell solltet ihr im Team nicht nach dem Prinzip arbeiten, dass jeder einfach mal macht und nur die Jar Dateien ausgetauscht werden.

    Sinnvoller wäre hier eine Versionsverwaltung wie z.B. Git. Dort können auch Änderungen genau verfolgt werden und es ist sogar eine gute Zusammenarbeit an ein und demselben Projekt möglich.

    Für ein vertrauensbasiertes Miteinander dürfte das reichen. Natürlich kann bei einem Zugriff aufs Dateisystem seitens der Entwickler nicht gewährleistet werden,

    dass sie keinen Unsinn anstellen. Das kann es nach deinem Ansatz aber auch nicht wirklich, da z.B. auch andere Dateien manipuliert werden könnten.

    Die Lösung wäre hier, den Entwicklern keine Rechte auf das Dateisystem zu geben und stattdessen eine CI/CD Pipeline um die Versionsverwaltung zu bauen.

    Sprich, wenn neue Änderungen von den Entwicklern hochgeladen werden, wird auf einem Server der Quellcode automatisch zu einer Jar gebaut und auf dem System platziert.

    So können über die Versionsverwaltung alle Änderungen verfolgt werden, die je auf dem System waren.

    Möchte man einen Schritt weitergehen, lässt es sich über sog. Pull Requests einrichten, dass alle Änderungen erst von dir abgesegnet werden müssen, bevor sie auf dem System ausgespielt werden.


    Das alles ist natürlich ein etwas größerer Einrichtungsaufwand, auf lange Sicht ist es aber ein viel angenehmerer Arbeitsworkflow

  • Erst einmal danke für deine Antwort, jedoch gibt es daran einige Probleme:


    1.) Bei einigen Developern läuft Git nicht, desweiteren würde ich auch Persönlich eher ungerne Git nutzen.

    2.) Auch bei mir benötigen Developer keine Zugriff auf den gesamten Server, Devs schicken mir die JAR-Datei ich kontrolliere ob Sicherheitsrisiken(Forc-OP, CloudNet-PermissionProvider,...) eingebaut wurden. Sollte dies nicht der Fall sein, ziehe ich das Plugin auf den Server.

    3.) Wenn man einfach macht, dass wenn ein Projekt auf Git hochgeladen wird und es zu einer JAR-Compield, ist das Problem das Developer wieder jegliche Sicherheitslücken sofort daraufspielen. Da bring es mir auch nix wenn ich danach sehe dass der was eingebaut hat.


    Wie gesagt, meine Frage war nicht wie man den Pluginaustausch,... grundsätzlich lösen kann, sonder ob es ein Programm gibt, mit dem Ich zwei Jar Dateien auf unterschied abgleichen kann. Hintergrund ist dabei, dass ich nicht jedes mall das gesamte Plugin durchgehen möchte und nach Sicherheitslücken zu suchen.


    MFG CheeseTastisch

  • Mir ist klar, dass deine Frage nicht der eigentliche Pluginaustausch war. Dennoch bin ich der Meinung, dass es sich hierbei um ein xy Problem handelt, weswegen ich dir den alternativen Vorschlag gemacht habe.


    1) Git ist so gesehen ein Industriestandard und läuft theoretisch überall. Ich würde es im Zweifel noch einmal probieren. Es gibt Installer, es gibt Tutorials, etc. Also das dürfte eigentlich kein Grund dagegen sein. Wenn doch, würde ich - so leid es mir tut - die Kompetenz deiner Entwickler ernsthaft anzweifeln.

    3) Deswegen hatte ich es um die Erweiterung der Pull Requests ergänzt, sodass du die Änderungen erst absegnen musst, bevor sie automatisch deployt werden. Alternativ könntest du auch einen Semi-Automatisch Weg gehen, in dem du zwar Git benutzt, aber keine CI/CD Pipeline hast, sondern dann ausgehend vom Source Code selbst die Jar baust und manuell hoch lädst.


    Generell kann ich dir den Weg über Git nur ans Herz legen. Es gibt sehr viele und tolle kostenlose Lösungen wie GitHub, GitLab oder BitBucket. Du profitierst eben einerseits durch die Versionsverwaltung, andererseits sparst du dir aber auch den Dateitransfer von gezippten Projekten, sollten sich die Entwickler ändern. Generell ist es ein weiterer Schritt in Richtung Professionalität und solltet ihr auch beruflich in die informatische Branche tendieren, ist der Umgang mit Git eine sehr gern gesehen Qualifikation (unabhängig von der verwendeten Programmiersprache).

  • Guten Tag,

    um direkt vorweg deine eigentliche Frage zu beantworten, würde ich dir beispielsweise WinMerge nahelegen. Es existiert aber eine wahre Flut an Anwendungen, die den von dir skizzierten Usecase abdecken. Ich habe für Vergleiche – als Linux-Nutzer – beispielsweise in der Vergangenheit Meld genutzt. Das Stichwort für eine Suche bei Google hierzu wäre wohl der etablierte Begriff des "Diffs". Letzten Endes geht es dir ja genau hierum: Du möchtest die Diff(erenz) eines ursprünglichen Ordners und einer neuen Version dieses Ordners vergleichen.


    Dafür musst du zuvor natürlich noch die Jar so dekompilieren, dass sie direkt in einem Ordner abgelegt wird. Du hast bereits geschrieben, dass das Dekompilieren kein Problem sei, aber falls es dennoch Probleme mit deiner existierenden Lösung geben sollte (beispielsweise weil sie die dekompilierten Dateien nicht entsprechend exportiert), so wäre hier Fernflower, das ursprünglich als interne Komponente von IntelliJ IDEA entwickelt wurde, nun aber auch separat erhältlich ist, sicherlich eine solide Wahl. Anschließend vergleichst du dann nur noch mit dem Tool deiner Wahl die beiden Ordner.



    Wo deine eigentliche Frage nun beantwortet ist, würde ich mich aber gerne mit Nachdruck der Argumentation von Der_Maibaum anschließen wollen. Auch ich halte Git hier nicht nur für die bessere Lösung sondern – unabhängig von deinem aktuellen Problem – für eine Ergänzung eures Workflows, die ihr definitiv mal berücksichtigen solltet. Es geht dabei ja keineswegs nur um die Kollaboration und die Kontrolle von eingereichtem Code, sondern viel mehr um die Nachvollziehbarkeit von einzelnen Änderungen, der Sicherung von bestimmten Stadien der Entwicklung sowie eine Umgebung, in der das Durchführen von Experimenten als Teil des allgemeinen Workflows verstanden wird. Und ich denke umso früher ihr Git als wertvolle Bereicherung eurer Tätigkeit versteht, desto einfacher werdet ihr es auch damit haben, die von Git beabsichtigten Workflows für euch zu adaptieren.



    Zur Veranschaulichung werde ich hier mal unseren Workflow als Kurzabriss (weil ich mittelfristig hierzu noch einen umfangreichen Beitrag auf unserer Website veröffentlichen möchte) beschreiben:


    Wir arbeiten grundsätzlich mit zwei Hauptbranches (Entwicklungszweigen): master und development. Im Gegensatz zu vielen anderen Software-Projekten stellen wir an beide Branches die Anforderung, dass sie jederzeit kompilierbar sein müssen und master sich von development nur insofern unterscheidet, dass der master zusätzlich manuell getestet und bereits in der Vergangenheit Teil eines Releases war. Aber auch unsere development-Branch soll zu jedem Zeitpunkt eine weitestgehend stabile Version darstellen, die aber eben bislang nur automatisch getestet wurde.


    Auf diese beiden Branches haben nur Ich und optional ein Project-Maintainer (also der Haupt-Verantwortliche für diese Software-Komponente) Schreibzugriff. Die anderen Entwickler können also ihre Änderung nicht direkt auf die master und development Branches anwenden. So ist schon einmal gesichert, dass sie keine Änderungen veranlassen können, die unmittelbar auf den Server aufgespielt werden. Stattdessen arbeiten die Entwickler in ihren eigenen Feature- bzw. Dev-Branches. Wir verwenden dafür das Schema dev/<name-in-kebab-case> (also zum Beispiel dev/teleport-history). Die Namen dieser Branches sind aber grundsätzlich willkürlich.


    Über diese Entwicklungszweige haben die Entwickler volle Kontrolle und können hier auch frei nach Belieben verändert, gelöscht oder erstellt werden. Darin findet dann die eigentliche Entwicklung statt und der Entwickler testet diese Version auch Eigenständig auf einer eigenen Instanz des Netzwerks. Sobald sich der Entwickler sicher ist, dass das Feature soweit abgeschlossen ist und auch keine weiteren Fehler auftreten, erstellt er einen entsprechenden Merge-Request. Ein solcher Merge-Request ist im Grunde die Beantragung der Überführung der Änderungen seines Entwicklungszweigs in den allgemeinen Entwicklungszweig development. Dort erklärt er dann auch seine Absicht für diesen Commit, verlinkt den vorhergegangenen Issue (Beschreibung des Bugs oder Features) und gibt optional weitere Anmerkungen zu der Merge-Prozedur. Das ganze sieht dann beispielsweise so aus:




    Wenn mir – oder dem entsprechenden Project-Maintainer – nun etwas an dem Code auffällt und wir Änderungen anbringen wollen oder zumindest bestimmte Stellen des Codes gerne diskutieren würden, so machen wir dies über Kommentare an dem gesamten Diff (oder wie Gitlab sie nennt "Threads"). Solche Diskussionen sehen dann beispielsweise so aus:




    Und sobald nun der Code allgemeinen Konsensus gefunden hat und so entsprechend in die Codebase bei development aufgenommen werden kann, mergen Ich – oder der besagte Project-Maintainer – das Ganze und die Änderungen landen automatisch auch in der development Branch. Wir haben so also vollste Kontrolle darüber was nun auf dem Netzwerk und in unserer Codebase landet. Zusätzlich können so frühzeitig Bugs entdeckt werden und alle lernen voneinander innerhalb der entsprechenden Diskussionen innerhalb der Merge-Requests.


    Bei uns sind zudem noch Pipelines (also CI-Job-Serien) in dem Workflow enthalten und ich merge auch nur Merge-Requests für die die Pipeline vollständig erfolgreich durchläuft. Wie eine solche Pipeline bei uns aussehen kann, ist hier zu sehen (Für Fortgeschrittene: Die Commit-Meldung ist übrigens nur deshalb so ... ähem ... rustikal, weil die Commits vor dem Merge gesquashed werden und daher am Ende für die Gesamtheit der Änderungen ein gutes Betreff und eine aussagekräftige Beschreibung gesetzt werden):



    Optional kann hier auch noch das Deployen des Codes (beispielsweise in ein Docker-Cluster) vorgenommen werden. Der Ansatz führt also zu qualitativ höherwertigem Code, besserer Kollaboration, allgemein hoher Sicherheit und vor Allem: Zeitersparnis und weniger Fehlerquellen. Manuelle Tests, Prozesse und Kontrollen sind unheimlich fehleranfällig und sollten daher vermieden werden. Ich kann dir also abschließend wirklich nur noch einmal dazu raten Git ggf. doch noch eine Chance zu geben. Die Vorteile sind riesig und der wohl einzige "Nachteil" ist die Eingewöhnungsphase bzw. die geringfügig verlängerte Einlern-Zeit für neue Entwickler.


    Solltest du hierzu weitere Fragen haben, so beantwortet sie dir sicherlich auch jemand innerhalb des Forums.

  • Erst einmal danke für deine Antwort, genau nach solchen Programmen habe ich gesucht.

    Wie bereits gesagt. Git möchte ich ungerne nutzen, natürlich gibt es da Argumente die dafür sprechen, jedoch möchte und werde ich Git nicht nutzen. Grund hierfür ist hauptsächlich der Inhaber des Servers. Ich habe mit ihm übre dieses Thema gesprochen. Vielen Dank für eure Hilfe


    MFG CheeseTastisch.


    PS: Gibt es eine Möglichkeit das Thema zu schlissen?