During this case study, we'll create a good deal of bundles for deployment. Here we will define the common conventions that will be used for identifying the bundles and organization of the Java code.

As we will see in greater detail in Chapter 5, a bundle is identified by a symbolic name, associated with a version sequence. It is also, usually, given a name. I have chosen a common group identifier for all the bundles com.packtpub.felix and a common bundle artifact base prefix com.packtpub.felix.bookshelf-. The common group identifier will also be used as the base package for the Java code.

For example, the Book Inventory API bundle would be given the symbolic name com.packtpub.felix.bookshelf-inventory-api and its Java classes would be organized under the package com.packt.felix.bookshelf.inventory.api. Notice the switch from dot to dash separation; this allows a quick visual split between the group and artifact IDs of the project. In this case, com.packt.felix is the group ID and bookshelf-inventory-api is the artifact ID.

In regular development contexts, an artifact's version progresses following best practices, rules that were put in place to transmit information about compatibility between different versions of a bundle. We'll look at the topic of versioning in greater detail in Chapter 5, but the following is a quick introduction.

This compatibility information is encoded in three parts of a version string: the major, minor, and patch level. Typically, a bundle would start with a major version of 0 until it is first released. While its major version is 0, the interfaces exposed by the bundle are still in development mode and may undergo any change found to improve them.

When the bundle is released, it is given the version 1.0.0. After this point, changes to the bundle that do not affect the exposed interfaces impact the patch level of the version. For example, a bundle with version 1.0.0 undergoes bug fixes that do not affect its interfaces. This bundle is released with version 1.0.1.

Backward compatible changes to a bundle's interfaces impact the minor version part and reset the patch level. For example, if a new getter method is added to an interface in a bundle with version 1.2.1, it would be released with version 1.3.0. In this instance, a component that had a dependency on this bundle when it had version 1.2.1 can use the one with version 1.3.0 without requiring any changes to its code.

A change in the major version of a bundle means that the changes to the functionality are not backwards compatible. This may include removal of methods, changes in the return types, or an optional bean property that becomes mandatory.

In our context, to make it easier for you to know in which chapter a bundle was last updated, we will encode the chapter number as the minor version. For example, the bookshelf-inventory-api bundle is released with version 1.5.0 in Chapter 5.

The following are the bundles we will produce as part of our case study: