Chapter 3. Building with Maven
Maven is an open source build system which is available from the Apache Maven project. This chapter explains some of the basic Maven concepts and describes how to set up Maven to work with Red Hat JBoss Fuse. In principle, you could use any build system to build an OSGi bundle. But Maven is strongly recommended, because it is well supported by Red Hat JBoss Fuse.
3.1. Maven Directory Structure
One of the most important principles of the Maven build system is that there are standard locations for all of the files in the Maven project. There are several advantages to this principle. One advantage is that Maven projects normally have an identical directory layout, making it easy to find files in a project. Another advantage is that the various tools integrated with Maven need almost no initial configuration. For example, the Java compiler knows that it should compile all of the source files under
src/main/javaand put the results into
Standard directory layout
Example 3.1, “Standard Maven Directory Layout” shows the elements of the standard Maven directory layout that are relevant to building OSGi bundle projects. In addition, the standard locations for Spring and Blueprint configuration files (which are not defined by Maven) are also shown.
Example 3.1. Standard Maven Directory Layout
ProjectDir/ pom.xml src/ main/ java/ ... resources/ META-INF/ spring/ *.xml OSGI-INF/ blueprint/ *.xml test/ java/ resources/ target/ ...
It is possible to override the standard directory layout, but this is not a recommended practice in Maven.
pom.xmlfile is the Project Object Model (POM) for the current project, which contains a complete description of how to build the current project. A
pom.xmlfile can be completely self-contained, but frequently (particular for more complex Maven projects) it can import settings from a parent POM file.
After building the project, a copy of the
pom.xmlfile is automatically embedded at the following location in the generated JAR file:
src and target directories
src/directory contains all of the code and resource files that you will work on while developing the project.
target/directory contains the result of the build (typically a JAR file), as well as all all of the intermediate files generated during the build. For example, after performing a build, the
target/classes/directory will contain a copy of the resource files and the compiled Java classes.
main and test directories
src/main/directory contains all of the code and resources needed for building the artifact.
src/test/directory contains all of the code and resources for running unit tests against the compiled artifact.
java/sub-directory contains Java source code (
*.javafiles) with the standard Java directory layout (that is, where the directory pathnames mirror the Java package names, with
/in place of the
src/main/java/directory contains the bundle source code and the
src/test/java/directory contains the unit test source code.
If you have any configuration files, data files, or Java properties to include in the bundle, these should be placed under the
src/main/resources/directory. The files and directories under
src/main/resources/will be copied into the root of the JAR file that is generated by the Maven build process.
The files under
src/test/resources/are used only during the testing phase and will not be copied into the generated JAR file.
By default, Red Hat JBoss Fuse installs and activates support for Spring Dynamic Modules (Spring DM), which integrates Spring with the OSGi container. This means that it is possible for you to include Spring configuration files,
META-INF/spring/*.xml, in your bundle. One of the key consequences of having Spring DM enabled in the OSGi container is that the lifecycle of the Spring application context is automatically synchronized with the OSGi bundle lifecycle:
- Activation—when a bundle is activated, Spring DM automatically scans the bundle to look for Spring configuration files in the standard location (any
.xmlfiles found under the
META-INF/spring/directory). If any Spring files are found, Spring DM creates an application context for the bundle and creates the beans defined in the Spring configuration files.
- Stopping—when a bundle is stopped, Spring DM automatically shuts down the bundle's Spring application context, causing any Spring beans to be deleted.
In practice, this means that you can treat your Spring-enabled bundle as if it is being deployed in a Spring container. Using Spring DM, the features of the OSGi container and a Spring container are effectively merged. In addition, Spring DM provides additional features to support the OSGi container environment—some of these features are discussed in Chapter 16, OSGi Services.
OSGi R4.2 defines a blueprint container, which is effectively a standardized version of Spring DM. Red Hat JBoss Fuse has built-in support for the blueprint container, which you can enable simply by including blueprint configuration files,
OSGI-INF/blueprint/*.xml, in your project. For more details about the blueprint container, see Chapter 16, OSGi Services.