Ant

Apache Ant is a Java library and command-line tool whose mission is to drive processes described in build files as targets and extension points dependent upon each other.

— http://ant.apache.org/

Apache Ant is probably second most used Java build tool right 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.

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.