Another useful tool to have installed as well is the build management application Maven 2 from Apache. Using Maven will greatly simplify the dependency management and the building, packaging, and deployment of developed bundles.
Note
Maven is not required for building OSGi bundles, since bundles are packaged as regular JARs with a customized manifest. However, using Maven does make the process much simpler and straightforward— there are Maven plugins provided as Felix sub-projects that help with this task.
The code examples and instructions to build them, shown in this book, will make use of Maven as a build environment.
A more detailed set of examples will be shown there. For now, we will cover a quick introduction to some of the main Maven concepts. You will learn how to actually configure a project to use it later ,in Chapter 5, The Book Inventory Bundle.
If you haven't used Maven before, don't worry: we'll cover some of its usage as part of this case study.
The Maven website has a good and simple install and configuration guide. Just download Maven 2 (http://maven.apache.org/) and install it.
Maven is a tool for automating project development activities such as building and packaging of artifacts (for example, JARs), managing a project's dependencies, generating documentation and reports, and so on.
Its basic principle consists of a set of project 'life-cycles', processes which define the 'phases' that a project goes through to achieve a final result. For example, building an application or constructing a documentation website for it are the purposes of two of the life-cycles built into Maven. Additional life-cycles can also be defined by the user, but this is beyond the scope of this introduction.
The life-cycle clearly defines the phases that are followed to achieve its purpose. Automating those steps, executing them without human intervention, limits the human error factor in the build process, as well as provides confidence in the reproducibility of the final result of the life-cycle.
The atomic action is the 'goal', which represents a specific task to be performed. A phase is made of a sequence of goals to be achieved for that phase. The goals that are bound to a phase are decided based on factors such as the project packaging type or its configured plugins.
There's a wide range of documentation on the Maven site (http://maven.apache.org/). Here's a good guide on life-cycles and phases: http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html.
The life-cycles built into Maven are:
- The default build life-cycle, which takes the project through the build phases, (we'll see this in a while)
- The
cleanlife-cycle, which takes the project through a cleaning process to remove items such as temporary files or generated content - The
sitelife-cycle, which steps through the documentation and reporting phases and generates a project site
For example, some of the main phases defined in the default build life-cycles are:
validatethat the project is well defined and all required information is providedcompilethe project source codetestthe compiled code, using an automated test suite (such as JUnit). Those are unit code tests that don't require the code to be packaged or deployedpackagethe code and resources into an artifact, the main deliverable for the project (a JAR, for example)integration-testthe package, potentially deploying it to a test environmentverifythat the package fulfills additional quality checksinstallthe package locally, making it available to other projects on this systemdeploythe package to an integration or release location
Each phase is dependent on the phase before it; for example, in the default build life-cycle, requesting the deploy phase will take the project through validate, compile, test, and so on.
Regularly, we will be using the clean and deploy life-cycles to produce a release of our bundles from a clean start.
The build life-cycles can be customized using plugins, which are provided by Maven or third-parties. Plugins can attach to goals or extend them to provide build goals with functionality. For example, we will be using some of the plugins provided by the Felix project to help with the OSGi bundle creation process later.
Maven provides a simple way to get the required plugins. When you install it, it comes with the minimal set of libraries required for it to function. It will then download the additional JARs it needs from online repositories, based on library identification and classification information (namely, the group and artifact IDs).
The description of a project, its identification, and the way it is to be built are defined in its Project Object Model (POM), an XML file that is the main source of information for Maven. It contains information such as the group and artifact IDs of the project and the dependencies it requires. It also contains information such as the developers of the project, its software configuration management system, where its packaged artifacts are deployed, and so on.
As part of the project identification, the POM holds the project packaging type which determines which goals are bound to the life-cycle phases. The default packaging type is jar and there are a few packaging types built-in such as war, ear, and so on. For example, the package phase will be different for a JAR and for a WAR.
The packaging we will use for our projects is a bundle, which is a custom packaging type provided by the Bundle Plugin (described in the next section). This will be used by the plugins that we will configure to generate the manifest headers and package the bundle. You will learn how to create and configure the POMs for the projects of this case study in Chapter 5.
Felix provides quite a few useful plugins to assist in the build and packaging process:
- Bundle Plugin: Based on the BND tool from Peter Kriens, this Maven 2 plugin will assist in the packaging of bundles based on a few build directives (configuration). It will also manage a local OSGi Bundle Repository (OBR) and provide distribution to OBRs (covered in Chapter 6,Using the OSGi Bundle Repository.)
- iPOJO Plugin: Used in conjunction with the Bundle plugin. Given an XML metafile, it will automate the iPOJO-related actions as part of the build process.
- junit4osgi Plugin: Integrates the jUnit test framework with the bundle build process.
- SCR Plugin: It simplifies the development of bundles by generating necessary descriptors based on annotations.
We will use the Bundle plugin throughout the case study and start using the iPOJO plugin in Chapter 9, Improving the Bookshelf service with iPOJO.
- What is a life-cycle in Maven terms?
a. It manages the state of bundles in an OSGi framework
b. It defines the phases that contents of a project go through to achieve a purpose in an automated fashion, such as building the project
c. It is a check-list for developers to follow to remember the steps that are required for a build
- What is a POM primarily used for in the build process?
a. It is included with the produced archive as bundle configuration
b. It is included with the produced archive as information on the project
c. It provides Maven with project identification and build instructions