Launchpad Entry: server-lucid-java-library-fixes
Packages affected: jetty6, jetty and lots of other libraries
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.
Several improvements have been applied to the 10.04 Java library stack in order to increase its maintainability.
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. Detailed rationale for each fix is mentioned in the Design chapter.
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.
- Some libraries use a arch-specific recommends and build arch:any to avoid recommending -gcj libraries on i386/amd64
- Rationale: building a Java library arch:any only for the sake of generating arch-specific recommends/suggests is both costly in terms of resources and technically incorrect.
- Moving to suggests would be acceptable in Ubuntu, but not in debian. Options are:
- Fix it in Ubuntu : creates permanent delta
- Use macros in control that would get set in dh_nativejava (gcc-defaults) : needs debian to accept the change
- 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.
Rationale: We duplicate code and features between the jetty (full, universe) and the jetty6 (libraries-only, main) packages. Adopting the Debian jetty package in main (replacing our jetty6 package) allows to benefit from future jetty updates on the debian side.
MIR jetty package, have it replace the jetty6 package and get rid of jetty6
Other improvements (targets of opportunity)
- Check gwt/swt-3.5 to see if we can get rid of swt-3.4
- Rationale: Only maintain a single SWT version in main
- Check if eucalyptus-commons-ext really needs jruby dependency
- Rationale: Do not include jruby1.2 in main for Lucid since we have trouble enabling its testsuite
- Three versions of asm are in main (asm, asm2, asm3), maybe it's possible to converge to using only two or one of them
- The three major versions API are specifically incompatible, so they should all be kept
See blueprint whiteboard for specific work items.
- jetty6 upgrade
- GCJ recommends: test on [arm ia64 powerpc] that the -gcj package is recommended, test on [i386 amd64] that it's suggested
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
- 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)