MavenSupportSpec

Differences between revisions 1 and 17 (spanning 16 versions)
⇤ ← Revision 1 as of 2008-07-18 15:59:40 →
Size: 5152
Editor: astatine
Comment:
← Revision 17 as of 2008-09-26 10:11:14 → ⇥
Size: 12394
Editor: lns-bzn-48f-81-56-218-246
Comment:
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
 * '''Launchpad Entry''': UbuntuSpec:maven-packaging-support
 * '''Created''': Jul 18th, 2008
 * '''Contributors''': ThierryCarrez, LuisArias
 * '''Packages affected''': none (only new packages)
Line 3: Line 8:
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. 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, in particular to avoid the online dependency resolving feature of Maven. This document presents a solution to this problem and details the minimal work needed before we can start packaging a minimal Maven project.
Line 7: Line 12:
It is now possible to package Maven-based Java applications like Geronimo or Glassfish in main or universe, using their native build system. The infrastructure making it possible to package Maven-based Java applications like Geronimo or Glassfish in main or universe is now in place.
Line 11: Line 16:
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. 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 on the Intenet 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.
Line 15: Line 20:
 * Alan in an Ubuntu developer. He wants to package Geronimo in universe, but Geronimo uses Maven. He uses our new mvn command, 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.		  * Alan in an Ubuntu developer. He wants to package Geronimo in universe, but Geronimo uses Maven. He is able to use the Maven packaging method and the already-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, this method doesn't modify Maven in any way so it doesn't prevent her from using Maven the usual way, setting up a local repository that downloads and updates files from the online Maven repositories.
Line 20: Line 25:
Software using Maven to build is usually very large and requires lots of dependencies. Even once the basic blocks described in this document are in place, packaging any large Java software will require lots of external packaging work to have all the required Java libraries available as proper Debian packages to build-depend from. So keep in mind that this might just be the visible tip of the iceberg.
Line 22: Line 29:
=== Identified incompatibilities with buildd === === Why we can't just call maven in debian/rules ===
Line 26: Line 33:
 * 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.
Line 28: Line 34:
=== Additional issues === === How to use maven in a debian package ===
Line 30: Line 36:
 * .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.		 The proposed method is based on two principles:
 * Simulate a complete Maven local repository in a debian/mvn_repo directory by shipping all required POM files and replace every JAR with a symbolic link to the corresponding system-installed library
 * Call mvn using the "-o" (offline mode) to avoid any superfluous online freshness check and the "-s" option to make it use the mvn_repo directory as its repository.

How do you know what is necessary to put in the mvn_repo directory ? Just let maven build it from scratch for you, and then proceed in replacing all JARs by symbolic links. Since you can't just ship symbolic links in the diff.gz file, you need to have a script that will recreate them for you before building. Here is the method to follow, step-by-step:
 * Create an empty debian/mvn_repo directory
 * Create a debian/mvn_settings.xml file with <localRepository>./debian/mvn_repo</localRepository>
 * Run the Maven commands required to build the software, with the "-s debian/mvn_settings.xml" parameter (example: "mvn -s debian/mvn_settings.xml package"). That will download everything required by maven (POMs and JARs) into debian/mvn_repo.
 * Add a "link_mvn_repo" target to debian/rules that must run before any mvn call (build)
 * In the "clean" target of debian/rules, add a line to remove all links in mvn_repo (after mvn clean calls)
 * In debian/rules, call mvn with the "-o" and "-s debian/mvn_settings.xml" parameters
 * For all JARs in debian/mvn_repo, check that you have an acceptable corresponding JAR in an existing package (if not, you'll have to package that first). Remove the JAR from mvn_repo, and add a line in the link_mvn_repo target that will create a link to the system-installed equivalent (example: ln -s /usr/share/java/plexus-utils.jar debian/mvn_repo/org/codehaus/plexus/plexus-utils/1.0.4/plexus-utils-1.0.4.jar). Add the corresponding build dep to debian/control.
 * The package will be policy-compliant when there is no more JARs in mvn_repo !

=== Potential issues ===

 * 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. Extra care in testing is needed to double-check that using a slightly different JAR version doesn't make it break at build or at runtime.

=== Alternative solutions (for reference) ===

==== JPackage patchset to Maven ====

The JPackage patchset is implemented in Fedora. It patches maven so that, when called with specific options, it supports using JARs installed in /usr/share/java directly. The POM files are shipped together with the Java libraries. A depmap.xml file converts Maven artifact names to system file locations. It is built from depmap fragments shipped with each Java library.

The advantage of this solution is to ship Maven-related information inside the Java library packages themselves, and rely on that system to automatically find the required JARs. However, it requires a heavy patch on Maven that must be maintained, a basic infrastructure that is very costly to put in place (refresh every JAR), and the system might be brittle because it doesn't freeze the POM information in a state that is necessarily compatible with the build you are trying to make (debugging of dependency issues is more complicated).

==== Packaging Aware Maven Proxy ====

In this approach, we would run a Maven proxy that would solve all dependency mapping and let Maven build a repository at build-time that downloads artifacts from the system itself. Maven would be run with a settings file that point to the local proxy, and the maven proxy would be launched prior to launching a maven build process.

The proxy would need to have the following features:

 * Generate pom.xml files upon request according to debian packaging dependencies
 * Map request artifact versions to existing artifact versions
 * Serve jar files from /usr/share/java
 * Block access to the internet

The advantages of this approach is that it doesn't require any Maven patching. However, building the maven proxy is complex, and starting a localhost daemon in parallel to a build might not be the best solution for buildds.
Line 35: Line 77:
=== Fedora's JPackage implementation === The chosen approach doesn't require any specific development or infrastructure by itself. However, it would be good to provide at least the mimimal build dependencies required by even the simplest helloWorld maven project. Indeed, simply calling the Maven "clean", "compile" or "package" targets requires some dependencies to be present, and at the very least those should be packaged and available for the first Maven packager to use.
Line 37: Line 79:
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		 === Maven dependencies for a helloWorld project ===
Line 41: Line 81:
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. (in bold, non-existing packages)
Line 43: Line 83:
See [http://cvs.fedoraproject.org/viewcvs/rpms/maven2/F-9/ patches] and
[http://cvs.fedoraproject.org/viewcvs/*checkout*/rpms/maven2/F-9/maven2-jpp-readme.html?rev=1.1 explanation].		 ||<rowbgcolor="#cccccc"> '''Target''' || '''Artifacts''' ||
|| clean || '''maven-clean-plugin''' '''file-management''' '''maven-shared-io''' plexus-utils ||
|| compile || '''maven-resources-plugin''' '''maven-compiler-plugin''' plexus-compiler-api plexus-compiler-javac plexus-utils plexus-compiler-manager ||
|| test || junit '''surefire-junit''' '''surefire-api''' '''surefire-booter''' '''maven-surefire-plugin''' plexus-utils ||
|| package || commons-lang '''maven-archiver''' '''maven-jar-plugin''' '''plexus-archiver''' plexus-utils '''plexus-io''' ||
Line 46: Line 89:
=== Possible Ubuntu implementations === === Bootstrapping ===
Line 48: Line 91:
Fortunately we don't really need maven to build those missing basic blocks. They can be built using ant with minimal effort. Here is a breakdown of the order in which the new packages can be created. maven-plugin-testing-harness.jar is optional, needed only to enable testing in the maven plugins build.

||<rowbgcolor="#cccccc"> '''JAR''' || '''Runtime & Compile depends''' || '''Testing depends''' ||
||<-3 #eeeeee> Level 0 (can be done using current archive) ||
|| surefire-api.jar || commons-lang plexus-utils || jmock ||
|| plexus-archiver.jar || plexus-component-api plexus-container-default plexus-utils || junit ||
|| plexus-io.jar || plexus-component-api plexus-container-default || junit ||
|| maven-shared-io.jar || classworlds junit maven wagon-provider-api plexus-utils plexus-container-default || easymock ||
||<#FFEBBB> maven-plugin-testing-harness.jar || maven junit || ||
||<-3 #eeeeee> Level 1 (needs level 0) ||
|| surefire-booter.jar || surefire-api plexus-utils || jmock ||
|| surefire-junit.jar || surefire-api || jmock ||
|| file-management.jar || classworlds maven maven-shared-io wagon-provider-api plexus-container-default plexus-utils || junit ||
|| maven-archiver.jar || maven plexus-archiver plexus-utils || ||
|| maven-resources-plugin.jar || maven || maven-plugin-testing-harness ||
|| maven-compiler-plugin.jar || classworlds junit maven plexus-compiler-api plexus-compiler-manager plexus-container-default plexus-utils plexus-compiler-javac || jsch commons-cli doxia-sink-api maven-plugin-testing-harness wagon-file wagon-http-lightweight wagon-provider-api wagon-ssh plexus-interactivity-api ||
||<-3 #eeeeee> Level 2 (needs level 1) ||
|| maven-surefire-plugin.jar || maven surefire-booter || jmock ||
|| maven-jar-plugin.jar || commons-lang maven-archiver plexus-io plexus-utils || maven-plugin-testing-harness ||
|| maven-clean-plugin.jar || classworlds junit file-management maven-shared-io maven wagon-provider-api plexus-container-default plexus-utils || jsch commons-cli doxia-sink-api maven-plugin-testing-harness wagon-file wagon-http-lightweight wagon-ssh plexus-archiver plexus-interactivity-api ||

If this spec is accepted, packaging-needed bugs would be filed (first Level 0 ones, then Level 1...)

=== Directions for packagers ===

==== Location for Maven-specific libraries ====

Lots of dependencies are Maven-specific, in particular the Maven plugins. It might make sense not to ship those libraries into /usr/share/java but rather as a subdirectory of /usr/share/maven2. Since we use links from m2_repo, from our point of view the location doesn't matter, and it would avoid crowding the /usr/share/java directory with JARs that can only be called by Maven. Note that it might even be possible to configure Maven so that it automatically includes JARs in /usr/share/maven2/plugins to its classpath, reducing the work needed to link always-present artifacts from mvn_repo.
Line 51: Line 122:
(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.) We should provide Debian packaging for a minimal helloWorld Maven project.
Line 55: Line 126:
(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.) None.
Line 59: Line 130:
I noticed the following tools which may be of some use too ? :
 * mvn-pkg-plugin : http://wiki.evolvis.org/mvn-pkg-plugin
 * jdeb : http://vafer.org/projects/jdeb
Hope this helps -- OlivierBerger

afaict those tools make installable debian binary packages but cannot be used to create packaging compliant with the buildd rules (no access to the Internet, all must be built from source and existing dependencies, no binaries in source) and therefore probably can't be used -- ThierryCarrez

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, in particular to avoid the online dependency resolving feature of Maven. This document presents a solution to this problem and details the minimal work needed before we can start packaging a minimal Maven project.

Release Note

The infrastructure making it possible to package Maven-based Java applications like Geronimo or Glassfish in main or universe is now in place.

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 on the Intenet 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 is able to use the Maven packaging method and the already-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, this method doesn't modify Maven in any way so it doesn't prevent her from using Maven the usual way, setting up a local repository that downloads and updates files from the online Maven repositories.

Assumptions

Software using Maven to build is usually very large and requires lots of dependencies. Even once the basic blocks described in this document are in place, packaging any large Java software will require lots of external packaging work to have all the required Java libraries available as proper Debian packages to build-depend from. So keep in mind that this might just be the visible tip of the iceberg.

Design

Why we can't just call maven in debian/rules

  • 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.

How to use maven in a debian package

The proposed method is based on two principles:

  • Simulate a complete Maven local repository in a debian/mvn_repo directory by shipping all required POM files and replace every JAR with a symbolic link to the corresponding system-installed library
  • Call mvn using the "-o" (offline mode) to avoid any superfluous online freshness check and the "-s" option to make it use the mvn_repo directory as its repository.

How do you know what is necessary to put in the mvn_repo directory ? Just let maven build it from scratch for you, and then proceed in replacing all JARs by symbolic links. Since you can't just ship symbolic links in the diff.gz file, you need to have a script that will recreate them for you before building. Here is the method to follow, step-by-step:

  • Create an empty debian/mvn_repo directory

  • Create a debian/mvn_settings.xml file with <localRepository>./debian/mvn_repo</localRepository>

  • Run the Maven commands required to build the software, with the "-s debian/mvn_settings.xml" parameter (example: "mvn -s debian/mvn_settings.xml package"). That will download everything required by maven (POMs and JARs) into debian/mvn_repo.
  • Add a "link_mvn_repo" target to debian/rules that must run before any mvn call (build)
  • In the "clean" target of debian/rules, add a line to remove all links in mvn_repo (after mvn clean calls)
  • In debian/rules, call mvn with the "-o" and "-s debian/mvn_settings.xml" parameters
  • For all JARs in debian/mvn_repo, check that you have an acceptable corresponding JAR in an existing package (if not, you'll have to package that first). Remove the JAR from mvn_repo, and add a line in the link_mvn_repo target that will create a link to the system-installed equivalent (example: ln -s /usr/share/java/plexus-utils.jar debian/mvn_repo/org/codehaus/plexus/plexus-utils/1.0.4/plexus-utils-1.0.4.jar). Add the corresponding build dep to debian/control.
  • The package will be policy-compliant when there is no more JARs in mvn_repo !

Potential issues

  • 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. Extra care in testing is needed to double-check that using a slightly different JAR version doesn't make it break at build or at runtime.

Alternative solutions (for reference)

JPackage patchset to Maven

The JPackage patchset is implemented in Fedora. It patches maven so that, when called with specific options, it supports using JARs installed in /usr/share/java directly. The POM files are shipped together with the Java libraries. A depmap.xml file converts Maven artifact names to system file locations. It is built from depmap fragments shipped with each Java library.

The advantage of this solution is to ship Maven-related information inside the Java library packages themselves, and rely on that system to automatically find the required JARs. However, it requires a heavy patch on Maven that must be maintained, a basic infrastructure that is very costly to put in place (refresh every JAR), and the system might be brittle because it doesn't freeze the POM information in a state that is necessarily compatible with the build you are trying to make (debugging of dependency issues is more complicated).

Packaging Aware Maven Proxy

In this approach, we would run a Maven proxy that would solve all dependency mapping and let Maven build a repository at build-time that downloads artifacts from the system itself. Maven would be run with a settings file that point to the local proxy, and the maven proxy would be launched prior to launching a maven build process.

The proxy would need to have the following features:

  • Generate pom.xml files upon request according to debian packaging dependencies
  • Map request artifact versions to existing artifact versions
  • Serve jar files from /usr/share/java
  • Block access to the internet

The advantages of this approach is that it doesn't require any Maven patching. However, building the maven proxy is complex, and starting a localhost daemon in parallel to a build might not be the best solution for buildds.

Implementation

The chosen approach doesn't require any specific development or infrastructure by itself. However, it would be good to provide at least the mimimal build dependencies required by even the simplest helloWorld maven project. Indeed, simply calling the Maven "clean", "compile" or "package" targets requires some dependencies to be present, and at the very least those should be packaged and available for the first Maven packager to use.

Maven dependencies for a helloWorld project

(in bold, non-existing packages)

Target

Artifacts

clean

maven-clean-plugin file-management maven-shared-io plexus-utils

compile

maven-resources-plugin maven-compiler-plugin plexus-compiler-api plexus-compiler-javac plexus-utils plexus-compiler-manager

test

junit surefire-junit surefire-api surefire-booter maven-surefire-plugin plexus-utils

package

commons-lang maven-archiver maven-jar-plugin plexus-archiver plexus-utils plexus-io

Bootstrapping

Fortunately we don't really need maven to build those missing basic blocks. They can be built using ant with minimal effort. Here is a breakdown of the order in which the new packages can be created. maven-plugin-testing-harness.jar is optional, needed only to enable testing in the maven plugins build.

JAR

Runtime & Compile depends

Testing depends

Level 0 (can be done using current archive)

surefire-api.jar

commons-lang plexus-utils

jmock

plexus-archiver.jar

plexus-component-api plexus-container-default plexus-utils

junit

plexus-io.jar

plexus-component-api plexus-container-default

junit

maven-shared-io.jar

classworlds junit maven wagon-provider-api plexus-utils plexus-container-default

easymock

maven-plugin-testing-harness.jar

maven junit

Level 1 (needs level 0)

surefire-booter.jar

surefire-api plexus-utils

jmock

surefire-junit.jar

surefire-api

jmock

file-management.jar

classworlds maven maven-shared-io wagon-provider-api plexus-container-default plexus-utils

junit

maven-archiver.jar

maven plexus-archiver plexus-utils

maven-resources-plugin.jar

maven

maven-plugin-testing-harness

maven-compiler-plugin.jar

classworlds junit maven plexus-compiler-api plexus-compiler-manager plexus-container-default plexus-utils plexus-compiler-javac

jsch commons-cli doxia-sink-api maven-plugin-testing-harness wagon-file wagon-http-lightweight wagon-provider-api wagon-ssh plexus-interactivity-api

Level 2 (needs level 1)

maven-surefire-plugin.jar

maven surefire-booter

jmock

maven-jar-plugin.jar

commons-lang maven-archiver plexus-io plexus-utils

maven-plugin-testing-harness

maven-clean-plugin.jar

classworlds junit file-management maven-shared-io maven wagon-provider-api plexus-container-default plexus-utils

jsch commons-cli doxia-sink-api maven-plugin-testing-harness wagon-file wagon-http-lightweight wagon-ssh plexus-archiver plexus-interactivity-api

If this spec is accepted, packaging-needed bugs would be filed (first Level 0 ones, then Level 1...)

Directions for packagers

Location for Maven-specific libraries

Lots of dependencies are Maven-specific, in particular the Maven plugins. It might make sense not to ship those libraries into /usr/share/java but rather as a subdirectory of /usr/share/maven2. Since we use links from m2_repo, from our point of view the location doesn't matter, and it would avoid crowding the /usr/share/java directory with JARs that can only be called by Maven. Note that it might even be possible to configure Maven so that it automatically includes JARs in /usr/share/maven2/plugins to its classpath, reducing the work needed to link always-present artifacts from mvn_repo.

Test/Demo Plan

We should provide Debian packaging for a minimal helloWorld Maven project.

Outstanding Issues

None.

Discussion

I noticed the following tools which may be of some use too ? :

Hope this helps -- OlivierBerger

afaict those tools make installable debian binary packages but cannot be used to create packaging compliant with the buildd rules (no access to the Internet, all must be built from source and existing dependencies, no binaries in source) and therefore probably can't be used -- ThierryCarrez

CategorySpec

JavaTeam/Specs/MavenSupportSpec (last edited 2009-01-07 18:40:18 by 121)