Paketierungsrichtlinien 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

The following applies to all JAR files except JNI-using JAR files and application-specific JAR files (i.e., JAR files that can only reasonably be used as part of an application and therefore constitute application-private data).

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 files

If upstream project is shipping Maven pom.xml files, these MUST be installed. Additionally, the package MUST install a mapping between the upstream artifact and the filesystem by using the %mvn_install macro.

If upstream project does not ship Maven pom.xml file, the official maven repository should be consulted and if the project publishes pom.xml files there, they SHOULD be included.

If modifications to Maven pom.xml files are needed, the %pom_* family of macros SHOULD be used.

Wrapper-Skripte

Applications wishing to provide a convenient method of execution SHOULD provide a wrapper script in %{_bindir}. Packages SHOULD use %jpackage_script to create these wrapper scripts.

Kompatibilitätspakete

In certain cases it might be necessary to create compatibility packages that provide older API/ABI level of the same library. However, creating these compatibility packages is strongly discouraged.

To standardize and simplify packaging of such compatibility packages, the following rules apply:

  • Compatibility packages MUST be named in the same way as the original package except the addition of the version to the package’s name.

  • Any JAR and POM files MUST be versioned, as well.

Paketierung von JAR-Dateien, die JNI verwenden

Anwendbarkeit

Java programs that wish to make calls into native libraries do so via the Java Native Interface (JNI). A Java package uses JNI if it contains a .so file. Note that this file can be embedded within JAR files themselves.

Richtlinie

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

  • JAR files using JNI or containing JNI shared objects themselves MUST be placed in %{_jnidir}, but MAY be symlinked to %{_libdir}/%{name}.

  • JNI shared objects MUST be placed in %{_libdir}/%{name}.

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