Ant

Apache Ant es una biblioteca Java y una herramienta de línea de comando cuya misión es conducir los procesos en los archivos creado como objetivos y puntos de extensión dependientes unos de otros.

Apache Ant is one of the most popular Java build tools after Apache Maven. The main difference between these two tools is that Ant is procedural and Maven is declarative. When using Ant, it is neccessary to exactly describe the processes which lead to the result. It means that one needs to specify where the source files are, what needs to be done and when it needs to be done. On the other hand, Maven relies on conventions and doesn’t require specifying most of the process unless you need to override the defaults.

If upstream ships a Maven POM file, it must be installed even if you don’t build with Maven. If not, you should try to search Maven Central Repository for it, ship it as another source and install it.

Archivo de especificaciones común
BuildRequires: ant
BuildRequires: javapackages-local
...
%build
ant test

%install
%mvn_artifact pom.xml lib/%{name}.jar

%mvn_install -J api/

%files -f .mfiles
%files javadoc -f .mfiles-javadoc
Details

  • %build section uses ant command to build the project and run the tests. The used target(s) may vary depending on the build.xml file. You can use ant -p command to list the project info or manually look for <target> nodes in the build.xml file.

  • %mvn_artifact macro is used to request installation of an artifact that was not built using Maven. It expects a POM file and a JAR file. For POM only artifacts, the JAR part is omitted. See [_installing_additional_artifacts] for more information.

  • %mvn_install performs the actual installation. Optional -J parameter requests installation of generated Javadoc from given directory.

  • This method of artifact installation allows using other XMvn macros such as %mvn_alias or %mvn_package.

  • %mvn_install generates .mfiles file which should be used to populate %files section with -f switch. For each subpackage there would be separate generated file named .mfiles-subpackage-name.

  • All packages are required to own directories which they create (and which are not owned by other packages). JAR files are by default installed into subdirectory of %{_javadir}. To override this behavior, use %mvn_file.

Apache Ivy

Apache Ivy provides an automatic dependency management for Ant managed builds. It uses Maven repositories for retrieving artifacts and supports many declarative features of Maven such as handling transitive dependencies.

XMvn admite la resolución local de artefactos Ivy, su instalación y requiere generación.

Archivo spec
BuildRequires: ivy-local
...
%build
ant -Divy.mode=local test

%install
%mvn_artifact ivy.xml lib/sample.jar

%mvn_install -J api/

%files -f .mfiles
%files -javadoc -f .mfiles-javadoc
Details

  • -Divy.mode=local tells Ivy to use XMvn local artifact resolution instead of downloading from the Internet.

  • Si hay un ivy-settings.xml o archivo similar, el cual especifica repositorios remotos, necesita ser deshabilitado, de lo contrario, anularía la resolución local.

  • %mvn_artifact supports installing artifacts described by Ivy configuration files.

  • %mvn_install performs the actual installation. Optional -J parameter requests installation of generated Javadoc from given directory.

Manipulación de archivos Ivy

A subset of macros used to modify Maven POMs also work with ivy.xml files allowing the maintainer to add / remove / change dependencies without the need of making patches and rebasing them with each change. You can use dependency handling macros %pom_add_dep, %pom_remove_dep, %pom_change_dep and generic %pom_xpath_* macros. For more details, see corresponding manpages.

# Eliminar la dependencia del artefacto con org="com.ejemplo" y
# nombre="java-proyecto" desde el archivo ivy.xml en el directorio actual
%pom_remove_dep com.example:java-project

# Añade una dependencia del artefacto con org="com.example" y
# name="foobar" a ./submodule/ivy.xml
%pom_add_dep com.ejemplo:foobar submodule
Utilizar la tarea ivy:publish

Ivy supports publishing built artifact with ivy:publish task. If your build.xml file already contains a task that calls ivy:publish, you can set the resolver attribute of the ivy:publish element to xmvn. This can be done with simple %pom_xpath_set call. Then when the task is run, XMvn can pick the published artifacts and install them during the run of %mvn_install without needing you to manually specify them with %mvn_artifact.

Archivo spec utilizando la tarea ivy:publish
BuildRequires: ivy-local
...
%prep
%pom_xpath_set ivy:publish/@resolver xmvn build.xml

%build
ant -Divy.mode=local test publish-local

%install
%mvn_install -J api/

%files -f .mfiles
%files -javadoc -f .mfiles-javadoc
Details

  • Es posible que el destino de publicación sea nombrado diferentemente. Busca la build.xml para las apariciones de ivy:publish.

  • %mvn_install instalará todos los artefactos publicados.

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