Ubuntu Wiki

Summary

A lot of Java applications use Maven (and associated maven plugins) as their build system. In order to package this software as appropriate Debian packages, a lot of changes need to be applied to the usual Maven process. This document outlines the known issues and proposed solutions.

Release Note

It is now possible to package Maven-based Java applications like Geronimo or Glassfish in main or universe, using their native build system.

Rationale

Most recent complex Java applications leverage ASF's Maven system and artifact repository to ease the dependency resolving and building of their software. Unfortunately the usual Maven process downloads/updates needed artifacts (JARs), Maven plugins and build/runtime dependency information (.pom files) from the Maven repositories into a local repository cache and works from there. This is incompatible with the way our buildd system works, and with the idea of repeatable builds in general. Given the power of the Maven plugins-based build system, working around Maven to build those complex packages without it is almost impossible.

Use Cases

• Alan in an Ubuntu developer. He wants to package Geronimo in universe, but Geronimo uses Maven. He uses our modified Maven, the packaged Java libraries and Maven plugins to write a fully-offline and repeatable package, compatible with our buildd system.
• Betty is a Java developer. She wants to use Maven to build her own Java software. Fortunately, the new Maven doesn't prevent her from using Maven the usual way, setting up a local repository that downloads and updates files from the official Maven repositories.

Assumptions

Design

Identified incompatibilities with buildd

• Online dependency download/update: Maven downloads needed build/runtime dependency information (.pom files) and resulting artifacts (Java libraries and Maven plugins) from Maven repositories on the Internet. For each item already present in the local repository, it checks if the version is up to date. We need to provide all those dependencies as part of the source or as packaged build dependencies, and disable Maven freshness check.
• Use of a specific repository: Maven doesn't use the libraries installed in /usr/share/java, it only uses its own local repository. Since the required Java libraries build dependencies will be pulled as packages, Maven needs to make use of those.
• Maven relies on specific versions of libraries: in the .pom files, each artifact can depend on a very specific version of a given JAR, which is usually different from the one in the Ubuntu repositories. A dependency mapping system needs to be supported in order to match the very specific required version with the installed one while keeping Maven happy.

Additional issues

• .pom files shipping: these files need to be available for maven to resolve dependencies and build order. We have to either ship them with each Java library we package, or as a big blob of .pom files together with the source, or have a way of reconstructing them from existing Debian Depends information before calling maven.
• Maven plugins: we'll need to package the most common Maven plugins, and make Maven support the use of these system-installed plugins. However, it's common practice to have specific build-time-only helper maven-plugins built at the beginning of a large maven build, and those needs to be supported as well. For example at the start of a Geronimo build, maven builds all required geronimo-maven-plugins, then uses them together with the common maven-plugins during the rest of the build process.

Implementation

Fedora's JPackage implementation

Fedora patched maven to solve most of these issues. They provide a mvn-jpp wrapper that enables most of those patches:

• JPP repository support: makes maven use already-installed JARs
• depmap.xml: solves the dependency mapping problem by running the pom files through an XSL transformation before use. This file needs to be manually written and shipped as part of the source

Then they ship .pom files in various ways : in a big default_poms package, and together with every Java library package, and probably as part of the source.

See README of the [http://cvs.fedoraproject.org/viewcvs/rpms/maven2/F-9/ patches] at [http://fedoraproject.org/wiki/Java/JPPMavenReadme].

Possible Ubuntu implementations

...

Test/Demo Plan

(It's important that we are able to test new features, and demonstrate them to users. Use this section to describe a short plan that anybody can follow that demonstrates the feature is working. This can then be used during testing, and to show off after release. This need not be added or completed until the specification is nearing beta.)

Outstanding Issues

(This should highlight any issues that should be addressed in further specifications, and not problems with the specification itself; since any specification with problems cannot be approved.)

Discussion

CategorySpec