Paketbaurichtlinien für Java

Diese Seite stellt die Fedora-Richtlinien für die Paketierung von Bibliotheken und Anwendungen dar, die in Java und verwandten Sprachen geschrieben sind und die „Java Virtual Machine“ als Bytecode-Interpreter verwenden.

Dieses Dokument beschreibt keine ausführlichen Paketierungstechniken und -tipps. Die hier verwendeten RPM-Makros und -Befehle sind in Handbuchseiten dokumentiert. Darüber hinaus beschreibt ein separates HOWTO zur Java-Paketierung HOWTO Java-bezogene Techniken detailliert und enthält Beispiele, Vorlagen und Dokumentation für Paketierer und Java-Entwickler, die erste Schritte im Bereich Java-RPM-Paketierung unternehmen.

Die Java-Paketierung von Fedora basiert ursprünglich auf den Standards des JPackage-Projekts. Im Laufe der Zeit haben sich unsere Ansätze bei den Paketierungswerkzeugen in den meisten Bereichen weiterentwickelt, wir achten aber weiterhin auf Abwärtskompatibilität mit älteren Paketen, die die JPackage-Standards verwenden.

Benennung von Paketen

Pakete MÜSSEN den üblichen Richtlinien zur Paketbenennung in Fedora entsprechen.

Die Java-API-Dokumentation MUSS in einem Teilpaket namens %{name}-javadoc abgelegt werden.

Release-Tags

Pakete MÜSSEN den üblichen Richtlinien zur Versionierung in Fedora entsprechen.

Architekturunterstützung

Das System-JDK bzw. -JRE ist möglicherweise nicht auf allen Architekturen verfügbar, die von einer bestimmten Fedora-Version unterstützt werden.

Aus diesem Grund MÜSSEN alle Java-Pakete ein ExclusiveArch-Tag enthalten:

  • Pakete, die ausschließlich noarch-Teilpakete erstellen, MÜSSEN ExclusiveArch: %{java_arches} noarch verwenden.

  • Pakete, die architekturabhängige Build-Artefakte (d.h. Paketierung von JAR-Dateien, die JNI verwenden-Module) enthalten, MÜSSEN ExclusiveArch: %{java_arches} verwenden.

Das Makro %{java_arches} enthält eine Liste aller Architekturen, auf denen das System-JRE / -JDK verfügbar ist, und ist in allen Fedora-Versionen definiert.

Vorkompilierte Abhängigkeiten

Pakete MÜSSEN den Standardrichtlinien von Fedora für die Bündelung von Abhängigkeiten entsprechen.

Insbesondere DÜRFEN *.class`- und `*.jar-Dateien aus Upstream-Releases beim Erstellen von Fedora-Paketen NICHT verwendet werden und sie DÜRFEN NICHT in binäre RPM-Pakete aufgenommen werden.

Installation von JAR-Dateien

Das Folgende gilt für alle JAR-Dateien mit Ausnahme von JNI-using JAR files und anwendungsspezifischen JAR-Dateien (d. h. JAR-Dateien, die vernünftigerweise nur im Rahmen einer Anwendung verwendet werden können und daher anwendungsinterne Daten darstellen).

JAR-Dateien teilen

Wenn ein Projekt die Wahl bietet, es als ein einziges monolithisches JAR-Archiv oder als mehrere separate JAR-Archive zu paketieren, SOLLTE die geteilte Paketierung bevorzugt werden.

Installationsverzeichnis

  • Alle architekturunabhängigen JAR-Dateien MÜSSEN in %{_javadir} oder einem seiner Unterverzeichnisse abgelegt werden.

  • Informationen zur Installation architekturabhängiger JAR-Dateien finden Sie unter Paketierung von JAR-Dateien, die JNI verwenden.

Dateinamen

  • Wenn das Paket eine einzelne JAR-Datei bereitstellt, SOLLTE der Dateiname %{name}.jar lauten.

  • Falls das Paket mehrere JAR-Dateien bereitstellt, SOLLTEN diese in einem Unterverzeichnis %{name} installiert werden.

  • Versionierte JAR-Dateien (*-%{version}.jar) DÜRFEN NICHT installiert werden, es sei denn, es handelt sich um ein Kompatibilitätspaket.

  • Pakete DÜRFEN alternative Dateinamen bereitstellen, sofern diese nicht mit anderen Paketen in Konflikt stehen.

BuildRequires und Requires

Java-Pakete MÜSSEN ihr jeweiliges Bausystem (oder eine versionierte Bindung davon) als „BuildRequires“einbinden:

  • BuildRequires: maven-local oder maven-local-openjdk${N} für Pakete, die mit Maven gebaut werden

  • BuildRequires: javapackages-local oder javapackages-local-openjdk${N} für Pakete, die nicht mit Maven gebaut werden

Java-Anwendungen SOLLTEN Requires für ein entsprechendes Java-Laufzeitpaket haben:

  • java-headless für Anwendungen, die keine grafische Oberfläche benötigen

  • java für Anwendungen, die eine grafische Oberfläche benötigen

  • java-devel für Anwendungen, die zusätzliche Inhalte im Zusammenhang mit der Java-Entwicklung benötigen

Javadoc-Installation

  • JavaDoc-Dokumentation DARF erstellt werden.

  • Wenn Javadoc-Dokumentation generiert wird, MUSS sie in ein Verzeichnis %{_javadocdir}/%{name} in einem Teilpaket -javadoc installiert werden.

  • Ein Verzeichnis oder Symlink %{_javadocdir}/%{name}-%{version} SOLLTE NICHT existieren.

  • Das Javadoc-Teilpaket MUSS mit noarch deklariert werden, auch wenn das Hauptpaket architekturspezifisch ist.

Kein Klassenpfad in MANIFEST.MF

JAR-Dateien DÜRFEN keinen class-path-Eintrag in ihrer META-INF/MANIFEST.MF-Datei enthalten.

Fest kodierte Pfade

Pakete dürfen keine Pfade zu den verwendeten JAR-Dateien fest kodieren. Wenn ein Paket auf eine JAR-Datei verweisen muss, sollte der Paketierer eines der Werkzeuge verwenden, die speziell für das Auffinden von JAR-Dateien im System entwickelt wurden.

Maven-pom.xml-Dateien

Wenn das Upstream-Projekt Maven-Dateien (pom.xml) ausliefert, MÜSSEN diese installiert werden. Zusätzlich MUSS das Paket mithilfe des Makros %mvn_install eine Zuordnung zwischen dem Upstream-Artefakt und dem Dateisystem herstellen.

Falls das Upstream-Projekt keine Maven pom.xml-Datei mitliefert, sollte das offizielle Maven-Repository konsultiert werden, und falls das Projekt dort pom.xml-Dateien veröffentlicht, SOLLTEN diese eingebunden werden.

Falls Änderungen an den Maven pom.xml-Dateien erforderlich sind, SOLLTE die Makrofamilie %pom_* verwendet werden.

Wrapper-Skripte

Anwendungen, die eine komfortable Ausführungsmethode bereitstellen möchten, SOLLTEN ein Wrapper-Skript in %{_bindir} bereitstellen. Pakete SOLLTEN %jpackage_script verwenden, um diese Wrapper-Skripte zu erstellen.

Kompatibilitätspakete

In bestimmten Fällen kann es erforderlich sein, Kompatibilitätspakete zu erstellen, die eine ältere API-/ABI-Version derselben Bibliothek bereitstellen. Von der Erstellung solcher Kompatibilitätspakete wird jedoch dringend abgeraten.

Zur Standardisierung und Vereinfachung der Erstellung solcher Kompatibilitätspakete gelten folgende Regeln:

  • Kompatibilitätspakete MÜSSEN genauso benannt werden wie das Originalpaket, nur dass zum Paketnamen die Versionsnummer hinzugefügt wird.

  • Sämtliche JAR- und POM-Dateien MÜSSEN ebenfalls versioniert werden.

Paketierung von JAR-Dateien, die JNI verwenden

Anwendbarkeit

Java-Programme, die native Bibliotheken aufrufen möchten, verwenden dazu das Java Native Interface (JNI). Ein Java-Paket nutzt JNI, wenn es eine .so-Datei enthält. Diese Datei kann auch in JAR-Dateien eingebettet sein.

Richtlinie

JNI-Pakete MÜSSEN den Richtlinien für normale Java-Pakete folgen, jedoch mit folgenden Ausnahmen:

  • JAR-Dateien, die JNI verwenden oder selbst gemeinsam genutzte JNI-Objekte enthalten, MÜSSEN in %{_jnidir} abgelegt werden, KÖNNEN aber mit %{_libdir}/%{name} verlinkt werden.

  • Gemeinsam genutzte JNI-Objekte MÜSSEN in %{_libdir}/%{name} abgelegt werden.

Want to help? Learn how to contribute to Fedora Docs ›