Java Gentoo Development: Difference between revisions

From Elvanör's Technical Wiki
Jump to navigation Jump to search
mNo edit summary
mNo edit summary
 
(One intermediate revision by the same user not shown)
Line 25: Line 25:


* 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).
* 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 ===


* 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).
* 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).

Latest revision as of 11:36, 14 July 2009

Java Ebuild writing guide

Links

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

  • 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.
  • 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.
  • Use ant-nodeps if you need optional Ant tasks that don't need any third party library.
  • 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.
  • 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.

Specific Variables

  • EANT_GENTOO_CLASSPATH automatically adds to the gentoo.classpath variable the classpath of the specified packages. This is probably the easiest way to fill the compile classpath.
  • EANT_BUILD_TARGET specifies the default target that will be run by eant.

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, and is present since EAPI2. JAVA_ANT_REWRITE_CLASSPATH will add gentoo.classpath as a classpath to all javac tasks.
  • src_test should also build the test classes (that should not happen in src_compile). There is no default src_test function that would call for example eant test. In src_test however, EANT_GENTOO_CLASSPATH will automatically add --build-only option.

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.

Eclasses

  • Ant tasks packages use an eclass, that will automatically set their DESCRIPTION among other things.