LucidJavaCleanupSpec

Differences between revisions 1 and 6 (spanning 5 versions)
⇤ ← Revision 1 as of 2009-11-20 21:48:50 →
Size: 3905
Editor: 63
Comment:
← Revision 6 as of 2009-11-30 12:51:35 → ⇥
Size: 4940
Editor: lns-bzn-48f-81-56-218-246
Comment:
Deletions are marked like this. Additions are marked like this.
Line 5: Line 5:
 * '''Contributors''': ThierryCarrez
 * '''Packages affected''':		  * '''Contributors''': ThierryCarrez, MatthiasKlose
 * '''Packages affected''': jetty6, jetty and lots of other libraries
Line 10: Line 10:
This should provide an overview of the issue/functionality/change proposed here. Focus here on what will actually be DONE, summarising that so that other people don't have to read the whole spec. See also CategorySpec for examples. 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.
Line 14: Line 14:
This section should include a paragraph describing the end-user impact of this change. It is meant to be included in the release notes of the first release in which it is implemented. (Not all of these will actually be included in the release notes, at the release manager's discretion; but writing them is a useful exercise.)

It is mandatory.		 Several improvements have been applied to the 10.04 Java library stack in order to increase its maintainability.
Line 20: Line 18:
This should cover the _why_: why is this change being proposed, what justifies it, where we see this justified. 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.
Line 24: Line 22:
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.
Line 25: Line 25:

None.
Line 28: Line 30:
You can have subsections that better describe specific parts of the issue. === Identified issues ===
 * 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

=== Abandoned ===
 * 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
Line 32: Line 53:
This section should describe a plan of action (the "how") to implement the changes discussed. Could include subsections like:

=== UI Changes ===

Should cover changes required to the UI, or specific UI that is required to implement this

=== Code Changes ===

Code changes should include an overview of what needs to change, and in some cases even the specific details.

=== Migration ===

Include:
 * data migration, if any
 * redirects from old URLs to new ones, if any
 * how users will be pointed to the new way of doing things, if necessary.		 See blueprint whiteboard for specific work items.
Line 51: Line 57:
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. Please add an entry to http://testcases.qa.ubuntu.com/Coverage/NewFeatures for tracking test coverage.

This need not be added or completed until the specification is nearing beta.		 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
Line 57: Line 63:
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.

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.

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. Detailed rationale for each fix is mentioned in the Design chapter.

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.

Assumptions

None.

Design

Identified issues

  • 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

Abandoned

  • 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

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

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

LucidJavaCleanupSpec (last edited 2009-11-30 12:51:35 by lns-bzn-48f-81-56-218-246)