Gentoo Java Packing Policy
Das Packen von Java-Anwendungen und -Bibliotheken unter Gentoo Linux ist nicht trivial und ist ein ziemlich komplexer Prozess mit etwas steiler Lernkurve. Diese Richtlinie und dieser Leitfaden zielen darauf ab, Java-Ebuilds zu standardisieren, wann welche Eclass-Klasse, das Build-System usw. verwendet werden sollte. Dies sollte allen helfen, die einen Beitrag leisten möchten, sowie den vorhandenen Gentoo-Entwicklern, wie sie die Gentoo-Java-Paketierungsnuancen kennen lernen. Einzelheiten zur Java-Ebuilds-Syntax, zur Semantik und zu Beispielen finden Sie im Developer Guide
Warum gibt es eine Java-Richtlinie?
Diese Richtlinie ist erforderlich, um Java-Ebuilds konsistent zu halten, einen offiziellen Standard zu bilden und die Korrektur von eingebrachten Java-Ebuilds zu reduzieren. Bitte beachten Sie diese Richtlinien, wenn Sie Java-Anwendungen und -Bibliotheken für Gentoo Linux packen.
Aus Quelle erstellen
Wie bei Gentoo üblich, müssen alle Java-Anwendungen und -Bibliotheken aus der Quelle erstellt werden. Dies beinhaltet alle Abhängigkeiten, die während des Kompilierens gebündelt und / oder heruntergeladen werden können. Für einige Anwendungen werden eingeschränkte Ausnahmen gemacht, und fast nie für eine Bibliothek. Dies alles von Fall zu Fall. Einige komplexe Anwendungen haben zu viele Abhängigkeiten, die nicht gepackt sind, Quellen sind nicht verfügbar und / oder das Paket lässt sich nicht leicht erstellen. Diese können sich für Ausnahmen qualifizieren, aber standardmäßig sollten alle Java-Pakete aus der Quelle erstellt werden. Weitere Informationen finden Sie unter Warum Build from Source.
Abhängigkeiten
Abhängig von Paketen ist alles, was ein anderes Paket ist, abhängig davon, ob es sich um eine Anwendung oder Bibliothek handelt, es muss auch aus der Quelle gepackt werden. Pakete dürfen KEINE eigenen Abhängigkeiten außerhalb von portage ausnahmslos auflösen und / oder herunterladen! Portage sollte alle Abhängigkeiten für das Paket handhaben. Welche Abhängigkeiten müssen gepackt werden. Gebündelte Abhängigkeiten sollten aus den Quellen entfernt werden, um sicherzustellen, dass beim Erstellen des Pakets Systemabhängigkeiten verwendet werden, die nicht im Paket enthalten sind. Es gibt begrenzte Ausnahmen von Fall zu Fall. Gentoo Java Eclasses geben Warnmeldungen aus, wenn gebündelte Binärklassen- oder JAR-Dateien gefunden werden.
Slotting
Anwendungen und Bibliotheken sollten entsprechend der von ihnen bereitgestellten API aufgeteilt werden. Wenn zwei Versionen dieselbe API haben oder eine neue Version vollständig mit der vorherigen Version kompatibel ist, sollten sie sich in demselben SLOT befinden.
Java-Bibliotheken neigen dazu, API und ABI zwischen geringfügigen Überarbeitungen, dh zwischen 2.1.1 und 2.1.2, zu unterbrechen. Infolgedessen ist es notwendig, frühzeitig und häufig zu stecken. Gentoo-Entwickler haben ein Tool namens dev-java / java-apicheck entwickelt, mit dem festgestellt werden kann, ob API-Änderungen in einem Paket enthalten sind, um einen Slot zu rechtfertigen. Bei jeder Änderung der API sollte es einen neuen Slot geben.
Für Java-Anwendungen reicht es meistens aus, nur die neueste Version zu behalten. Wenn die Anwendung wie Tomcat in Serie läuft, möchten wir die neueste Version in jeder Serie beibehalten. Sehr alte Serien werden möglicherweise vollständig gelöscht, auch wenn sie noch vom Upstream verwaltet werden.
Paketkonventionen
Java-Anwendungen können sehr groß sein. Viele haben Teilstücke, die eigenständig gebaut werden können. Es ist üblich, dass andere Teilstücke als Teil der Anwendung von einem anderen Teilstück abhängen. Auf Gentoo sind solche Unterteile einzeln zu verpacken. Bei Bedarf können E-Klassen erstellt werden, um bei allen Aspekten allgemeine Aspekte zu unterstützen. Wenn Sie eine Java-Anwendung in Gentoo packen, sollte die Anwendung in die kleinsten baubaren Teile zerlegt werden. Erstellen von individuellen Paketen für alle Teilstücke. Der Paketname beginnt mit dem Namen der Anwendung, gefolgt vom Namen der Teilkomponente der Anwendung.
Minimale JRE / JDK-Version
Alle Java-Ebuilds sollten das JRE / JDK auf die Mindestversion setzen, sofern Sie keine neuere Version benötigen. NIEMALS sollte die jre / jdk-Version NIEMALS unter das aktuelle Minimum gesetzt werden, es sei denn, ein Paket wird nicht mit der aktuellen Minimumversion kompiliert. Dies ist sehr selten und wahrscheinlich sind alle Pakete veraltet. Die meisten aktuellen Java-Anwendungen und / oder -Bibliotheken sollten mit dem Minimum kompilieren und funktionieren oder ein neueres Programm erfordern. Es ist akzeptabel, auf eine neuere / höhere Version zu setzen, dies bitte jedoch nur, wenn Sie tatsächlich eine neuere / größere Version benötigen. Ansonsten sollten alle Java-Ebuilds auf die aktuelle Mindest-JRE / JDK-Version gesetzt werden.
Aktuelle minimale JRE / JDK-Version:
RDEPEND = „> = virtual / jre-1.7“
DEPEND = „> = virtual / jdk-1.7“
Java-spezifische USE-Flags
Es gibt einige spezifische USE-Flags für Java-Ebuilds . Diese Verwendungsflags werden nicht in der normalen USE-Variablen verwendet, sondern in JAVA_PKG_IUSE. Ein anderes Verwendungsflag als das folgende würde in die normale USE-Variable gehen. Das JAVA_PKG_IUSE muss in einem Ebuild vor der Vererbungszeile stehen.
Die USE-Flags in JAVA_PKG_IUSE
Das doc-Flag erstellt die API-Dokumentation mit javadoc.
Das Quellflag installiert eine Zip des Quellcodes eines Pakets. Dies wird üblicherweise für IDEs verwendet, um die Quelle mit den verwendeten Bibliotheken zu verknüpfen.
Eine Eclass ist eine Sammlung von Code, der von mehr als einem Ebuild verwendet werden kann. Zum Zeitpunkt des Schreibens befinden sich alle Klassen im Verzeichnis eclass / in der Baumstruktur. Grob gesagt gibt es drei Arten von Eclass:
- Die Funktionen, die allgemeine Funktionen bereitstellen, die von vielen Ebuilds verwendet werden (z. B. Eutils, eapi7-ver, cvs, bash-completion)
- Diejenigen, die ein grundlegendes Buildsystem für viele ähnliche Pakete bereitstellen (z. B. vim-plugin, kde)
- Diejenigen, die ein Paket oder eine kleine Anzahl von Paketen mit komplexen Build-Systemen verarbeiten (z. B. vim, toolchain, kernel-2)
Es gibt mehrere Java Eclasses wie folgt: java-ant-2.eclass – Eclass für Ant-basierte Java-Pakete,
java-pkg-2.eclass – Eclass für Java-Pakete,
java-pkg-opt-2.eclass – Eclass für Pakete mit optionaler Java-Unterstützung,
java-pkg-simple.eclass – Eclass für Java-Quellen ohne Buildanweisungen oder verwendbares / funktionierendes Buildsystem, Referenz
java-utils-2.eclass – Base Eclass für Java-Pakete (wird nie direkt in Ebuild verwendet),
java-virtuals-2.eclass – Java Virtuals Eclass (wird nur für Java Virtual Packages verwendet),
java-vm-2.eclass – Java Virtual Machine Eclass (nur für Java-VM-Pakete verwendet)
Welche Eclass verwenden?
Alle Java-Pakete erben immer java-pkg-2.eclass. Pakete mit optionaler Java-Unterstützung sollten java-pkg-opt-2.eclass verwenden. Wenn das Paket über ein Ant-Build-System verfügt, sollten Sie auch java-ant-2.eclass erben. Wenn das Paket kein Buildsystem hat oder ein nicht unterstütztes Buildsystem wie Gradle oder Maven verwendet, sollten Sie java-pkg-simple.eclass erben und verwenden.
Sie werden java-virtuals-2.eclass nur für ein virtuelles Java-Paket verwenden. Es wird nicht für normale Java-Pakete verwendet. Vererben Sie diese Klasse nur, wenn es sich um ein virtuelles Paket handelt.
Java-vm-2.eclass wird nur für Java Virtual Machine-Pakete verwendet. Es wird nicht für normale Java-Pakete verwendet. Vererben Sie diese Klasse nicht, es sei denn, das Paket ist für eine Java Virtual Machine bestimmt.
Die java-utils-2.eclass sollte nicht direkt von einem Ebuild EVER vererbt werden! Die anderen Klassen erben diese Klasse bereits und müssen daher niemals direkt erben.
Java Build-Systeme
Java hat einige gängige Build-Systeme, die häufigsten sind folgende:
ant – Vollständige Integration mit Portage, Build-System kann und sollte verwendet werden
Gant – Keine Integration mit Portage, Build-System kann nicht verwendet werden
Gradle – Keine Integration mit Portage, Build-System kann nicht verwendet werden
ivy – Keine Integration mit portage, kann umgangen werden und NUR ein Build-System verwenden
maven – Keine Integration mit Portage, Build-System kann nicht verwendet werden
Welches Build-System soll verwendet werden?
Versuchen Sie standardmäßig, immer das Buildsystem zu verwenden, das von Upstream bereitgestellt wird. Dies erfordert möglicherweise Änderungen und / oder Patches. Falls dies nicht funktioniert oder ein nicht unterstütztes Build-System wie Gradle oder Maven verwendet wird, fahren Sie mit dem nächsten Abschnitt No Build System fort.
Kein Build-System
Für Pakete ohne Buildsystem oder mit einem nicht unterstützten Buildsystem. Sie müssen sich entweder mit der Verwendung von java-pkg-simple.eclass vertraut machen oder Sie müssen sogar eine eigene Ant build.xml-Datei schreiben, damit Sie das Paket mit Ant erstellen können. Verwenden Sie nicht die mvn ant: ant-Funktion von Maven, um build.xml-Dateien für Ant zu generieren. Diese generierten Dateien sind generisch.
Ameise Ant ist vollständig in portage integriert. Java-Pakete, die mit einem Ant-Build-System geliefert werden, sollten die Java-Ant-2.eclass verwenden. Die von java-ant-2.eclass bereitgestellten Funktionen sollten den Ebuild-Erstellungsprozess vereinfachen. Pakete, die mit einem Ant-basierten Build-System geliefert werden, sollten NICHT java-pkg-simple.eclass anstelle von java-ant-2.eclass verwenden. Es gab Fälle, in denen Ebuild-Revisionen zwischen Eklassen umgestellt wurden. Diese Richtlinie versucht genau dies zu verhindern. Wenn es mit einem Ant-basierten Build-System geliefert wird, verwenden Sie es, umgehen Sie es NICHT auf alternative Weise!
Gant
Gant ist nicht in Portage integriert. Es ist derzeit nicht möglich, Gant zum Erstellen von Java-Paketen unter Gentoo zu verwenden. Sie können dies versuchen, werden aber wahrscheinlich auf andere Probleme stoßen. Derzeit ist keine Integration von Gant in Portage geplant. Bitte beachten Sie den Abschnitt No Build System.
Gradle
Gradle ist nicht in Portage integriert. Es ist derzeit nicht möglich, mit Gradle Java-Pakete unter Gentoo zu erstellen. Sie können dies versuchen, werden aber wahrscheinlich auf andere Probleme stoßen. Derzeit ist keine Integration von Gradle in Portage geplant. Bitte beachten Sie den Abschnitt No Build System.
Efeu
Ivy ist nicht in Portage integriert. Es ist derzeit nicht möglich, Ivy zum Erstellen von Java-Paketen unter Gentoo zu verwenden. Allerdings ist Ivy ein Abhängigkeitsauflöser, der normalerweise um ein Ant-Build-System herum liegt. Das heißt, Sie können die Ivy-Anteile umgehen, kommentieren oder anderweitig auslassen und mit dem Rest des Ant-Build-Systems fortfahren. Wenn Ivy jedoch für ein anderes Build-Tool als Ant verwendet wird, können Sie überhaupt nicht fortfahren. Bitte beachten Sie den Abschnitt No Build System.
Maven
Maven ist nicht in portage integriert. Es ist derzeit nicht möglich, Maven zum Erstellen von Java-Paketen unter Gentoo zu verwenden. Sie können dies versuchen, werden aber wahrscheinlich auf andere Probleme stoßen. Momentan gibt es Pläne für die Integration von Maven in Portage, aber keine ETA. Es wurden mehrere Anstrengungen unternommen, um Maven sowohl von der Quelle (Bootstrap) als auch von Paketen mit Maven zu erstellen. Leider gelang es diesen Bemühungen und dieser Arbeit nie über die Java-Überlagerung hinaus. Es ist schon einige Zeit her, seit jemand an der Integration von Maven gearbeitet hat. Es gab zwar Diskussionen und einige theoretische Pläne, aber keine ETA und niemand, der derzeit daran arbeitet. Für Maven-basierte Pakete beziehen Sie sich bitte auf den Abschnitt No Build System.
Nicht-Standard
Es gibt viele andere nicht standardmäßige Build-Systeme wie autoconf, automake oder Skripts zum Erstellen des Pakets. Normalerweise sind dies Pakete, in denen Java-Teile optional sind und meistens nicht Java-basierte Software erstellt werden. Es kann jedoch vorkommen, dass Software Java Native Interface verwendet und möglicherweise einige Nicht-Java-Komponenten zum Kompilieren verwendet werden. Es gibt andere, bei denen das Paket meistens nicht Java ist, aber einen Teil hat, der Java ist und kein Standard-Java-Build-System für den Java-Teil verwendet. In solchen Situationen muss darauf geachtet werden, dass die Java-Teile korrekt erstellt werden. In diesem Fall ist es wahrscheinlich das Beste, diesen Java-Teil entweder mit java-pkg-simple.eclass zu erstellen oder eine build.xml-Datei für Ant zu erstellen und java-ant-2.eclass zu verwenden. Wenn Sie versuchen, Java-Code ohne Gentoo Java Eclasses zu erstellen, ist das Ergebnis wahrscheinlich falsch, wenn es verwendet werden kann. Bitte umgehen Sie Gentoo Java Eclasses nicht, um alternative Methoden zum Erstellen von Java-Paketen, Code oder Teilen zu erhalten.
Java-Dateisystem-Layout
Im Allgemeinen werden die Verzeichnisrichtlinien von den Hilfsfunktionen in der E-Klasse java-utils-2 für Sie behandelt. Sie dürfen nicht von diesem Dateisystem-Layout abweichen. Stellen Sie keine Gläser an einen anderen Ort, es sei denn, das Paket erfordert dies!
Diese Funktionen entsprechen den folgenden Pfadnamenkonventionen:
/usr/share/${PN}-${SLOT}/package.env enthält Informationen zum Paket.
.jar-Dateien, die aus Quellcode erstellt wurden, werden in / usr / share / $ {PN} – $ {SLOT} / lib / installiert.
Vorgefertigte .jar-Dateien, die nicht vom Ebuild kompiliert wurden, werden in / opt / $ {PN} – $ {SLOT} / lib installiert
Die Javadoc-Dokumentation wird in / usr / share / doc / $ {PF} / html / api / installiert.
Quellarchive werden in / usr / share / $ {PN} – $ {SLOT} / source / installiert.
Vom Benutzer ausführbare Skripts werden in / usr / bin installiert
Systemweite Umgebungsdateien sind in /usr/env.d/java installiert
Benutzerspezifische Umgebungsdateien können in $ {HOME} /. Gentoo / env.d / abgelegt werden.