Differences between revisions 10 and 11
Revision 10 as of 2010-02-07 22:45:20
Size: 3567
Revision 11 as of 2010-04-13 19:38:24
Size: 3581
Comment: add category
Deletions are marked like this. Additions are marked like this.
Line 91: Line 91:

Topics to talk about at FOSDEM 2010 regarding Debian-Java:

  • Status of Java Policy
  • Status of maven-repo
  • Merge of javahelper and maven-repo-helper?
  • Dependencies - versioned or not?
  • Versioned .jar files? why? parallell installation?
  • CDBS vs. Debhelper7, dh -with maven?
  • why it's useful to package Java software, Java packaging is way behind python packaging
  • Bridging two great packaging systems: Debian apt and Maven
  • OSGi in Debian: the promise of always on, always up-to-date systems
  • Problem of multiple dot versions of libraries
  • How to determine the classpath
    • for compilation
    • for testing
    • for running
  • How to write good init scripts for java daemons?
  • run unittests on buildtime?
  • How to be a good java upstream
    • Have a tar.gz without precompiled stuff and convenience copies of code
    • document, where your dependencies where downloaded from
    • make your build.xml configurable
      • possibility to point to an external directory with jars
      • maybe provide a variable at the first position of your classpath which can also be used by developers to place override jars
      • possibility to easily exclude parts of the build for which we don't have the dependencies yet
      • possibility to easily exclude some contribs
      • don't assume specific dot versions of your dependencies
    • Maybe provide a page Java/UpstreamHints where we can point upstream to in case we want to suggest something

  • Best practices
  • How to have API-Docs and eventually source code available in IDEs like eclipse when developing against java libraries in /usr/share/java?
  • PROPOSAL: generally use pom files to install jars. This can be a standard format to describe versioned dependencies, etc. If upstream is not yet in maven, just use debian as organization.
  • rename default-jdk-builddep

Best Practices

  • short description of a workflow with git, topgit and pristine-tar
  • debian/build.xml to avoid patching upstream build.xml
  • debian/ant.properties
  • ... (add your own ideas)


Most upstream tarballs include convenience copies of dependency jars. These can not be used to build debian packages. To avoid patching the upstream build.xml one can also link the required jar files from /usr/share/java to the directories where upstream expects them.

The following snippets help with linking and unlinking the jars. They link only those jars defined in debian/control#Build-Depends and thus also help to get the build depends right. I'd propose to include these snippets in the javahelper package or somewhere alike.

# script to link required jar files from /usr/share/java


if [ -z $DESTINATION ]
  echo "missing destination"
  exit 1

BUILDDEPENDS=$(grep-dctrl --no-field-names --show-field Build-Depends -F source zookeeper debian/control | tr " ," "\n" | grep -v "^$" )

  echo "linking .jar files of $DEPENDENCY:"
  JARS=$(dpkg -L $DEPENDENCY | grep "^/usr/share/java/.*\.jar$")
  for JAR in $JARS
    echo "  link $JAR"

# debian/rules file using the above script

        debian/linkjars.sh lib
        debian/linkjars.sh src/java/lib

        find lib -lname "/usr/share/java/*.jar" -exec rm {} \;
        find src/java/lib -lname "/usr/share/java/*.jar" -exec rm {} \;

FOSDEM slides CategoryJava