Differences between revisions 9 and 10
Revision 9 as of 2010-02-02 08:54:24
Size: 3511
Comment:
Revision 10 as of 2010-02-07 22:45:20
Size: 3567
Comment:
Deletions are marked like this. Additions are marked like this.
Line 88: Line 88:

----
[[attachment:slides fosdem.odp|FOSDEM slides]]

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)

(un)linkjars

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

DESTINATION=$1

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

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

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

# debian/rules file using the above script

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

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


FOSDEM slides