2.2. Development Model
Overview
Figure 2.1, “Developing a 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 2.1. Developing a 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 access to the Internet, when building with Maven. See the section called “Maven repositories”.
Maven archetypes
An easy way to get started with development is by using Maven archetypes, which is analogous to a new project wizard (except that it must be invoked from the command line). A Maven archetype typically creates a complete new Maven project, with the correct directory layout and some sample code. For example, see Section 3.1, “Create a Web Services Project” and Section 3.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 kind 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 3.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 2.4, “Dependency Injection Frameworks”.
Deployment metadata
Depending on how a project is packaged and deployed (as an OSGi bundle, 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 for an OSGi bundle (in bundle headers).
META-INF/maven/groupId/artifactId/pom.xml- The POM file is normally embedded in any Maven-built JAR file.
WEB-INF/web.xml- The
web.xmlfile 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 bundle 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).
