Skip to end of metadata
Go to start of metadata


Firstly, check out the source from the git repository.

git clone qpid-broker-j



The build requires a Java 8 or later. You should set the JAVA_HOME environment variable and include its bin directory in your PATH.

Check it's OK by executing the following at your command prompt.

java -version


The build requires a Maven version of 3.0.0 or later.  You should set the M2_HOME environment variable and include its bin directory in your PATH.

Check it's OK by executing the following at your command prompt.

mvn --version
For full maven install reference visit Maven Installation Instructions.

Qpid Maven Structure

For complete reference and documentation on Maven please visit the following online resources.

Apache Maven Project

Maven: The Complete Reference by Sonatype

Project Object Model (POM)

Each Qpid java module has its own POM file (pom.xml) located in its root directory.

This file defines the modules version, dependencies and project inheritence as well as the configuration of the relative maven plugins specific to this module.  

At present we have 2 high level "parent" modules that serve as the grandparent and parent of all the java modules in the project.


POMArtifact NameLocationDescription

Qpid Parent



This is the high level POM that all Qpid modules ultimately inherit from.  

It itself is a child of the latest Apache parent POM and its main purpose is to initialise all of our default values, plugins and versions and set any global Qpid configuration.

It is versioned separatley and its release cycle is independent of that of the Qpid Java Project.

Java Build


pom.xmlThis is the primary build POM that can be used to build the whole Qpid Java project.  It defines all of the Java Qpid modules and sets all the default values, plugins, versions and configuration for the whole Java build.

Child Modules





Each and every child module has its own specific POM file that specifies exactly what its dependencies are and any plugin configuration it needs.

Maven Commands

Here is a quick reference guide outlining some of the maven commands you can run and what the outcome will be.

Please visit Introduction To The Maven Lifecycle reference guide for full details on all the maven lifecycle phases.

mvn cleanremoves all the files created by the previous buildUsually means it deletes the contents of the modules */target/ directory.
mvn validatevalidates that the maven poms are all correct and that no config is missingUsefull to run when making build modifications to ensure consistency.
mvn compilecompiles the source code of the projectThis will verify that project dependencies are correct.
mvn testexecutes the unit testsShould not rely on code being packaged or deployed, only unit tests.

mvn package

packages the code into the its distributable formats (jar, war, zip etc)Each pom specifies what the distribution format is, default is POM.
mvn verifyverifies that the packaged code is validThis will run the integration and system tests.
mvn installinstalls the package into the local maven repositoryThis will result in the module being available, locally, as a depedency
mvn deploycopies the final artifacts to the remote maven repository for sharingThis would happen only when modules ready to be shared with other developers or projects
mvn site:stagecreates a staged version of the maven site with all the reports

Staging output defaults to the */target/staging/ directory

mvn jacoco:reportgenerates the code coverage report for the tests that have been executedTest output appears in the */target/site/jacoco/ directory

Maven Profiles

Maven profiles are used to allow set configuration to be enables easily at the command line using the -P option.   If no profile is selected, java-mms-1.0 is run by default.

for e.g.

mvn verify -Pjava-bdb.1-0

Please visit Introduction To Maven Profiles for full details on the use of profiles in a maven build.

Profile NameDescription
java-store.protocolTest profile to use AMQP protocol with store store for Java Broker for system testing. Store can be bdb, derby, json, mms the latter signifying a test in-memory store principally used for testing.
Note that when running the older protocols, it is necessary to add the system property -DenableAmqp0-x to the command line.
cppTest profile to use AMQP 0-10 and the C++ for system testing
apache-releaseRelease profile for performing Apache software releases
dependency-checkDependency check to validate project licensing ahead of release
joramtestsProfile used to execute the Joram JMS test suite (more below).
tckProfile used to execute the JMS TCK (more below)

Maven Build Output

By default the build output for a maven module will appear in the modules "target" directory:

for e.g. the broker core module output appears in:


Depending on the goals specified in the last build, one or all of the following can be found in the "target" directory.

*/target/Packaged build artifactsJAR, WAS, ZIP etc as well as any release specific artifacts specified in assembly files i.e. release tars
*/target/surefire-reports/Logs from unit/system test and Surefile summaryLogs files generated by the tests (named TEST-<test-class>-<test-method>.txt). Surefire summary has an .xml extension.
*/target/qpid-broker/${project.version}/qbtc-test-config/Broker configuration used by the System testsBroker configuration used by the System tests
*/taget/site/Maven site outputMaven reports generated in HTML format i.e. test reports, code coverage etc
*/target/staging/The staged maven siteLocal attempt to generate the full maven site

The releaseable Client and Broker binary packages can be found in the following locations locally if required for testing.



Once you have this then follow the Java Broker installation instructions.



Once you have this then refer to the JMS client documentation.

Example Maven Commands

Here are some example Maven build commands that you may find usefull.

Clean previous builds output and install all modules to local repository without running any of the unit or system tests.

mvn clean install -DskipTests

Clean previous builds output and installs all modules to the local repository after running all the tests using the Java BDB 1-0 profile

mvn clean install -Pjava-bdb.1-0

Clean previous builds output and installs all modules to the local repository after running all the tests using the Java MMS 0-9 profile

mvn clean install -Pjava-mms.0-9 -DenableAmqp0-x

Perform a subset of the QA (int or sys tests) on the packaged release artifacts

mvn verify -Dtest=TestNamePattern* -DfailIfNoTests=false

Execute the unit tests and then produce the code coverage report

mvn test jacoco:report

Joram JMS Testsuite

The Joram JMS Testsuite is integrated into the Maven build but is disabled by default.  It allows the Joram JMS test suite to executed, using the specified Qpid JMS client, against the Java Broker.  The Java Broker must be running already.

The following clients are supported:

  • qpid-jms-client - Qpid Client AMQP 1.0
  • qpid-amqp-1-0-client-jms - the proof of concept Qpid Client AMQP 1.0 (development ceased 0.32)
  • jms-client  for AMQP protocols 0-8..0-10

To use the test suite, first configure the Java Broker to permit HTTP basic-authentication, then run the following command:

mvn -f joramtests/pom.xml integration-test -Djoramtests=<jms client identifier>

where <jms client identifier> is one of: qpid-jms-clientqpid-amqp-1-0-client-jmsjms-client-0-9jms-client-0-10.

The Maven failsafe plugin will run the tests.  Unit output is produced in joram-tests/target/failsafe-reports and the log from the client is written to joramtests/target/joramtest.log.

To run a particular test use the failsafe plugin property -Dit.test:

mvn -f joramtests/pom.xml integration-test -Djoramtests=qpid-amqp-1-0-client-jms  -Dit.test=ConnectionTest


The configuration for the JMS TCK is integrated into the Maven build but the profile is disabled by default.  The JMS TCK itself is proprietary and must be provided by the user.   The Java Broker must be running and HTTP management available. The test suite will automatically set-up/teardown the JMS objects required by the TCK.

  • qpid-jms-client - Qpid Client AMQP 1.0
  • jms-client  for AMQP protocols 0-8..0-10

To use the test suite, first unpack the JMS TCK into a directory, then invoke in the following way:

To run an individual test, use the tck.test system property.

JMS 2.0 TCK can be run against Java Broker only with qpid-jms-client (for AMQP 1.0)  by specifying profile jms20-tck and location of directory containing expanded TCK. For example,

Performance Tests

The Performance test suite is integrated into Maven.  It is bound to the integration-test phase and it is activated by the  perftest system property.  The Java Broker must be running and HTTP management available. The test suite will automatically set-up/teardown the JMS objects required for the performance tests. 

The following clients are supported:

  • qpid-jms-client - Qpid Client AMQP 1.0
  • jms-client  for AMQP protocols 0-8..0-10

To invoke:

Most things can be overridden from system properties.  Take a look in the first few lines of the POM.

Python Tests

The Python Test suite runs against the Java Broker too but is not currently integrated into Maven. To run the 0-8..0-10 test suites use the following steps.  It assumes that qpid-python and qpid-cpp are checked out.

  1. Configure the Java Broker to allow so that the authentication provider permits plain connections. 

  2. Install the Python packages to a suitable location.

  3. Run the tests will the following command:

Todo.  Describe the running of the AMQP 1.0 test suite using the swigged binding/proton-c.  See the

IDE integration

Nowadays, most of the team chose IntelliJ.


To setup the project, simply import the POM that resides at the top level.

Configuring the Annotation Processor

The build uses Java Annotation Processors to automatically generate code for things such as factories.  Intellij's annotation processor defaults don't play nicely with Maven.  A symptom of this is missing implementation classes when you try and start the Broker.

Go into "Preferences" -> "Annotation Processors"

  • Ensure that the default profile includes all modules.
  • Ensure that Enable Annotation Processing is ticked.
  • Ensure that the Production Source Directory and Test Source Directory match that used by Maven. Choose Module Content Root and use the following paths.
    • target/generated-sources/annotations
    • target/generated-test-sources/test-annotations
  • The option Obtain processors from project classpath does not seem to work.  As a workaround, you may use Processor Path specify the path to the codegen's JAR
    • /path/to/home/.m2/repository/org/apache/qpid/qpid-broker-codegen/6.2.0-SNAPSHOT/qpid-broker-codegen-6.2.0-SNAPSHOT.jar

This workaround does mean that you need to remember to mvn install each time the codegen project is changed, and update the version number each time the version number bumps.

Running the Broker within Intellij

TODO expand on this.

You need to

  • specify QPID_WORK and QPID_HOME in the "VM options"
  • set the class path to "qpid-broker"
  • set the working directory to the root source folder
  • add dojotoolkit and bdb to the "qpid-broker" module dependencies

Running System Tests within Intellij

Running system tests from within IntelliJ requires a bit of fiddeling. You first create a template configuration which you then need to adapt every time you want to run a different systest. This means this method does not support running the entire test suite.

  1. Add a new Configuration
    1. "Run" --> "Edit Configurations..."
    2. Press the plus (plus) sign at the top left to add a new configuration and select "JUnit"
    3. Change the name to "Systest"
    4. Add these to the "VM options"
      1. -Dprofile.virtualhostnode.context.blueprint='{"type":"ProvidedStore","globalAddressDomains":"${dollar.sign}{qpid.gloabalAddressDomains}"}'
      2. -DQPID_HOME=<your Qpid home path>
      3. -DQPID_WORK=<your Qpid work path>
      4. -Dqpid.globalAddressDomains=[]
    5. Change the "Working Directory" to point to your source root folder (i.e., the folder containing the systests folder)
    6. Set "Use classpath of mod..." to "qpid-systests"
  2. When you want to actually run a specific test, copy the fully qualified class name of the test into the "Class" field of this configuration before executing it.



  • No labels