Firstly, check out the source from the git repository.
git clone https://git-wip-us.apache.org/repos/asf/qpid-broker-j.git 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 complete reference and documentation on Maven please visit the following online resources.
Maven: The Complete Reference by Sonatype
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.
| POM | Artifact Name | Location | Description |
|---|---|---|---|
Qpid Parent | qpid-parent | NA | 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 | qpid-java-build | pom.xml | This 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 | qpid-* | **/pom.xml or **/**/pom.xml | Each and every child module has its own specific POM file that specifies exactly what its dependencies are and any plugin configuration it needs. |
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.
| Command | Description | Notes |
|---|---|---|
| mvn clean | removes all the files created by the previous build | Usually means it deletes the contents of the modules */target/ directory. |
| mvn validate | validates that the maven poms are all correct and that no config is missing | Usefull to run when making build modifications to ensure consistency. |
| mvn compile | compiles the source code of the project | This will verify that project dependencies are correct. |
| mvn test | executes the unit tests | Should 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 verify | verifies that the packaged code is valid | This will run the integration and system tests. |
| mvn install | installs the package into the local maven repository | This will result in the module being available, locally, as a depedency |
| mvn deploy | copies the final artifacts to the remote maven repository for sharing | This would happen only when modules ready to be shared with other developers or projects |
| mvn site:stage | creates a staged version of the maven site with all the reports | Staging output defaults to the */target/staging/ directory |
| mvn jacoco:report | generates the code coverage report for the tests that have been executed | Test output appears in the */target/site/jacoco/ directory |
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 Name | Description |
|---|---|
java-store.protocol | Test 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. |
| cpp | Test profile to use AMQP 0-10 and the C++ for system testing |
| apache-release | Release profile for performing Apache software releases |
| dependency-check | Dependency check to validate project licensing ahead of release |
| joramtests | Profile used to execute the Joram JMS test suite (more below). |
| tck | Profile used to execute the JMS TCK (more below) |
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:
broker-core/target
Depending on the goals specified in the last build, one or all of the following can be found in the "target" directory.
| Location | Description | Notes |
|---|---|---|
| */target/ | Packaged build artifacts | JAR, 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 summary | Logs 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 tests | Broker configuration used by the System tests |
| */taget/site/ | Maven site output | Maven reports generated in HTML format i.e. test reports, code coverage etc |
| */target/staging/ | The staged maven site | Local 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.
Broker
broker/target/qpid-broker-VERSION-bin.tar.gz
Once you have this then follow the Java Broker installation instructions.
Client
client/target/qpid-client-VERSION-bin.tar.gz
Once you have this then refer to the JMS client documentation.
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
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:
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-client, qpid-amqp-1-0-client-jms, jms-client-0-9, jms-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.
To use the test suite, first unpack the JMS TCK into a directory, then invoke in the following way:
mvn post-integration-test -Dtck=qpid-jms-client -f tck/pom.xml -Dtck.directory=/path/to/jmstck/ |
To run an individual test, use the tck.test system property.
mvn post-integration-test -Dtck=qpid-jms-client -f tck/pom.xml -Dtck.directory=/path/to/jmstck/ -Dtck.test=com/sun/ts/tests/jms/ee/all/sessiontests/SessionTests.java |
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,
mvn post-integration-test -f tck/pom.xml -Pjms20-tck -Dtck.directory=/home/alex/tck/jmstck20 -Dqpid-jms-client-version=0.20.0 |
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:
To invoke:
mvn -f perftests/pom.xml integration-test -Dperftests=jms-client-0-9 |
Most things can be overridden from system properties. Take a look in the first few lines of the POM.
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.
Configure the Java Broker to allow so that the authentication provider permits plain connections.
curl --user admin:admin -d '{"secureOnlyMechanisms": []}' http://localhost:8080/api/latest/authenticationprovider/passwordFile |
Install the Python packages to a suitable location.
LOCALROOT=~/myroot
(cd qpid-cpp/management/python && python setup.py install --root ${LOCALROOT})
(cd qpid-python && python setup.py install --root ${LOCALROOT})
export PYTHONPATH=${LOCALROOT}/lib/python2.7/site-packages |
Run the tests will the following command:
QPID_JAVA=/path/to/my/qpid-java
cd qpid-python
./qpid-python-test -b amqp://guest/guest@localhost:5672 -I${QPID_JAVA}/test-profiles/python_tests/Java010PythonExcludes -I${QPID_JAVA}/test-profiles/python_tests/JavaPre010PythonExcludes -m qpid_tests.broker_0_10 -m qpid_tests.broker_0_9 -m qpid_tests.broker_0_8 -m qmf.console [<fully qualified test name>] |
Todo. Describe the running of the AMQP 1.0 test suite using the swigged binding/proton-c. See the https://builds.apache.org/view/M-R/view/Qpid/job/Qpid-Python-Java-Test/.
Nowadays, most of the team chose IntelliJ.
To setup the project, simply import the POM that resides at the top level.
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"
target/generated-sources/annotationstarget/generated-test-sources/test-annotationsThis 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.
TODO expand on this.
You need to
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.
sign at the top left to add a new configuration and select "JUnit"