EucalyptusInMainSpec
10398
Comment:
|
11622
|
Deletions are marked like this. | Additions are marked like this. |
Line 26: | Line 26: |
This spec does not take care of any other non-Java MIR that Eucalyptus may need. iscsitarget for example could be a new 1.6 dependency, and it is in universe currently. == Design == |
|
Line 28: | Line 32: |
== Design == |
|
Line 32: | Line 34: |
* libhibernate3-java in eucalyptus-javadeps : saves 34+ packages * libhibernate-entity-manager in eucalyptus-javadeps : saves 10+ packages * Use glassfish-javaee instead of geronimo-* |
* Use a specific eucalyptus-hibernate package instead of generic libhibernate3-java: saves 34+ packages * Include libhibernate-entity-manager in eucalyptus-hibernate: saves 10+ packages * Include libhibernate-[commons-]annotations in eucalyptus-hibernate: saves 2 packages (?) * Use glassfish-javaee instead of geronimo-* (?) |
Line 45: | Line 48: |
|| glassfish-toplink-essentials || || libhibernate-annotations-java || | |
Line 69: | Line 71: |
|| libhibernate-annotations-java || ej || || || libhibernate-commons-annotations-java || ej || || |
|
Line 98: | Line 98: |
=== New packages expected from RefactorEucalyptusJavadepsSpec === | === New dependencies expected from Eucalyptus 1.6 === * netty 3.1 * dnsjava * eucalyptus-hibernate === Packages expected from RefactorEucalyptusJavadepsSpec === * Axiom |
Line 101: | Line 108: |
* Google Web Toolkit | * Drools * Mule * MVEL * OpenSAML/1.1 Java * WSS4J |
Line 103: | Line 114: |
* Mule | |
Line 106: | Line 116: |
* Drools * MVEL |
* Google Web Toolkit |
Line 121: | Line 130: |
Note: we would patch so that it uses: * libtomcat6-java instead on libtomcat5.5-java (avoiding libcommons-[el,launcher,modeler]-java) * tomcat6-examples instead of glassfish-appserv |
|
Line 123: | Line 136: |
|| glassfish-toplink-essentials || Spring || || | |
Line 127: | Line 141: |
|| glassfish-appserv || Spring || || | |
Line 129: | Line 142: |
|| libtomcat5.5-java || Spring || || | |
Line 135: | Line 147: |
|| libjdom0-java || libfreemarker-java, velocity || || libwerken.xpath-java || velocity || || libcommons-digester-java || libstruts1.2-java, libcommons-validator-java, libcommons-modeler-java, libtiles-java || || libcommons-validator-java || libstruts1.2-java || || libcommons-el-java || libtomcat5.5-java || || libcommons-launcher-java || libtomcat5.5-java || || libcommons-modeler-java || libtomcat5.5-java || || libcommons-beanutils-java || libtiles-java || |
|| libjdom0-java || libfreemarker-java, velocity || || || libwerken.xpath-java || velocity || || || libcommons-digester-java || libstruts1.2-java, libcommons-validator-java, libcommons-modeler-java, libtiles-java || || || libcommons-validator-java || libstruts1.2-java || || || libcommons-beanutils-java || libtiles-java || || |
Line 146: | Line 155: |
* 54 from primary list * 8 from RefactorEucalyptusJavadepsSpec * 25 from Refactor/Spring '''Total: 87 packages to MIR''' |
* 51 from primary list * 3 from new Eucalyptus deps * 11 from RefactorEucalyptusJavadepsSpec * 21 from Refactor/Spring '''Total: 86 packages to MIR''' |
Line 155: | Line 165: |
* Do a minimal Spring rather than take Debian spring, get rid of (at most) 21 packages | * Do a minimal Spring rather than take Debian spring, get rid of (at most) 17 packages * include libehcache in eucalyptus-hibernate: saves 3 packages * Get rid of WSS4J/OpenSAML dependency: saves 2 packages |
Line 159: | Line 171: |
tbd | === Create eucalyptus-hibernate === Create the specific eucalyptus hibernate libraries, containing the subset of hibernate needed for Eucalyptus and not all the JBoss hooks the libhibernate3-java package contains. Those should be shipped as the new "eucalyptus-javadeps" package (which is kept to include all the non-standard libraries required by Eucalyptus). === Implement other hacks === All the other number-reducing hacks should be implemented: * Remove dependency from libclassworlds-java -> maven-ant-helper * ... === Determine final map of MIR, split into sets === The final dependencies should be determined and splitted into sets that can be handled separately. === Process MIR sets === Several options, to be discussed with MIR team: * One bug per set, one task per package in set * One bug per package * One bug for everything * Process outside Launchpad, with one metabug to track progress |
Line 169: | Line 205: |
''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. |
Launchpad Entry: server-karmic-eucalyptus-in-main
Created: June 2nd, 2009
Contributors: ThierryCarrez
Packages affected: lots
Summary
Eucalyptus, as part of the Ubuntu Enterprise Cloud, needs to move to main to be properly supported by Canonical. That means that all runtime and build-time dependencies (and all dependencies of the dependencies) must also move to main. This specification tracks which packages will need to move to main and efforts made to reduce the total number as much as possible.
Release Note
Eucalyptus is now part of the Ubuntu "main" repository, and fully supported by Canonical.
Rationale
Eucalyptus is currently in universe, together with most of its Java library dependencies. Since Eucalyptus is part of the Ubuntu Enterprise Cloud product, it needs to be properly supported by Canonical, which means move to the "main" repository. However, packages in "main" also need to have all their runtime and build-time dependencies in "main" as well. Java software in general heavily makes use of other Java libraries, so this quickly snowballs into a large number of packages to move to main. Furthermore, there isn't so much Java-based software in main already (OpenOffice.org, tomcat6) so even some basic Java libraries need to be moved.
User stories
- Dave has been trying the UEC technology preview in 9.04 and aims to deploy UEC with the 9.10 release. As it will no longer be a technology preview, it needs to be properly supported.
Assumptions
This spec does not take care of any other non-Java MIR that Eucalyptus may need. iscsitarget for example could be a new 1.6 dependency, and it is in universe currently.
Design
We need to try to keep the number of packages as small as possible in order to avoid MIR team overload. Some hacks (like duplicating some greedy source packages to avoid bringing lots of unnecessary build dependencies) are worth the trouble if they save a significant amount of packages. However Debian doesn't care about keeping the number of dependency packages small, so those hacks don't really make sense from a Debian perspective.
Proposed actions for package number reduction
- Use a specific eucalyptus-hibernate package instead of generic libhibernate3-java: saves 34+ packages
- Include libhibernate-entity-manager in eucalyptus-hibernate: saves 10+ packages
- Include libhibernate-[commons-]annotations in eucalyptus-hibernate: saves 2 packages (?)
- Use glassfish-javaee instead of geronimo-* (?)
Remove dependency from libclassworlds-java -> maven-ant-helper: saves 8+ packages
- xmlbeans is no longer needed (Axis2 build dep) so removed libxmlbeans-java libsaxonb-java from list
- Add arch-based recommend in antlr3 + build as "any": removed antlr3-gcj from list
- Add arch-based recommend in libbcprov-java + build as "any": removed libbcprov-java-gcj from list
Resulting list (without those from RefactorEucalyptusJavadepsSpec)
Binary Package |
Runtime dep of |
Extra Build dep of |
antlr3 |
ej |
|
glassfish-javaee |
ej |
libjgroups-java |
groovy |
ej |
|
janino |
ej |
|
junit4 |
groovy |
|
libasm2-java |
ej, groovy |
|
libasm3-java |
|
ej, libjarjar-java |
libasm-java |
ej, libcglib2.1-java |
|
libaspectwerkz2-java |
|
libcglib2.1-java |
libavalon-framework-java |
ej |
|
libbackport-util-concurrent-java |
libdom4j-java, libehcache-java |
|
libbcprov-java |
ej |
libjgroups-java |
libc3p0-java |
ej |
|
libcglib2.1-java |
ej |
|
libclassworlds-java |
groovy |
|
libcommons-cli-java |
ej, groovy |
|
libcommons-codec-java |
ej, libjaxme-java, libcommons-httpclient-java |
|
libcommons-fileupload-java |
ej |
|
libcommons-httpclient-java |
ej |
|
libcommons-io-java |
ej, libcommons-fileupload-java |
|
libcommons-jxpath-java |
ej |
|
libconcurrent-java |
|
libaspectwerz2-java |
libdom4j-java |
ej, libjaxen-java, libsaxonb-java |
|
libehcache-java |
ej |
|
libgoogle-collections-java |
ej |
|
libjarjar-java |
|
libaspectwerkz2-java |
libjavassist-java |
ej |
|
libjaxen-java |
ej, libdom4j-java, libxom-java |
|
libjaxme-java |
libdom4j-java |
|
libjdom1-java |
ej, libcommons-jxpath-java, libjaxen-java, libsaxonb-java |
|
libjettison-java |
ej |
libxstream-java |
libjgroups-java |
|
libehcache-java |
libjibx-java |
ej |
|
libjmock-java |
|
libqdox-java |
libjoda-time-java |
|
libxstream-java |
libjrexx-java |
libaspectwerkz2-java |
|
libjsr107cache-java |
libehcache-java |
|
libjunitperf-java |
|
libdom4j-java |
libmockobjects-java |
ej, groovy |
|
libow-util-ant-tasks-java |
|
libasm-java, libasm2-java, libasm3-java |
libqdox-java |
libjibx-java |
ej, libcommons-attributes-java |
libslf4j-java |
ej |
|
libstringtemplate-java |
antlr3 |
|
libtrove-java |
|
libaspectwerkz2-java |
libwoodstox-java |
libjibx-java |
|
libxml-commons-external-java |
ej |
|
libxml-security-java |
ej |
|
libxom-java |
ej, libsaxonb-java |
|
libxpp2-java |
libdom4j-java |
|
libxpp3-java |
ej, libdom4j-java, groovy, libjibx-java |
|
libxstream-java |
ej, groovy |
|
New dependencies expected from Eucalyptus 1.6
- netty 3.1
- dnsjava
- eucalyptus-hibernate
Packages expected from RefactorEucalyptusJavadepsSpec
- Axiom
- Backport Util Concurrent 3.1
- Drools
- Mule
- MVEL
- OpenSAML/1.1 Java
- WSS4J
- Spring
- JUG
- Jetty 6
- Google Web Toolkit
Dependencies from Spring
Core dependencies
Package |
Dependency of |
Extra build dep of |
jruby1.1 |
|
Spring |
libcommons-attributes-java |
|
Spring |
libaopalliance-java |
|
Spring |
libjamon-java |
|
Spring |
Extra dependencies coming from Debian packaging
Note: we would patch so that it uses:
- libtomcat6-java instead on libtomcat5.5-java (avoiding libcommons-[el,launcher,modeler]-java)
- tomcat6-examples instead of glassfish-appserv
Package |
Dependency of |
Extra build dep of |
libjdo-api-java |
Spring |
|
glassfish-toplink-essentials |
Spring |
|
libfreemarker-java |
Spring |
|
velocity |
Spring |
|
libjexcelapi-java |
Spring |
|
libstruts1.2-java |
Spring |
|
libibatis-java |
Spring |
|
libtiles-java |
Spring |
|
libquartz-java |
Spring |
|
libxapool-java |
Spring |
|
libvelocity-tools-java |
Spring |
|
testng |
Spring/test |
|
libjdom0-java |
libfreemarker-java, velocity |
|
libwerken.xpath-java |
velocity |
|
libcommons-digester-java |
libstruts1.2-java, libcommons-validator-java, libcommons-modeler-java, libtiles-java |
|
libcommons-validator-java |
libstruts1.2-java |
|
libcommons-beanutils-java |
libtiles-java |
|
Total
- 51 from primary list
- 3 from new Eucalyptus deps
11 from RefactorEucalyptusJavadepsSpec
- 21 from Refactor/Spring
Total: 86 packages to MIR
Other potential actions to reduce number of packages
Remove libcglib2.1-java -> libaspectwerkz2-java dependency, get rid of 5 packages
- Do a minimal Spring rather than take Debian spring, get rid of (at most) 17 packages
- include libehcache in eucalyptus-hibernate: saves 3 packages
- Get rid of WSS4J/OpenSAML dependency: saves 2 packages
Implementation
Create eucalyptus-hibernate
Create the specific eucalyptus hibernate libraries, containing the subset of hibernate needed for Eucalyptus and not all the JBoss hooks the libhibernate3-java package contains.
Those should be shipped as the new "eucalyptus-javadeps" package (which is kept to include all the non-standard libraries required by Eucalyptus).
Implement other hacks
All the other number-reducing hacks should be implemented:
Remove dependency from libclassworlds-java -> maven-ant-helper
- ...
Determine final map of MIR, split into sets
The final dependencies should be determined and splitted into sets that can be handled separately.
Process MIR sets
Several options, to be discussed with MIR team:
- One bug per set, one task per package in set
- One bug per package
- One bug for everything
- Process outside Launchpad, with one metabug to track progress
Test/Demo Plan
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.
Unresolved issues
None.
BoF agenda and discussion
UDS discussion
Current status
- 99 packages which would need to move to main.
Java in main is currently driven by OpenOffice. Tomcat6 is there, but has few dependencies.
Future
- Eucalyptus version for Karmic should have fewer dependencies anyway from upstream refactoring.
How can the number of build/runtime dependencies be reduced?
- Get rid of anything not necessary
- Geronimo spec packages (already provided by glassfish-j2ee)
- Move parts into Eucalyptus code
- Refactor packages (e.g. hibernate pulls in a lot of stuff)
- Requires multiple source packages or only to promote some resulting binaries to main.
- (doko recommends duplicating the source package and documenting it)
- Requires multiple source packages or only to promote some resulting binaries to main.
What could be expected to be refused inclusion to main
- Active upstream criteria
- Annogen
- OpenSAML
- WSS4J?
- Known to be insecure
- Nothing obvious
- Partial builds (because of non-free dependencies)
- Mule
- We don't really care
Size issues (adding to default CD)
- GWT is 6MB of binary
- 1.6 should be more granular and work with existing java packages more
- JRuby is 3MB
- Just be a build-time dependency of GWT
- libjgroups-java, 3MB. Not needed ?
- glassfish-toplink-essentials, 2.4MB, comes from hibernate
- Avoiding JDK would save about 50MB of CD space
- Avoiding GCJ would save about 20MB
Can we use the new Spring packaging from Debian?
- Not included yet in Debian, but work is underway
- Might make too hard choices for us ? Testing from Eucalyptus side needed.
Safety net
- Keep a eucalyptus-javadeps package to drop in any problematic parts which can't be fixed (hibernate?).
- One tiny part of Drools
Action Summary
- Which Eucalyptus version we'll use in Karmic and its dependencies?
- Can we use Spring from Debian?
- What can we do to reduce Hibernate size?
- Will it be acceptable to move JBoss to main?
- JDK dependency investigation
- Ask Colin about blacklisting for the server seed only to solve GCJ issue
- Once it's known what is required, start preparing/filing MIRs to avoid a last minute panic.
EucalyptusInMainSpec (last edited 2009-08-10 09:46:57 by lns-bzn-48f-81-56-218-246)