Translation(s): English

Ant build system

Ant does not have formal conventions which means that source code can be found in different directories depending on the upstream project. It is very common that upstream developers include all build-dependencies in their source packages, so you have to be careful and make sure that all prebuilt jar or class files are removed before you upload your package.

Ant is procedural, that means you have to provide information in your build.xml how to build a package. Often the only way to influence the build process is to patch build.xml. In contrast to Maven Ant is mainly a build tool instead of a project management tool.


Electric is a electrical CAD system. The application uses Ant to build the sources. Add ant to Build-Depends and if you use dh sequencer everything else will work automatically.


 debhelper (>= 11),

Also make sure that you add the ${java:Depends} substvar to your binary package, so that javahelper (jh_depends) can automatically insert your runtime dependencies. Those are derived from the build-dependencies. Unfortunately there is no automatic way to determine runtime dependencies with javahelper.


export CLASSPATH=/usr/share/java/bsh.jar:/usr/share/java/j3dcore.jar:/usr/share/java/j3dutils.jar:/usr/share/java/vecmath.jar:/usr/share/java/slf4j-simple.jar:/usr/share/java/slf4j-api.jar:/usr/share/java/jython.jar

    dh $@ --with javahelper

Using javahelper together with an exported CLASSPATH will automatically modify the default MANIFEST file of the resulting jar file. A Class-Path entry is inserted into the MANIFEST, so that Electric properly detects all runtime dependencies.

In order to comply with the DFSG system libraries have to be used to compile the package. Since all prebuilt jar files were removed one way to achieve that is to patch build.xml.

<javac encoding="UTF-8" debug="true" includeantruntime="false" destdir="${antBuild}" srcdir="com"
   fork="true" memoryMaximumSize="1024m" source="1.7" target="1.7">
                <pathelement location="/usr/share/java/bsh.jar" />
                <pathelement location="/usr/share/java/vecmath.jar" />
                <pathelement location="/usr/share/java/j3dcore.jar" />
                <pathelement location="/usr/share/java/j3dutils.jar" />
                <pathelement location="/usr/share/java/slf4j-api.jar" />
                <pathelement location="/usr/share/java/scala-library.jar" />
                <pathelement location="/usr/share/java/jython.jar" />

As you can see the compilation is executed within a javac task block in build.xml. You can pass different options to the javac compiler similar to how it would be done on the command-line (e.g. changing the encoding and source/target values). The classpath is a nested element which contains further pathelement locations. These point to the system libraries in /usr/share/java now. The javac task is explained in more detail in the official documentation.


FreeCol is a game similar to Colonization. The Ant build system is used to compile the sources.


export CLASSPATH=/usr/share/java/cortado.jar:/usr/share/java/miglayout.jar:/usr/share/java/commons-cli.jar
export JAVA_TOOL_OPTIONS=-Dfile.encoding=UTF8

   dh $@ --with javahelper --buildsystem=ant

The package uses javahelper to install the resulting jar file with a freecol.jlibs file and also uses a freecol.classpath file to modify the MANIFEST file and update the Class-Path entry. debian/rules overwrites the file encoding value by exporting the JAVA_TOOL_OPTIONS variable. This is an alternative method to patching the build.xml file just for setting a new encoding value. Although it is not necessary in this case, it is possible to specify the buildsystem explicitly. This can be useful if more than one build system is provided by upstream.


mediathekview is an application to search for German public television streams. Version 3.3.0-1 used the Ant build system, newer versions switched to Gradle.

Interesting features of this package are a mediathekview.manifest file to manipulate the upstream MANIFEST.


 Class-Path: /usr/share/java/commons-lang3.jar /usr/share/java/commons-compress.jar /usr/share/java/swingx.jar /usr/share/java/forms.jar /usr/share/java/mac_widgets.jar /usr/share/java/jide-oss.jar
 Main-Class: mediathek.Main

The syntax is straightforward. You specify the jar file with the MANIFEST you want to modify and after that overwrite or add new entries like Class-Path and Main-Class. You could also use a debian/*.classpath file, which uses a slightly different syntax, in case you only wanted to change the CLASSPATH.

java-wrappers versus jarwrapper

Two different ways exist in Debian to start a Java application. You can either write a wrapper script and use java-wrappers or jarwrapper.

Both Electric and FreeCol use the java-wrappers method while MediathekView 3.3.0-1 used jarwrapper. The jarwrapper tool sets up binfmt-misc to run executable jars. In order to make it work you have to make your jar file executable and use javahelper (jh_depends). The tool will then add a dependency on jarwrapper which in turn activates binfmt support. Once the jar file is installed into the /usr/bin directory, you can run your Java application like any other program without having to use the java command.

Electric's wrapper script:

# Include the wrappers utility script
. /usr/lib/java-wrappers/

find_java_runtime java7

find_jars bsh jython electric
find_jars vecmath j3dcore j3dutils slf4j-simple

run_java com.sun.electric.Launcher "$@"

The find_java_runtime command is to ensure that at least a Java 7 JRE is installed on the system and find_jars will make sure that all runtime dependencies are on the CLASSPATH. Finally the run_java command will execute the Main class while still allowing users to pass arbitrary options to the binary.


lombok-ast uses a debian/linkjars file to symlink jar files from /usr/share/java into the source package's lib directory. This is useful if you want to avoid patching the build.xml file.