Debian Java Packaging Project

Building Java Packages in Debian

It is very important to get the same results in the binary packages independent of the build environment. This means that you should use one specific JDK version and an exactly defined CLASSPATH for building your package.

• Use one specific JDK version to build the package: Build-depend on the corresponding package (don't use alternatives!), set JAVA_HOME in debian/rules and call java, javac, ... with their full path (don't use /usr/bin/java!).

  A lot of weird things may happen if you use /usr/bin/java or /usr/bin/javac since both are managed by update-alternatives. javac and java might even point to different JDK versions, so a class that gets compiled by /usr/bin/javac might not be able to run with /usr/bin/java, for example when assertions in JDK 1.4 are used.

  Some packages enable or disable extra features depending on the JDK version they were built with, for example the PostgreSQL JDBC driver builds a JDBC 1.0 version on JDK 1.1, a JDBC 2.0 version on JDK 1.2/1.3 and an extended JDBC 2.0 version on JDK 1.4 or higher.

  Another example is bug #197484: Refactoring did not work in Eclipse when it was built with JDK 1.4 and the problem went away when using JDK 1.3 - the only way to avoid getting a buggy package is to use one specific JDK in debian/rules.

  /usr/bin/java* might even point to a locally installed JDK so additional (possibly non-free) package dependencies might be pulled in, for example when new APIs like JMS or JTA are available during build time. And you don't even know about them!

  This situation is completely different from using /usr/bin/gcc or /usr/bin/g++ for C and C++ programms since they are not managed by update-alternatives. Admitted, they might point to gcc 2.95, gcc 3.2 or gcc 3.3 but they are provided by a single package and never point to a locally installed GCC version. And the library dependencies are resolved by dpkg-shlibdeps.

• Use a defined CLASSPATH. This is also important to get equal results (see above). Don't call scripts that manipulate $CLASSPATH depending on the installed packages, For example, /usr/bin/ant adds all JARs (or symlinks) in /usr/share/ant/lib/ to the class path so your package might use Commons Logging instead of another logger implementation. Your package would also have additional unnoticed dependencies in this case.
• If you are using Ant you can put ant.properties in the debian directory, call Ant with "-propertyfile path/to/debian/ant.properties" and define build.compiler, compile.debug and compile.optimize there.
• Try to use patches instead of direct modifications to upstream sources. This way you only need to keep the debian directory in the SVN repository. You can use dpatch if the upstream source consists of just one tarball or DBS for more complicated cases. Both can be integrated with cdbs.
• To update to a new upstream version, try to apply the .diff.gz from the previous version on top of the unpacked source tree. You can use uupdate from devscripts to facilitate this.

Last Modified: $Date: 2006-01-26 10:40:40 +0000 (Thu, 26 Jan 2006) $