Differences between revisions 13 and 14
Revision 13 as of 2009-07-28 18:37:27
Size: 3367
Revision 14 as of 2009-08-22 11:16:31
Size: 3387
Deletions are marked like this. Additions are marked like this.
Line 73: Line 73:

There is a BoF about java packaging at 11am UTC+2:00. It won't be video'd, but we will have people on #debian-java on oftc if anyone else wants to contribute.

A second session has been scheduled at 15:30 UTC+2:00 in the lower talk room. Will also be video

I sent an email to the list to try and get opinions in advance, here is a short agenda summarising that email. Please do put other things on here.


  • Actually merging the changes from the FOSDEM draft

  • Packaging tools we need (see javahelper)

  • Recursive classpath detection
  • Other transition issues
  • Executable jars / wrappers
  • jar and wrapper locations
  • Multiarch issues
    • /usr/lib/jvm
    • /usr/lib/jni
    • multi-arch depends
  • Maven in Debian (Java/MavenBuilder, Java/MavenRepoHelper, Java/MavenRepoSpec)

  • OpenJDK
  • Jigsaw
  • major packaging projects: spring, jboss, glassfish, ...
  • getting more contributers, cooperation with Ubuntu

Random notes

  • Maybe we want a jh_classpath so we can move between ways of doing transitive classpaths more easily, rather than just jh_manifest (I've just added this to javahelper)

Notes from first session


  • Java libraries
    • don't depend on runtimes for libraries, but extend debian/control for classfile version
    • default build (via ant options / jh_build default) to java 5 bytecode
    • happy with the rest
  • GCJ-native
    • fine
  • Javadoc
    • javadoc in /usr/share/doc/package/api even if it's in package-doc
    • non-doc packages don't depend on classpath-doc
    • depends/links not in policy but best practice
  • Tests
    • don't specify 'junit' just 'automated tests
    • test failures cause package build fail based on env var?
  • arch-dependent jars
    • fine

Recursive classpath detection:

  • we want it, but should be compatible with osgi/jigsaw (tools to fix it all up)


  • doing 'sonames' with file/package naming and so on is generally a good idea, but there are some concerns about extra dev packages for the unversioned link and the work in checking for upstream transitions which they don't announce

Notes from second session

  • ok to expand locations for binaries (wrappers / executable jars)
  • ok to change to executable jars via jarwrapper and binfmt_misc
  • ok to expand jars to be in /usr/share/$program if they are private


  • /usr/lib/<triple>/jni

  • ship symlinks for transitions
  • /usr/lib/jvm <-- binaries aren't multiarched

  • JVMs should be Multiarch: allowed
  • may need to keep dependencies of library packages on runtimes so
    • that JNI packages can declare same-arch depends and pure-java packages can declare cross-arch depends


  • mjj29 to update wiki.d.o/Java to have javahelper information
  • find unmaintained libraries with no rdeps and propose removal
  • search for packages which will be rcbuggy with the new changes
  • doko to find out what the minimum amount of osgi information is
  • beta for jigsaw on PPA: https://edge.launchpad.net/~openjdk/+archive/ppa