Difference between revisions of "Modularization"

From Apache OpenOffice Wiki
Jump to: navigation, search
(Other Links)
(Other Links)
Line 54: Line 54:
  
 
== Other Links ==
 
== Other Links ==
[[IRCLOGS]]
+
[[IRCLOGS http://wiki.services.openoffice.org/wiki/Modularization/IRCLOGS/20090415.log]]<br>
 
[http://wiki.services.openoffice.org/wiki/modularization_org Original wiki page of modularization]
 
[http://wiki.services.openoffice.org/wiki/modularization_org Original wiki page of modularization]
 
[[Category:Build_System]]
 
[[Category:Build_System]]

Revision as of 01:58, 20 April 2009

The Modularization Project

This project is designed to optimize the architecture,custom-tailor a concrete product of OpenOffice which the end-user can select their favorite features and make the OOo kernel more and more smaller.

Proposal for new Incubator Project "Modularization"

Mission:
Simplify and enable the creation of custom-tailor OOo deliverables.

Goals:
- Simplify the creation of custom OOo deliverables:
 - Only checkout what is needed.
 - Only build what is needed.
 - Enable re-usage of stuff.
 - May be comparable to the Linux kernel build system.

- Optimize the architecture to enable custom-tailor products.

- (First) Todos:
 - Add missing/useful configure switches (e.g. enable/disable headless).
 - Create a build helper, supporting checkout, configuration and building of OOo.
 - Separate features as needed and make them optional.
 - Disentangle the OOo applications..

Purpose of Modularization

1. end-user can custom-tailor the features of OOo .
2. developers only need build and update part of the module to update the OOo.
3. Splitting the OOo to kernel(smaller is better) and apps to enable the office vendors can custom-tailor their products. Just like Linux kernal and Mozilla core.

Here comes more goals

Plans of Modularization

1.independent Apps.
2.build on installed OOo, small developer packages.
3.smaller, independent packages. 

Benchmarks

1.encapsulation
2.unambiguously defined, consistent and minimal interfaces
3.dependencies always shall have tree-shape, no circles (small dependency circles up to about 5 compilation units or 2 larger modules may be necessary sometimes)


ToDos

1.make modules to be brief, completely pure, and not cotain other modules' stuff.
2.List features of Modules , and then divide them into primary features, and secondary features.
3.Form a dictionary(or Tree) of Features-Files(Source Code).From which we will know the relationship of the sources and the features.
4.Make the secondary features to be extentions or optional installtion.
Etc...

Work in progress

Other Links

IRCLOGS http://wiki.services.openoffice.org/wiki/Modularization/IRCLOGS/20090415.log
Original wiki page of modularization

Personal tools