Mastering modularity - OSGi in Action - page 32

META-INF/MANIFEST.MF entry of the JAR file. This is where OSG i places its module meta-
data. Whenever we refer to a bundle's manifest file , we're specifically referring to the
module-related metadata in this standard JAR manifest file.
Note that this definition of a bundle is similar to the definition of a module, except
that it combines both the physical and logical aspects of modularity into one concept.
So before we get into the meat of this chapter, which is defining bundle metadata, let's
discuss the bundle's role in physical and logical modularity in more detail.

2.4.1 The bundle's role in physical modularity

The main function of a bundle with respect to physical modularity is to determine
module membership. No metadata is associated with making a class a member of a
bundle. A given class is a member of a bundle if it's contained in the bundle JAR file.
The benefit for you is that you don't need to do anything special to make a class a
member of a bundle: just put it in the bundle JAR file.
This physical containment of classes leads to another important function of bundle
JAR files as a deployment unit. The bundle JAR file is tangible, and it's the artifact you
share, deploy, and use when working with OSG i. The final important role of the bundle
JAR file is as the container of bundle metadata, because, as we mentioned, the JAR man-
ifest file is used to store it. These aspects of the bundle are shown in figure 2.7. The issue
of metadata placement is part of an ongoing debate, which we address in the sidebar for
those interested in the issue.

blah, blah, blah,
blah, blah, blah,
blah, blah, blah

Manifest

Class1

Application server

Class2
Class3
Class4

Bundle A

Deploy

Bundle B

Class5

blah, blah, blah,
blah, blah, blah,
blah, blah, blah

Manifest

Figure 2.7 A class is a member of a bundle if it's packaged in it, the bundle carries its module metadata
inside it as part of its manifest data, and the bundle can be deployed as a unit into a runtime environment.

Where should metadata go?
Is it a good thing to store the module metadata in the physical module and not in the
classes themselves? There are two schools of thought on this subject. One says it's
better to include the metadata alongside the code it's describing (in the source file
itself), rather than in a separate file where it's more difficult to see the connection to
the code. This approach is possible with various techniques, such as doclets or the
annotations mechanism introduced in Java 5.