Difference between revisions of "Modularization"

From Apache OpenOffice Wiki
Jump to: navigation, search
(→‎Other Links)
Line 1: Line 1:
−
== The Modularization Project==
+
by now OOo has been regarded as the only real alternative office suite,
−
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.
+
sometimes hard to build, often admired for its feature completeness,
 +
somewhat beaten because of the memory footprint, understood to have one
 +
of the most classical graphical user interfaces ever, loved to recover
 +
MS documents, and so on ...
  
−
<pre>
+
==The Modularization Project==
−
Proposal for new Incubator Project "Modularization"
+
Many words may be used for OOo, though small is not with them :-)
 +
OOo is a huge project, with lots of code and a more or less monolithic
 +
architecture. (Even :-) the ESC [[ESC_dashboard|understands]] that size does not only has
 +
advantages (though it sometimes matters :-).
  
−
Mission:
+
(see )
−
Simplify and enable the creation of custom-tailor OOo deliverables.
+
  
−
Goals:
+
It seems a hero (or five) is needed ... we (Cynthia, Xiuzhi, LiuTao,
−
- Simplify the creation of custom OOo deliverables:
+
Ingo and I) want to move out to fill this position and therefor need
−
- Only checkout what is needed.
+
your (mental) support ...
−
- 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.
+
to Improve and Support Modularization of OOo.
  
−
- (First) Todos:
+
===Goals===
−
- Add missing/useful configure switches (e.g. enable/disable headless).
+
The Goals are:
−
- Create a build helper, supporting checkout, configuration and building of OOo.
+
* Adapt the OOo source to enable (more) custom-tailor products.
−
- Separate features as needed and make them optional.
+
* Support custom-tailor products in the build system by
−
- Disentangle the OOo applications..
+
** checking out what is needed only,
−
</pre>
+
** building what is needed only,
 +
** re-using intermediate or final deliverables.
 +
* Enable pre-build intermediates and their usage.
  
−
== Purpose of Modularization ==
+
===Todos===
 +
And this is what we want to do first:
 +
* Create a "build helper", responsible for
 +
** getting the source,
 +
** getting prerequisites and pre-builds,
 +
** configuring the sources, taking care of dependencies ...,
 +
** and (optionally) building it.
 +
* Add missing/useful configuration switches (e.g. for headless support).
 +
* Re-factor according to needs (e.g. writer only etc.).
  
−
1. end-user can custom-tailor the features of OOo .<br>
+
This "build helper" may be compared to the Linux kernels menuconfig /
−
2. developers only need build and update part of the module to update the OOo.<br>
+
xconfig, first configure it extensively, ideally in a graphical way, than build it.
−
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.<br>
+
−
 
+
−
[http://wiki.services.openoffice.org/wiki/Modularization_more_goals  Here comes more goals]
+
−
 
+
−
== Plans of Modularization ==
+
−
1.independent Apps.<br>
+
−
2.build on installed OOo, small developer packages.<br>
+
−
3.smaller, independent packages.  <br>
+
−
 
+
−
== Benchmarks ==
+
−
1.encapsulation <br>
+
−
2.unambiguously defined, consistent and minimal interfaces <br>
+
−
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) <br>
+
−
 
+
−
 
+
−
== ToDos ==
+
−
1.make modules to be brief, completely pure, and not cotain other modules' stuff.<br>
+
−
2.List features of Modules , and then divide them into primary features, and secondary features. <br>
+
−
3.Form a dictionary(or Tree) of Features-Files(Source Code).From which we will know the relationship of the sources and the features. <br>
+
−
4.Make the secondary features to be extentions or optional installtion.<br>
+
−
Etc...<br>
+
−
 
+
−
== Work in progress ==
+
  
 +
===Outlook===
 +
Later on we may
 +
* rework SCP to configure the sources more dynamically,
 +
* provide pre-build intermediates to reduce build times for many,
 +
* disentangle the OOo applications, and
 +
* do even more ...
  
 
== Other Links ==
 
== Other Links ==
 
[http://wiki.services.openoffice.org/wiki/Modularization/IRCLOGS IRCLOGS ]<br>
 
[http://wiki.services.openoffice.org/wiki/Modularization/IRCLOGS IRCLOGS ]<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]
 +
[http://wiki.services.openoffice.org/wiki/Modularization_more_goals  Here comes more goals]
 +
 
[[Category:Build_System]]
 
[[Category:Build_System]]

Revision as of 07:25, 30 April 2009

by now OOo has been regarded as the only real alternative office suite, sometimes hard to build, often admired for its feature completeness, somewhat beaten because of the memory footprint, understood to have one of the most classical graphical user interfaces ever, loved to recover MS documents, and so on ...

The Modularization Project

Many words may be used for OOo, though small is not with them :-) OOo is a huge project, with lots of code and a more or less monolithic architecture. (Even :-) the ESC understands that size does not only has advantages (though it sometimes matters :-).

(see )

It seems a hero (or five) is needed ... we (Cynthia, Xiuzhi, LiuTao, Ingo and I) want to move out to fill this position and therefor need your (mental) support ...

to Improve and Support Modularization of OOo.

Goals

The Goals are:

  • Adapt the OOo source to enable (more) custom-tailor products.
  • Support custom-tailor products in the build system by
    • checking out what is needed only,
    • building what is needed only,
    • re-using intermediate or final deliverables.
  • Enable pre-build intermediates and their usage.

Todos

And this is what we want to do first:

  • Create a "build helper", responsible for
    • getting the source,
    • getting prerequisites and pre-builds,
    • configuring the sources, taking care of dependencies ...,
    • and (optionally) building it.
  • Add missing/useful configuration switches (e.g. for headless support).
  • Re-factor according to needs (e.g. writer only etc.).

This "build helper" may be compared to the Linux kernels menuconfig / xconfig, first configure it extensively, ideally in a graphical way, than build it.

Outlook

Later on we may

  • rework SCP to configure the sources more dynamically,
  • provide pre-build intermediates to reduce build times for many,
  • disentangle the OOo applications, and
  • do even more ...

Other Links

IRCLOGS
Original wiki page of modularization Here comes more goals

Retrieved from "https://wiki.openoffice.org/w/index.php?title=Modularization&oldid=121953"
Personal tools