Java Gentoo Development

Java Ebuild writing guide

Links

• Official Guide

General

• The jar names should not contain version number, if you need to rename them, there is an eclass for that: java-pkg_newjar.

• If a package provides differents APIs, the package should be always SLOTed based on the version of the API.

• If you use eclasses such as java-pkg_getjars twice, the jars will be recorded twice in package.env.

• If some library needs to be used only during the build, use java-pkg_getjars --buildonly. The dependency won't be recorded into package.env.

• To get the dependencies of one library (during ebuild writing), use --with-dependencies. Note that this is a java-config option.

• The following eclass can be used to rewrite an Ant buildfile with your own classpath. The program actually used is /usr/bin/xml-rewrite-2.py, and you can look at the source code to see exactly what can be done.

java-ant_xml-rewrite -f build.xml --change -e java -a classpath -v "${sitemesh_classpath}" || die

Note that the file that has to be rewritten must be valid XML. If it is an included file, just rewrite the file that includes it. It will just get embedded in the included file.

• Creating a launcher is very easy - just use the java-pkg_dolauncher eclass. Just be careful that if you use any argument at all (such as --jar or --main), you will also need to specify the name of the launcher as the first argument).

• USE flags that should be handled by Java eclasses functions (such as doc and source) should be in the variable JAVA_PKG_IUSE rather than IUSE. Note that this variable must be defined at the top of the ebuild. Note that one benefit of this is that it adds the necessary DEPEND (app-arch/zip for source, as an example).

Ant

• Inheriting java-ant-2 adds dev-java/ant-core in DEPEND, so no need to add it explicitly.

• If a package installs an Ant task, it should be registered in src_install() with java-pkg_register-ant-task. There should also be an RDEPEND on >=dev-java/ant-core-1.7.0.

• If the package uses an Ant build system with hardcoded classpath inside the build.xml (example: classpath="lib/helper_library.jar"), the best way currently it to use the eclass java-pkg_jarfrom to create a symlink to the Gentoo installed version.

• ANT_TASKS can be set (and should be set) manually on the ebuild, but only in src_compile() or src_test(). Note that ANT_TASKS basically controls the Ant class path, which is different than the one for javac. So -Dgentoo.classpath, for example, does not affect Ant classpath. Nor does it affect the classpath for the <java> task (although this seems to be in development). Currently it only interacts with the classpath for the <javac> task.

• Beware the value of the property build.compiler in Ant files. It can produce bugs, this value may be safely switched to "modern" most of the time.

• Use ant-nodeps if you need optional Ant tasks that don't need any third party library.

Source and Target

• When compiling Java code, there are two important options to Ant/javac: -source and -target. -target is the version of the bytecode that will be produced. -source is the version of the Java source. Note that necessarily, target >= source.

• Normally the values of source and target (that will later be used when compiling through the rewriting of the Ant build file) are obtained by looking at DEPEND and RDEPEND virtual/jdk atoms. You can override this via the variables JAVA_PKG_WANT_SOURCE and JAVA_PKG_WANT_TARGET.

Default Functions

• src_configure will rewrite the Ant build file. It is called before src_compile but after src_unpack. JAVA_ANT_REWRITE_CLASSPATH will add gentoo.classpath as a classpath to all javac tasks.

Setup

• Set JAVA_PKG_STRICT=1 in your /etc/make.conf.

• Report bugs in Java packages both in the main tree and the java-overlay. Don't report bugs in the experimental overlay though.

Java Development Guide (Python)

• When working with java-config (the main program used by the Gentoo system), don't forget that it initially imports source files from the system location. If you are doing development make sure the correct Python source files are used. This is also true for depend-java-query.

• The class EnvironmentManager maintains a list of Virtual Machines and Packages available.

• The class VersionManager deals with the version string parsing and comparisons. version_satisfies(self, dependencyString, virtualMachine) is useful: given a dependency string and a VM, it returns True if the VM satisfies the dependency string.

• A dependency string for java-config is of the form >=virtual/(jdk|jre)-1.4. See Python source file VersionManager.py for the exact regular expression used.

• java-config can determine the current active VM via the environment variable GENTOO_VM.

• depend-java-query is the program used to find the VM needed at build time; gjl is the Gentoo Java Launcher. It gets invoked by the packages that have a launcher installed. Both programs then call java-config afterwards.

• The eclass currently coded for Java virtuals only deal with the writing of the correct configuration files to disk.

• Doing development with java-config-2 is possible easily if you symlink the program to your development space. Eg:

ln -s /home/elvanor/development/gentoo/virtuals/depend-java-query /usr/bin/depend-java-query

• Warning, depend-java-query needs the -p (--need-virtual) option before the --get-vm one. Else it will be ignored.