Ant

Apache Ant es una librería Javay 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 es probablemente la segunda herramienta de creación más usada de Java después de Apache Maven. La principal diferencia entre estas dos herramientas es que Ant es procedimiental y Maven declarativa. Cuando se utiliza Ant, es necesario describir exactamente los procesos que llevan al resultado. Significa que se necesita especificar donde están los archivos fuente, que se necesita hacer y cuando debe ser hecho. De otro lado, Maven se basa en convenciones y no se requiere especificar la mayoría de los procesos a menos que se necesita anular lo predeterminado.

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.

Common spec file
BuildRequires: ant
BuildRequires: javapackages-local
...
%build
ant test

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

%mvn_install -J api/

%files -f .mfiles
%dir %{_javadir}/%{name}

%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 supports local resolution of Ivy artifacts, their installation and requires generation.

Spec file
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

  • If there is an ivy-settings.xml or similar file, which specifies remote repositories, it needs to be disabled, otherwise it would override local resolution.

  • %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

Ivy files manipulation

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.

# Remove dependency on artifact with org="com.example" and
# name="java-project" from ivy.xml file in current directory
%pom_remove_dep com.example:java-project

# Add dependency on artifact with org="com.example" and
# name="foobar" to ./submodule/ivy.xml
%pom_add_dep com.example:foobar submodule
Using the ivy:publish task

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.

Spec file using the ivy:publish task
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:

  • The publish target may be named differently. Search the build.xml for occurences of ivy:publish.

  • %mvn_install will install all the published artifacts.

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