Red Hat Training

A Red Hat training course is available for Red Hat Fuse

1.2. Development Model

Overview

Figure 1.1, “Developing a Red Hat JBoss Fuse Project” shows an overview of the development model for building an OSGi bundle or a Fuse Application Bundle that will be deployed into the Red Hat JBoss Fuse container.

Figure 1.1. Developing a Red Hat JBoss Fuse Project

Developing a Red Hat JBoss Fuse Project

Maven

Apache Maven, which is the recommended build system for JBoss Fuse, affects the development model in the following important ways:
  • Maven directory layout—Maven has a standard directory layout that determines where you put your Java code, associated resources, XML configuration files, unit test code, and so on.
  • Accessing dependencies through the Internet—Maven has the ability to download dependencies automatically through the Internet, by searching through known Maven repositories. This implies that you must have either access to the Internet or local copies of the required Maven repositories, when building with Maven. See the section called “Maven repositories”.

Maven archetypes

An easy way to get started with development is by using a Maven archetype, which is analogous to using the new project wizard (except that it must be invoked from the command line). A Maven archetype typically creates a completely new Maven project, with the correct directory layout and some sample code. For example, see Section 2.1, “Create a Web Services Project” and Section 2.2, “Create a Router Project”.

Maven POM files

The Maven Project Object Model (POM) file, pom.xml, provides the description of how to build your project. The initial version of a POM is typically generated by a Maven archetype. You can then customise the POM as needed.
For larger Maven projects, there are two special kinds of POM files that you might also need:
  • Aggregator POM—a complete application is typically composed of multiple Maven projects, which must be built in a certain order. To simplify building multi-project applications, Maven enables you to define an aggregator POM, which can build all of the sub-projects in a single step. For more details, see Section 2.3, “Create an Aggregate Maven Project”.
  • Parent POM—in a multi-project application, the POMs for the sub-projects typically contain a lot of the same information. Over the long term, maintaining this information, which is spread across multiple POM files, would time-consuming and error-prone. To make the POMs more manageable, you can define a parent POM, which encapsulates all of the shared information.

Java code and resources

Maven reserves a standard location, src/main/java, for your Java code, and for the associated resource files, src/main/resources. When Maven builds a JAR file, it automatically compiles all of the Java code and adds it to the JAR package. Likewise, all of the resource files found under src/main/resources are copied into the JAR package.

Dependency injection frameworks

JBoss Fuse has built-in support for two dependency injection frameworks: Spring XML and Blueprint XML. You can use one or the other, or both at the same time. The projects underlying JBoss Fuse (Apache Camel, Apache CXF, Apache ActiveMQ, and Apache ServiceMix) all strongly support XML configuration. In fact, in many cases, it is possible to develop a complete application written in XML, without any Java code whatsoever.
For more details, see Section 1.4, “Dependency Injection Frameworks”.

Deployment metadata

Depending on how a project is packaged and deployed (as an OSGi bundle, a Fuse Application Bundle(FAB), or a WAR), there are a few different files embedded in the JAR package that can be interpreted as deployment metadata, for example:
META-INF/MANIFEST.MF
The JAR manifest can be used to provide deployment metadata either for an OSGi bundle (in bundle headers) or for a FAB.
META-INF/maven/groupId/artifactId/pom.xml
The POM file—which is normally embedded in any Maven-built JAR file—is the main source of deployment metadata for a FAB.
WEB-INF/web.xml
The web.xml file is the standard descriptor for an application packaged as a Web ARchive (WAR).

Administrative metadata

The following kinds of metadata are accessible to administrators, who can use them to customize or change the behavior of bundles at run time:
  • Apache Karaf features—a feature specifies a related collection of packages that can be deployed together. By selecting which features to install (or uninstall), an administrator can easily control which blocks of functionality are deployed in the container.
  • OSGi Config Admin properties—the OSGi Config Admin service exposes configuration properties to the administrator at run time, making it easy to customize application behavior (for example, by customizing the IP port numbers on a server).