Pautas de Empaquetado de Java

Esta página representa la directriz de Fedora para bibliotecas de empaquetado y aplicaciones escritas en Java y relacionadas con idiomas que utilicen la Máquina Virtual de Java como un intérprete de bytecode.

Este documento no pretende describir exhaustivamente técnicas y consejos de empaquetado. Las macros y comandos RPM utilizados aquí están documentados en las páginas del manual. Además, una guía aparte Java Packaging HOWTO describe en detalle las técnicas de empaquetado de Java e incluye ejemplos, plantillas y documentación dirigida a empaquetadores y desarrolladores Java que se inician en el empaquetado RPM de Java.

El empaquetado de Java de Fedora originalmente está basado en los estándares de JPackage Project. A lo largo del tiempo tenemos divergencias en las herramientas de empaquetado en muchas áreas pero comúnmente conservamos compatibilidad hacia atrás con paquetes más anteriores que utilizan los estándares de JPackage.

Nombrado de paquete

Los paquetes DEBEN seguir las pautas de nombres de paquetes estándar de Fedora.

La documentación de la API de Java DEBE colocarse en un subpaquete llamado %{name}-javadoc.

Lanzamientos

Paquetes DEBEN seguir el estándar de directrices del versionado de paquete de Fedora.

Mantenimiento de arquitectura

Es posible que el sistema JDK / JRE no esté disponible en todas las arquitecturas que sean compatibles con cualquier versión dada de Fedora.

Por este motivo, todos los paquetes Java DEBEN contener una etiqueta exclusiva que es ExclusiveArch:

  • Paquetes que se crean solo sub‐paquetes noarch DEBEN utilizar ExclusiveArch: %{java_arcos} noarch.

  • Los paquetes que incluyan artefactos de construcción dependientes de la arquitectura (p.e. módulos Empaquetar archivos JAR que utilizan JNI) DEBEN utilizar ExclusiveArch: %{java_arcos}.

La macro %{java_arches} contiene un listado de todas las arquitecturas donde esté disponible el sistema JRE / JDK y esté definido sobre todas las versiones de Fedora.

Dependencias de pre-compilación

Los paquetes DEBEN seguir el estándar de la dependencia de directrices de agrupación en Fedora.

En particular, los archivos *.class y *.jar desde las versiones en desarrollo NO DEBEN ser utilizadas durante la creación de los paquetes de Fedora y NO DEBEN ser incluidos en los RPM binarios.

Instalación de archivos JAR

Lo siguiente se aplica a todos los archivos JAR excepto los JNI-using JAR y los archivos JAR específicos de la aplicación (p.e., archivos JAR que solo pueden razonadamente ser utilizados como parte de una aplicación y por tanto constituir datos privados de la aplicación).

Desglose de archivos JAR

Si un proyecto ofrece la elección de empaquetarlo como un único JAR monolítico o como varios JAR separados, el desglose de empaquetado SERÍA el preferido.

Directorio de instalación

  • Todos los archivos JAR independientes de la arquitectura DEBEN ir dentro de %{_javadir} o su subdirectorio.

  • Para instalación de arquitectura dependiente de archivos JAR, consulte Empaquetar archivos JAR que utilizan JNI.

Nombre del archivos

  • Si el paquete proporciona un *único+ archivo JAR con el nombre del archivo instalado SERÍA %{name}.jar.

  • Si el paquete proporciona múltiples archivos JAR, DEBERÍAN ser instalados en un subdirectorio %{name}.

  • Archivos JAR con versión (-%{version}.jar) NO DEBE ser instalado a no ser que el paquete sea un paquete de compatibilidad.

  • Los paquetes PUEDEN proporcionar nombres de archivos alternativos, así como no entren en conflicto con otros paquetes.

BuildRequires y Requires

Los paquetes de Java DEBEN tener el requisito BuildRequire respectivo al sistema de creación (o un vínculo de versión):

  • BuildRequires: maven-local o maven-local-openjdk${N} para paquetes creados con Maven

  • BuildRequires: javapackages-local o javapackages-local-openjdk${N} para paquetes no creados con Maven

Las aplicaciones Java TENDRÍAN Requires en un paquete en tiempo de ejecución apropiado para Java:

  • java-headless para aplicaciones no requiriendo interfaz gráfico

  • java para aplicaciones que requieran interfaz gráfico

  • java-devel para aplicaciones que requieran contenido adicional relacionado para desarrollo en Java

Instalación de Javadoc

  • La documentación de JavaDoc PUEDE ser generada.

  • Si la documentación de javadoc es generada, DEBE ser instalada in un directorio o %{_javadocdir}/%{name} como parte del subpaquete -javadoc.

  • El directorio o enlace simbólico %{_javadocdir}/%{name}-%{version} NO EXISTIRÍA.

  • El subpaquete javadoc DEBE ser declarado noarch, incluso si el paquete principal es específico de la arquitectura.

Ninguna ruta-clase en MANIFEST.MF

Los archivos JAR NO DEBEN incluir un apunte class-path en su archivo META-INF/MANIFEST.MF.

Rutas hardcoded

Los paquetes NO DEBEN codificar rutas a lo duro para archivos JAR que utilizan. Cuando un paquete necesita referenciar un archivo JAR, el empaquetador UTILIZARÍA una de las herramientas que estén designadas para localizar archivos JAR en el sistema.

Archivos pom.xml de Maven

Si el proyecto en desarrollo está llevado por archivos Maven pom.xml`, DEBE ser instalado. Adicionalmente, el paquete DEBE instalar una relación entre el artefacto en desarrollo y el sistema de archivos utilizando la macro `%mvn_install+.

Si en el proyecto en desarrollo no lleva el archivo pom.xml de Maven, el repositorio maven oficial sería consultado y si el proyecto publica los archivos pom.xml allí, ESTARÍAN incluidos.

Si son necesarias las modificaciones a los archivos pom.xml de Maven, la familia %pom_ de macros SERÍAN utilizadas.

Script de Cobertura

Las aplicaciones que deseen proporcionar un método conveniente de ejecución PROPORCIONARÍAN un script de cobertura en %{_bindir}. Los paquetes UTILIZARÍAN %jpackage_script para crear estos guiones de coberturas.

Paquetes de compatibilidad

En ciertos casos podría ser necesario crear paquetes de compatibilidad que proporcionen nivel de API/ABI más anteriores de la misma biblioteca. Sin embargo, crear estos paquetes de compatibilidad es altamente desaconsejado.

Para estandarizar y simplificar el empaquetado de tales paquetes de compatibilidad, aplique las reglas siguientes:

  • Los paquetes de compatibilidad DEBEN estar nombrados de la misma manera que el paquete original excepto para la adición de la versión del nombre del paquete.

  • Cualquiera de los archivos JAR y POM DEBEN ser versionados, también.

Empaquetar archivos JAR que utilizan JNI

Aplicabilidad

Los programas de Java que deseen realizar invocaciones a bibliotecas nativas las cuales vayan por medio de Java Nativa Inteface (JNI). Un paquete de Java utiliza JNI si contiene un archivo .so. Note que este archivo puede ser embebido con archivos JAR ellos mismos.

Directrices

Los paquetes de JNI DEBEN seguir las guías de paquetes Java ordinarios, con estas excepciones:

  • Los archivos JAR utilizan JNI o contengan objetos JNI compartidos ellos mismos DEBEN estar situados en %{_jnidir}, pero PUEDEN ser enlazados simbólicamente a %{_libdir}/%{name}.

  • Los objetos JNI compartidos DEBEN estar situados en %{_libdir}/%{name}.

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