Chapter 1. OSGi revealed
Figure 1.1. Modularity refers to the logical decomposition of a large system into smaller collaborating pieces.
Figure 1.2. Multiple JARs containing overlapping classes and/or packages are merged based on their order of appearance in the class path, with no regard to logical coherency among archives.
Figure 1.3. The OSGi Service Platform specification is divided into halves, one for the OSGi framework and one for standard services.
Figure 1.4. OSGi layered architecture
Figure 1.5. A bundle contains code, resources, and metadata.
Figure 1.6. The service-oriented interaction pattern. Providers publish services into a registry where requesters can discover which services are available for use.
Figure 1.7. Simple paint program user interface
Chapter 2. Mastering modularity
Figure 2.1. A module defines a logical boundary. The module itself is explicitly in control of which classes are completely encapsulated and which are exposed for external use.
Figure 2.2. Classes have explicit dependencies due to the references contained in the code. Modules have implicit dependencies due to the code they contain.
Figure 2.3. Even though object orientation and modularity provide similar capabilities, they address them at different levels of granularity.
Figure 2.4. The paint program is a simple Swing application.
Figure 2.5. Paint program class relationships