Minecraft-Plugin übergeben: Vom Quellcode zur JAR
Bevor ihr die Übergabe eines individuell entwickelten Minecraft-Plugins abnehmt, sollte jemand anderes als dessen Autor die vereinbarte Version aus dem übergebenen Repository bauen. Anschließend prüft ihr genau diese neu erzeugte JAR auf dem vorgesehenen Testserver. Die Person erhält die dokumentierten Voraussetzungen und die genehmigten Projektzugänge. Fehlt eine unerklärte Datei, die nur auf dem Laptop des Entwicklers liegt, ist die Übergabe noch unvollständig.
Diese Prüfung richtet sich an Community-Betreiber, Agenturen und Teams, die ihr Plugin später von anderen Entwicklern warten lassen möchten. Sie setzt voraus, dass die Quellcodeübergabe zum vereinbarten Umfang gehört. Das folgende Verfahren ist ein vorgeschlagener Abnahmetest. Mineando hat dafür weder einen Build noch Servertests ausgeführt.
Legt fest, was euer Team erhält
Eine funktionierende JAR, ein Quellcodearchiv und ein wartbares Projekt sind unterschiedliche Liefergegenstände. Vereinbart vor Entwicklungsbeginn den Repository-Zugang, den zur Veröffentlichung gehörenden Quellcodestand, die Build-Anleitung und die benötigten Abhängigkeiten. Haltet Einschränkungen für Änderungen oder die Weitergabe von Drittkomponenten fest. Geht nicht davon aus, dass sämtliche Bestandteile ohne Bedingungen übergeben werden dürfen.
Benennt die empfangende Person und die Organisation, die das Repository und die Build-Konten kontrolliert. Das persönliche Konto des ursprünglichen Entwicklers sollte keine versteckte Voraussetzung für die Wartung sein. Gehört der Quellcode nicht zur Lieferung, müssen diese Grenze und der Weg für spätere Änderungsaufträge ausdrücklich feststehen.
Der Leitfaden zur Plugin-Abnahme behandelt Spielverhalten, Berechtigungen und Fehlerfälle. Hier geht es um eine engere Frage: Kann das übernehmende Team die Software selbst erzeugen, die es künftig warten soll?
Ordnet die Veröffentlichung einem exakten Stand zu
Erstellt vor der Probe ein kurzes Versionsprotokoll. Darin stehen die gelieferte JAR, ihre Prüfsumme, der genaue Quellcode-Commit, der Build-Befehl und die benötigte Umgebung. Ergänzt eine verständliche Versionsbezeichnung, verlasst euch aber nicht allein auf einen Dateinamen wie event-plugin-final.jar.
Bei einem hypothetischen Anmelde-Plugin könnte das Protokoll die Version 1.4.0, die tatsächliche Commit-Kennung und den vereinbarten Paper-Build nennen. Diese Angaben müssen aus dem konkreten Projekt stammen. Fehlende Werte werden nicht geraten. Auch die Serverversion wird für die Probe nicht beiläufig gegen die neueste ausgetauscht.
Unterscheidet die Java-Umgebung für den Build von der Laufzeitumgebung des Testservers und dokumentiert beide. Dazu gehören erforderliche Begleitplugins und Einstellungen. Der übernehmende Entwickler muss erkennen können, welche Version gebaut und wo ihr Verhalten geprüft wurde, ohne alte Chatverläufe zusammensuchen zu müssen.
Übergebt Werkzeug und eindeutige Anleitung
Bei einem Gradle-Projekt gehören die Wrapper-Skripte und zugehörigen Dateien in die Versionsverwaltung. Der Gradle Wrapper führt die festgelegte Gradle-Version aus und lädt sie bei Bedarf herunter. Damit wird die Version des Build-Werkzeugs kontrolliert, nicht jede weitere Eingabe des Builds.
Die Anleitung muss den genauen Task für die installierbare JAR und deren Ausgabepfad nennen. Ein Projekt kann mehrere Archive erzeugen. „Nimm eine Datei aus dem Build-Ordner“ reicht deshalb nicht. Beschreibt außerdem, wie Tests ausgeführt werden und wo ihre Ergebnisse liegen. Erfolgreiches Verpacken belegt nicht, dass Tests vorhanden waren oder tatsächlich liefen.
Fordert eine Liste der externen Repositories und der erforderlichen Zugänge an. Zugangsdaten gehören nicht ins Quellcodearchiv; stellt sie über das vereinbarte Verfahren bereit. Die Probe soll fehlende Berechtigungen sichtbar machen, ohne Geheimnisse im Abnahmeprotokoll zu hinterlassen.
Prüft die Herkunft der Abhängigkeiten
Funktioniert ein Build nur wegen einer alten Bibliothek im Cache eines bestimmten Rechners, bleibt die Übergabe anfällig. Lasst euch erklären, woher die Abhängigkeiten stammen und welche tatsächlich aufgelösten Versionen zur Veröffentlichung gehören.
Gradles Dependency Locking hält aufgelöste Versionen fest; die zutreffenden Lockfiles gehören in die Versionsverwaltung. Veränderliche Inhalte unter denselben Koordinaten, etwa bei einer wechselnden SNAPSHOT-Abhängigkeit, werden dadurch nicht eingefroren.
Die Paper-Projektdokumentation unterscheidet neuere API-Koordinaten, die einen konkreten Build angeben können, vom älteren -SNAPSHOT-Format. Prüft das Format eurer Zielversion, statt das aktuelle Beispiel unverändert in ein älteres Projekt zu übernehmen.
Bei privaten Bibliotheken muss klar sein, was beim Ausscheiden eines Mitarbeiters oder beim Ausfall eines Repositories geschieht. Vereinbart die Verantwortung für Zugänge und eine gegebenenfalls erlaubte Aufbewahrung benötigter Artefakte. Versionssperren garantieren keine zukünftige Verfügbarkeit eines Repositories. Dokumentiert offene Einschränkungen und ihre Folgen für die Wartung vor der Freigabe.
Führt die Probe in einer separaten Umgebung durch
Nutzt einen isolierten Rechner oder eine Build-Umgebung, die das empfangende Team freigegeben hat. Beginnt mit einem frischen Checkout des vermerkten Commits und einem neuen Abhängigkeitscache. Löscht dafür keine Arbeitsdateien des Autors. Für die dokumentierten Downloads kann weiterhin Netzwerkzugang erforderlich sein. Ein frischer Build ist nicht automatisch ein Offline-Build.
- Arbeitet die Voraussetzungen ab und beschafft die vorgesehenen Repository-Zugänge.
- Checkt die dokumentierte Revision aus, ohne lokale Build-Ergebnisse des Autors zu kopieren.
- Führt die beschriebenen Build- und Testbefehle aus und bewahrt Protokolle sowie tatsächliche Testergebnisse auf.
- Ermittelt das benannte installierbare Artefakt und notiert seine Prüfsumme.
- Installiert genau diese Datei auf einem isolierten Server mit der vereinbarten Abnahmeumgebung.
- Wiederholt einen festgelegten Verhaltenstest, etwa Anmeldung, erneute Verbindung und Prüfung der gespeicherten Teilnahme.
Fehlt im Beispiel eine private Bibliothek, wird die Probe mit einem nachvollziehbaren offenen Punkt angehalten. Eine unerklärte JAR von einem anderen Laptop kann eine Vorführung retten, lässt die Wartungsabhängigkeit aber verborgen. Ergänzt die rechtmäßig verfügbare Bibliothek und das Zugangsverfahren in den Übergabeunterlagen. Wiederholt anschließend die betroffenen Schritte.
Unterscheidet Neubau und identische Binärdatei
Ein erfolgreicher Build kann eine andere Datei erzeugen. Strenge Reproduzierbarkeit verlangt identische Artefaktbytes aus demselben Quellcode, einer definierten Umgebung und denselben Anweisungen. Falls das eine Anforderung ist, vereinbart sie ausdrücklich und vergleicht die benannten Artefakte.
Bei unterschiedlichen Prüfsummen muss der Entwickler die Abweichung untersuchen, bevor die neue JAR als identisch mit der gelieferten Binärdatei behandelt wird. Erklärt Unterschiede nicht ungeprüft für harmlos. Umgekehrt beweist eine gleiche Prüfsumme nicht, dass alle Spielanforderungen bestanden wurden. Bewahrt Build-Nachweise und Server-Abnahmeergebnisse gemeinsam auf, mit klar erkennbarer Aussagekraft.
Die Probe gilt für die vereinbarte Veröffentlichung. Sie belegt weder zukünftige Minecraft-Kompatibilität noch die Umkehrbarkeit eines Updates, das Daten verändert. Plant Bereitstellung und Wiederherstellung gesondert; dabei hilft der Leitfaden zur Freigabe nach einem Paper-Update.
Schließt die Übergabe mit nutzbaren Nachweisen ab
Dieser Teil der Lieferung ist abnahmefähig, wenn der empfangende Entwickler der Anleitung folgen, die erlaubten Abhängigkeiten beziehen, das richtige Artefakt erzeugen und den vereinbarten Servertest abschließen kann. Legt Versionsprotokoll, Logs, Ergebnisse und akzeptierte Einschränkungen dazu. Benennt Verantwortliche für Repository-Zugänge, künftige Abhängigkeitsupdates und die nächste Wartungsversion.
Für individuelle Minecraft-Entwicklung bringt ihr diese Übergabeanforderungen zusammen mit Spielerablauf, Zielversionen, Termin und Budget mit. Mineando kalkuliert bezahlte Projekte individuell. Quellcodeübergabe, Wartungsverantwortung und Support werden ausdrücklich vereinbart. Eine erfolgreiche Übergabe schließt spätere Updates nicht automatisch ein.
