2.2. Development Model

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.

Apache Maven, which is the recommended build system for JBoss Fuse, affects the development model in the following important ways:

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”.

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:

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.

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”.

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:

The following kinds of metadata are accessible to administrators, who can use them to customize or change the behavior of bundle at run time: