LucidJavaCleanupSpec

Differences between revisions 1 and 2
⇤ ← Revision 1 as of 2009-11-20 21:48:50 →
Size: 3905
Editor: 63
Comment:
← Revision 2 as of 2009-11-27 08:24:45 → ⇥
Size: 4576
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. It also covers any extra library needed for Eucalyptus in 10.04.
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.
Line 23: Line 21:

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.
Line 28: Line 30:
=== 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
Line 32: Line 49:
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 53:
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
 * Regression testing for Eucalyptus on lucid stack
Line 57: Line 60:
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. 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

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