LucidJavaCleanupSpec

Revision 2 as of 2009-11-27 08:24:45

Clear message

Summary

With Lucid ending up being 10.04 LTS, we need to take special care to clean up Java libraries before committing to support them for 5 years on Ubuntu Server. This spec lists specific actions that should be taken during the Lucid cycle, including some targets of opportunity. It also covers any extra library needed for Eucalyptus in 10.04.

Release Note

Several improvements have been applied to the 10.04 Java library stack in order to increase its maintainability.

Rationale

In order to reach the objectives of introducing Eucalyptus in main in Jaunty and Karmic, several shortcuts were used. With Lucid being LTS, we need to clean up some of the shortcuts used in the past in order to ease the maintenance of the Lucid Java library stack for the next 5 years.

User stories

As an Ubuntu developer, I want to be able to easily maintain the Java library stack for 5 years on servers. I use the 10.04 library stack, which is more coherent and reduces unnecessary code duplication, and it makes my life better.

As a Eucalyptus packager, I need to have all Eucalyptus 1.7 libraries available. I use the 10.04 Java library stack and it provides me with the necessary libraries.

Assumptions

Design

Identified issues

  • Some libraries use a arch-specific recommends and build arch:any to avoid recommending -gcj libraries
    • Moving to suggests would be acceptable in Ubuntu, but not in debian
    • Fix it in Ubuntu : creates permanent delta
    • Use macros in control that would get set in dh_nativejava (gcc-defaults?) : needs forward change to debian
    • dpkg-gencontrol look for -gcj in recommends and move them to suggests : a little hackish

  • jetty package in Debian has been upgraded to 6.x, so it duplicates features from the Ubuntu jetty6 package.

    • MIR jetty package, have it replace the jetty6 package and get rid of jetty6
  • Other library upgrades during debian sync might have broken Eucalyptus and require fixing
  • Some new libraries might be needed for Eucalyptus 1.7 features

Other improvements

  • Check gwt/swt-3.5 to see if we can get rid of swt-3.4
  • Check if eucalyptus-commons-ext really needs jruby dependency
  • Three versions of asm are in main (asm, asm2, asm3), maybe it's possible to converge to using only two or one of them

You can have subsections that better describe specific parts of the issue.

Implementation

See blueprint whiteboard for specific work items.

Test/Demo Plan

Test cases:

  • jetty6 upgrade
  • GCJ recommends: test on [arm ia64 powerpc] that the -gcj package is recommended, test on [i386 amd64] that it's suggested
  • Regression testing for Eucalyptus on lucid stack

Unresolved issues

None.

BoF agenda and discussion

UDS discussion notes

Lots of Java libraries were added to main following introduction of Eucalyptus in karmic. Since lucid is LTS, we need to review what can be done to clean up before committing to support those for 5 years.

TODO for Lucid

  • We use "jetty6" for Jetty libraries in main, although recent syncs brought the "jetty" package to version 6.
    • MIR process, needs to start asap
  • Changes in eucalyptus

    • Maybe c3p0 -> ??

    • Testing needed for new java stack in Lucid

Targets of opportunity

  • Drop GCJ support (get rid of the arch:any hack for -gcj packages where we don't want to recommend gcj)
    • Moving to suggests would be acceptable in Ubuntu, but not in debian

    • Fix it in Ubuntu -> delta

    • Use macros in control that would get set in dh_nativejava (gcc-defaults?) (and forward change to debian)
    • dpkg-gencontrol look for -gcj in recommends and move them to suggests
  • Try gwt with swt-3.5
  • Evaluate if possible to cripple eucalyptus-commons-ext even more to exclude jruby dep

Deferred

  • We currently support three versions of asm in main. Maybe we can make them all converge to use the latest.
    • Needs analysis
  • eucalyptus-commons-ext contains eucalyptus-centric versions of several other libraries, maybe there is still room for improvement.
    • No easy way out for Lucid (apart from moving all JBoss 4.2 to main -- very unlikely for Lucid)

CategorySpec