Difference between revisions of "Efforts/Package Restructuring/Modelling"

From Apache OpenOffice Wiki
Jump to: navigation, search
m (Example)
m (Product Pipeline)
Line 86: Line 86:
 
==Product Pipeline==
 
==Product Pipeline==
 
[[Image:Product Pipeline.jpg|center]]
 
[[Image:Product Pipeline.jpg|center]]
 +
 +
The modelling by inheritance and instantiation needs to lead to deliverables which are re-usable during productization and after installation, ideally leading to zero redundancy in case of the installation of many variants (OOo and derivatives).
 +
 +
Taking a look at how packages (like RPM) are typically organized, we can see, that the intermediate deliverables should express their needs and offers in terms of
 +
* dependencies against a (virtual) package, as well as by listing the
 +
* provisions.
 +
 +
A name schema reflecting this approach may look like this:
 +
 +
<feature>_<brnd>_<pltfrm>_<lcl>
 +
writer_foo_linux_en
 +
 +
Packages independent of a particular dimension just leave this position empty.
 +
 +
 +
For example, splitting the writer along the above "dimensions" (brand, OS, Architecture, locale, rest), we get
 +
* writer.rpm - this is everything of the writer, which does not provide anything a long the dimensions,
 +
* writer___en.rpm - containing all English localization content not depending on anything else,
 +
* writer_OOo__en.rpm - containing all English localization content of the OOo brand,
 +
* writer___de.rpm - containing all German localization content not depending on anything else,
 +
* writer_OOo__de.rpm - containing all German localization content of the OOo brand,
 +
* writer__linux_.rpm - containing all Linux specific stuff,
 +
 +
All product entities (files, registry entries, short cuts etc.) get packaged according their dimensions.
 +
 +
We now need to see, how we can express dependencies. Looking at the above example, we see, that the writer package (writer.rpm) certainly needs some of the other packages, to become usable. It obviously depends on the following
 +
* writer localization,
 +
* writer brand,
 +
* writer platform specific files,
 +
or expressed more general writer.rpm depends on
 +
* writer_brnd__lcl
 +
* writer___lcl
 +
* writer__linux_
 +
While the specific packages do provide
 +
* writer - writer
 +
* writer___en - writer___en, writer___lcl
 +
* writer_OOo__en - writer_brnd__lcl, writer_OOo__lcl, writer_brnd__en, writer_OOo__en,
 +
* writer___de - writer___de, writer___lcl,
 +
* wrtier_OOo__de - writer_brnd__lcl, writer_OOo__lcl, writer_brnd__de, writer_OOo__de
 +
 +
Packages with less dimensions are '''more general''' than packages with more dimensions, which are '''more specific'''.
 +
 +
Two rules of thumb help to ease modelling the dependencies:
 +
* A package may only have a dependency to a more general package (the writer_OOo__en package may depend on the writer_OOo__ package, but not the opposit)!
 +
* A more specific package implies the more general (the writer_OOo__en package implies an writer___en package)!
 +
  
  
 
[[Category:Packaging]]
 
[[Category:Packaging]]

Revision as of 10:06, 22 January 2008

De-Composition

Looking at an installed OOo and its files, registry entries etc., we can see, that all these entities belong to one or multiple of the following categories, such that they provide or depend on it

  1. brand
  2. Operating System
  3. Machine Architecture / interpreter
  4. localization

The consequences of this observation are, that entities unrelated to one or multiple categories, but shared by products differing in these categories, are identical and thus may be re-used for creating, changing or updating products respectively installed products.

Additionally every entity exactly belongs to one

  • feature

as otherwise it would not be needed for any feature, thus it would not be needed at all. Certainly features may be related such that they require one another, even if this is not noticeable in the Product View.

Composition

Model products by setting them into

  • inheritance, respectively
  • instantiation (template)

relationship.

Inheritance

Inheritance models a "is a" relationship. In practice that would mean, that a StarOffice 8 update 7 is an OOo 2.2.1 (respectively its basis) adding something.

Instantiation

Example

Template Product OOo-Standard {
  Features: writer, calc, impress, draw
}

Abstract Product OOo2.4 {
  Name: OOo 2.4
  Code-Base: SRC680m236
  Implements: OOo-Standard

}

Product OOo2.4-ISO : OOo2.4 {
  Name: OpenOffice 2.4
  Format: ISO-750
  Platform: Linux-x86, Windows-x86, Mac OS X x86
}

Product OOo2.4-download-linux-x86 : OOo2.4 {
  Name: OpenOffice 2.4
  Format: donwload
  Platform: Linux-x86
}

Product OOo2.4-download-windows-x86 : OOo2.4 {
  Name: OpenOffice 2.4
  Format: donwload
  Platform: windows-x86
}

Abstract Product FooOffice3u4 : OOo2.4 {
  Name: FooOffice 3 update 4
  Features: foo-templates, foo-fonts, foo-brand
  Updates: < FooOffice 3 u 4
}

Product FooOOo3u4-ISO : FooOffice3u4 {
  Name: FooOffice 3 update 4 ISO
  Format: ISO-750
  Platform: Linux-x86, Solaris-x86, Solaris-Sparc, Windows-x86, Mac OS X x86
}

Product FooOffice3u4-donwload : FooOffice3u4{
  Name: FooOffice 3 update 4 ISO
  Format: download
  Platform: Linux-x86
}

Abstract Product : OOo_2.4 {
  Name: BarOffice 5 update 6
  Features: bar-templates, bar-fonts, bar-brand
  Updates: < BarOffice 5 u 6
}

Tooling

  • Comparison of Installation Sets
  • Check for conflicts
  • Creation of Installation Sets
  • Visualization

Product Pipeline

Product Pipeline.jpg

The modelling by inheritance and instantiation needs to lead to deliverables which are re-usable during productization and after installation, ideally leading to zero redundancy in case of the installation of many variants (OOo and derivatives).

Taking a look at how packages (like RPM) are typically organized, we can see, that the intermediate deliverables should express their needs and offers in terms of

  • dependencies against a (virtual) package, as well as by listing the
  • provisions.

A name schema reflecting this approach may look like this:

<feature>_<brnd>_<pltfrm>_<lcl>
writer_foo_linux_en

Packages independent of a particular dimension just leave this position empty.


For example, splitting the writer along the above "dimensions" (brand, OS, Architecture, locale, rest), we get

  • writer.rpm - this is everything of the writer, which does not provide anything a long the dimensions,
  • writer___en.rpm - containing all English localization content not depending on anything else,
  • writer_OOo__en.rpm - containing all English localization content of the OOo brand,
  • writer___de.rpm - containing all German localization content not depending on anything else,
  • writer_OOo__de.rpm - containing all German localization content of the OOo brand,
  • writer__linux_.rpm - containing all Linux specific stuff,

All product entities (files, registry entries, short cuts etc.) get packaged according their dimensions.

We now need to see, how we can express dependencies. Looking at the above example, we see, that the writer package (writer.rpm) certainly needs some of the other packages, to become usable. It obviously depends on the following

  • writer localization,
  • writer brand,
  • writer platform specific files,

or expressed more general writer.rpm depends on

  • writer_brnd__lcl
  • writer___lcl
  • writer__linux_

While the specific packages do provide

  • writer - writer
  • writer___en - writer___en, writer___lcl
  • writer_OOo__en - writer_brnd__lcl, writer_OOo__lcl, writer_brnd__en, writer_OOo__en,
  • writer___de - writer___de, writer___lcl,
  • wrtier_OOo__de - writer_brnd__lcl, writer_OOo__lcl, writer_brnd__de, writer_OOo__de

Packages with less dimensions are more general than packages with more dimensions, which are more specific.

Two rules of thumb help to ease modelling the dependencies:

  • A package may only have a dependency to a more general package (the writer_OOo__en package may depend on the writer_OOo__ package, but not the opposit)!
  • A more specific package implies the more general (the writer_OOo__en package implies an writer___en package)!
Personal tools