Identificación de Archivo JAR

Las aplicaciones Java complejas normalmente constan de múltiples componentes. Cada componente puede tener múltiples implementaciones, llamadas artefactos. Los artefactos en el contexto Java normalmente son archivos JAR, pero también pueden ser archivos WAR y cualquier otra familia de archivo.

Hay múltiples formas incompatibles de identificar (denominar) artefactos Java y cada sistema de compilación a menudo fomenta el uso de un esquema de nomenclatura específico. Esto significa que las distribuciones Linux también necesitan permitir que cada artefacto sea ubicado utilizando varios identificadores diferentes, utilizando posiblemente diferentes esquemas. Por otro lado es prácticamente imposible utilizar todos los esquemas de nomenclatura, por lo que existen algunas simplificaciones.

Este capítulo describe diferentes formar de identificar y localizar artefactos en el repositorio del sistema.

Rutas relativas

Los artefactos JAR son instalados un uno de los árboles de directorio estándar. Usualmente esto es o bien %{_javadir} (/usr/share/java) o bien %{_jnidir} (/usr/lib/java).

La forma más sencilla de identificar artefactos es mediante su ruta relativa desde una de las ubicaciones estándar. Todos los artefactos pueden identificarse de esta manera, ya que cada uno tiene un nombre de archivo único. En este documento, cada ruta que identifica un artefacto se denominará "ruta del artefacto".

Para que las rutas de los artefactos sean más sencillas y legibles, se puede omitir la extensión si es igual a jar. Para los artefactos que no son JAR, la extensión no se puede omitir y debe conservarse.

Además, si la ruta del artefacto apunta a un directorio, representa todos los artefactos contenidos en dicho directorio. Esto permite hacer referencia fácilmente a un conjunto completo de artefactos relacionados, simplemente especificando el nombre del directorio que los contiene.

Si el mismo parche del artefacto tiene extensiones válidas en dos directorios raíz diferentes entonces no está especificado cuales artefactos estarán situados.

Especificación de artefacto

Como notado en sección anterior, cada artefacto puede ser identificado únicamente por su ruta de archivo. Sin embargo esto no siempre la manera preferida para identificación de artefacto.

Modern Java build systems provide a way of identifying artifacts with an abstract identifier, or more often, a pair of identifiers. The first if usually called group ID or organization ID while the second is just artifact ID. This pair of identifiers will be called artifact coordinates in this document. Besides group ID and artifact ID, artifact coordinates may also include other optional information about artifact, such as extension, classifier and version.

In Linux distributions it is important to stay close to upstreams providing software being packaged, so the ability to identify artifacts in the same way as upstream does is very important from the packaging point of view. Every artifact can optionally be identified by artifact coordinates assigned during package build. Packages built with Maven automatically use this feature, but all other packages, even these built with pure javac, can use this feature too (see description of %mvn_artifact and %add_maven_depmap macros).

Alias

Los alias funcionan de dos maneras:

  • Enlaces simbólicos para rutas

  • Relaciones adicionales para las especificaciones de artefactos

In the real world the same project can appear under different names as it was evolving or released differently. Therefore other projects may refer to those alternative names instead of using the name currently prefered by upstream.

Aliases de artefacto

XMvn provides a way to attach multiple artifact coordinates to a single artifact. Dependent projects that use alternative coordinates can then be built without the need to patch their POMs or alter the build by other means. It will also generate virtual provides for the alias, so it can be also used in Requires and BuildRequires. Creating an alias is achieved by %mvn_alias macro.

Ejemplo de invocación
# com.example.foo:bar (el artefacto real existente en el proyecto) también
# está disponible como com.example.foo:bar-all
%mvn_alias com.example.foo:bar com.example.foo:bar-all

# No es necesario repetir la parte de las coordenadas que permanece igual
# (groupID en este caso)
%mvn_alias com.example.foo:bar :bar-all

# Puedes especificar varios alias a la vez.
%mvn_alias com.example.foo:bar :bar-all :bar-lib

# La macro admite varios atajos para generar múltiples alisaes.
# Ramas - {} - captura su contenido, los cuales entonces ser referenced en la
# parte alias con @N, donde N es el índice del grupo de captura.
# * actúa como comodín (coteja cualquiera)
# El siguiente genera aliases finalizados con sombreados para todos artefactos
# en el proyecto
%mvn_alias 'com.ejemplo.talcual:{}' :@1-sombreado

Versiones de compatibilidad

Manipular para compatibilidad de paquetes, jars versionados, etc.

In Fedora we prefer to always have only the latest version of a given project. Unfortunately, this is not always possible as some projects change too much and it would be too hard to port dependent packages to the current version. It is not possible to just update the package and keep the old version around as the names, file paths and dependency provides would clash. The recommended practice is to update the current package to the new version and create new package representing the old version (called compat package). The compat package needs to have the version number (usually only the major number, unless further distinction is necessary) appended to the name, thus effectivelly having different name from RPM’s point of view. Such compat package needs to perform some additional steps to ensure that it can be installed and used along the non-compat one.

You should always evaluate whether creating a compat package is really necessary. Porting dependent projects to new versions of dependencies may be a complicated task, but your effort would be appreciated and it is likely that the patch will be accepted upstream at some point in time. If the upstream is already inactive and the package is not required by anything, you should also consider retiring it.
Versiones de compatibilidad de Maven

XMvn supports marking particular artifact as compat, performing the necessary steps to avoid clashes with the non-compat version. An artifact can be marked as compat by %mvn_compat_version. It accepts an artifact argument which will determine which artifact will be compat. The format for specifying artifact coordinates is the same as with %mvn_alias. In the common case you will want to mark all artifacts as compat. You can specify multiple compat versions at a time.

Resolución de dependencias de artefactos de compatibilidad

Cuando XMvn realiza la resolución de dependencias para un artefacto de dependencia en un proyecto, verifica la versión de la dependencia y la compara con todas las versiones del artefacto instaladas en el directorio de compilación. Si ninguno de los artefactos compatibles coincide, resolverá el artefacto al que no sea compatible. Esto tiene algunas implicaciones:

  • The versions are compared for exact match. The compat package should provide all applicable versions that are present in packages that are supposed to be used with this version.

  • The dependent packages need to have correct BuildRequires on the compat package as the virtual provides is also different (see below).

Los nombres de archivo y los proveedores virtuales

In order to prevent file name clashes, compat artifacts have the first specified compat version appended to the filename. Virtual provides for compat artifacts also contain the version as the last part of the coordinates. There are multiple provides for each specified compat version. Non-compat artifact do not have any version in the virtual provides.

Ejemplo de invocación de %mvn_compat_version
# Asumiendo el paquete tiene barra de nombre y versión 3
# Conjuntos el compat versión de foo:artefacto de barra a 3
%mvn_compat_versión foo:barra 3
# El archivo de artefacto instalada (suponiendo que es un jar y no había ninguno
# %mvn_llamadas de lima) será en %{_javadir}/barra/de barra-3.Bote
# El generado proporciona para foo:la barra será
# mvn(foo:barra:3) = 3
# mvn(foo:barra:pom:3) = 3

# Establece las versiones de compatibilidad de todos los artefactos en la compilación a 3 y 3.2.
%mvn_compat_version : 3 3.2

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