Para Desarrolladores de Java

Packaging Java software has specifics which we will try to cover in this section aimed at Java developers who are already familiar with Java language, JVM, classpath handling, Maven, pom.xml file structure and dependencies.

Instead we will focus on basic packaging tools and relationships between Java and RPM world. One of the most important questions is: What is the reason to package software in RPM (or other distribution-specific formats). There are several reasons for it, among others:

  • Método unificado de instalación de software para usuarios de la distribución, independientemente de los proyectos en desarrollo

  • Verificación de la autenticidad de los paquetes de software mediante sus firma

  • Actualizaciones de software simplificadas

  • Manipulación automática de dependencias para usuarios

  • Diseño común del sistema de archivos en toda la distribución, impuesto por los estándares de empaquetado

  • Capacidad para administrar, supervisar y consultar paquetes instalados en varias máquinas a través de interfaces unificadas

  • Distribución de metadatos adicionales con el propio software, como las licencias utilizadas, la página web del proyecto, los registros de cambios y otra información que los usuarios o administradores puedan encontrar útil

Ejemplo de proyecto RPM

RPM uses spec files as recipes for building software packages. We will use it to package example project created in previous section. If you did not read it you do not need to; the file listing is available here and the rest is not necessary for this section.

Listado de directorio
Makefile
src
src/org
src/org/fedoraproject
src/org/fedoraproject/helloworld
src/org/fedoraproject/helloworld/output
src/org/fedoraproject/helloworld/output/Output.java
src/org/fedoraproject/helloworld/input
src/org/fedoraproject/helloworld/input/Input.java
src/org/fedoraproject/helloworld/HelloWorld.java

Hemos empaquetado el directorio del proyecto en el archivo helloworld.tar.gz.

Ejemplo del archivo spec
Unresolved directive in introduction_for_developers.adoc - include::{EXAMPLE}rpm_project/helloworld.spec[]

Los archivos spec de RPM contienen varias secciones básicas:

Cabecera, la cual contiene:

  • Package metadata such as its name, version, release, license, …​

  • A Summary with basic one-line summary of package contents.

  • Package source URLs denoted with Source0 to SourceN directives.

    • Source files can then be referenced by %SOURCE0 to %SOURCEn, which expand to actual paths to given files.

    • In practice, the source URL shouldn’t point to a file in our filesystem, but to an upstream release on the web.

  • Patches - using Patch0 to PatchN.

  • Project dependencies.

    • Dependencias de compilación especificadas por BuildRequires, los cuales necesitan ser determinados manualmente.

    • Las dependencias de tiempo de ejecución se detectarán automáticamente. Si no es así, tendrás que especificarlas con Requires.

    • More information on this topic can be found in the dependency handling section.

%description

  • Few sentences about the project and its uses. It will be displayed by package management software.

%prep section

  • Unpacks the sources using setup -q or manually if needed.

  • If a source file doesn’t need to be extracted, it can be copied to build directory by cp -p %SOURCE0 ..

  • Apply patches with %patch X, where X is the number of patch you want to apply. (You usually need the patch index, so it would be: %patch 0 -p1).

%build section

  • Contains project compilation instructions. Usually consists of calling the projects build system such as Ant, Maven or Make.

Sección opcional %check

  • Runs projects integration tests. Unit test are usually run in %build section, so if there are no integration tests available, this section is omitted.

%install section

  • Copies built files that are supposed to be installed into %{buildroot} directory, which represents target filesystem’s root.

%files section

  • Enumera todos los archivos que deben instalarse desde %{buildroot} en el sistema de destino.

  • Documentation files are prefixed by %doc and are taken from build directory instead of buildroot.

  • Directories that this package should own are prefixed with %dir.

%changelog

  • Contains changes to this spec file (not upstream).

  • Has prescribed format. To prevent mistakes in format, it is advised to use tool such as rpmdev-bumpspec from package rpmdevtools to append new changelog entries instead of editing it by hand.

To build RPM from this spec file save it in your current directory and run rpmbuild:

$ rpmbuild -bb helloworld.spec

If everything worked OK, this should produce RPM file ~/rpmbuild/RPMS/x86_64/helloworld-1.0-1.fc18.x86_64.rpm. You can use rpm -i or dnf install commands to install this package and it will add /usr/share/java/helloworld.jar and /usr/bin/helloworld wrapper script to your system. Please note that this specfile is simplified and lacks some additional parts, such as license installation.

Paths and filenames might be slightly different depending on your architecture and distribution. Output of the commands will tell you exact paths.

As you can see to build RPM files you can use rpmbuild command. It has several other options, which we will cover later on.

Other than building binary RPMs (-bb), rpmbuild can also be used to:

  • compilar únicamente RPM de código fuente (SRPM), es decir, los paquetes que contienen archivos de código fuente que posteriormente se pueden compilar como RPM (opción -bs)

  • compilar todo, tanto los RPM binarios como los de código fuente (opción -ba)

See rpmbuild 's manual page for all available options.

Consultar repositorios

Fedora incluye varias herramientas útiles que pueden resultar de gran ayuda a la hora de obtener información de los repositorios RPM.

dnf repoquery is a tool for querying information from RPM repositories. Maintainers of Java packages might typically query the repository for information like "which package contains the Maven artifact groupId:artifactId".

Averigua cual paquete contiene un artefacto determinado
$ dnf repoquery --whatprovides 'mvn(commons-io:commons-io)'
apache-commons-io-1:2.4-9.fc19.noarch

El ejemplo anterior muestra que se puede acceder al artefacto commons-io:commons-io instalando el paquete apache-commons-io.

By default, dnf repoquery uses all enabled repositories in DNF configuration, but it is possible to explicitly specify any other repository. For example following command will query only Rawhide repository:

$ dnf repoquery --available --disablerepo \* --enablerepo rawhide --whatprovides 'mvn(commons-io:commons-io)'
apache-commons-io-1:2.4-10.fc20.noarch

A veces puede resultar útil simplemente enumerar todos los artefactos que proporciona un paquete determinado:

$ dnf repoquery --provides apache-commons-io
apache-commons-io = 1:2.4-9.fc19
jakarta-commons-io = 1:2.4-9.fc19
mvn(commons-io:commons-io) = 2.4
mvn(org.apache.commons:commons-io) = 2.4
osgi(org.apache.commons.io) = 2.4.0

Output above means that package apache-commons-io provides two Maven artifacts: previously mentioned commons-io:commons-io and org.apache.commons:commons-io. In this case the second one is just an alias for same JAR file. See section about artifact aliases for more information on this topic.

Another useful tool is rpm. It can do a lot of stuff, but most importantly it can replace dnf repoquery if one only needs to query local RPM database. Only installed packages, or local .rpm files, can be queried with this tool.

Un caso de uso habitual podría ser comprobar qué artefactos de Maven proporcionan paquetes compilados localmente.

$ rpm -qp --provides simplemaven-1.0-2.fc21.noarch.rpm
mvn(com.example:simplemaven) = 1.0
mvn(simplemaven:simplemaven) = 1.0
simplemaven = 1.0-2.fc21

Cuestionario para Desarrolladores de Java

  1. ¿Cómo crearías un RPM binario si te dieran un RPM de código fuente?

  2. What is most common content of Source0 spec file tag?

  3. ¿Cuál es la diferencia entre las etiquetas Version y Release?

  4. ¿Cómo se aplica un parche en RPM?

  5. ¿En qué parte del sistema de archivos deben guardarse los archivos JAR?

  6. ¿Cuál es el formato del registro de cambios de RPM o qué herramienta utilizarías para generarlo?

  7. How would you install an application that needs certain layout (think ANT_HOME) while honoring distribution filesystem layout guidelines?

  8. How would you generate script for running a application with main class org.project.MainClass which depends on commons-lang jar?

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