Developing Java applications for MQ just got easier with Maven

Introduction

This post talks about a simpler way to develop Java applications for MQ, using a Maven repository to automatically install dependencies.

Application development for MQ requires access to the language-specific interfaces, libraries, headers, DLLs etc. You write an application and, depending on the language, the MQ-provided components are used within the IDE while you are writing code, checked during build processes, or referenced at runtime. If you want to make your application available to other people, then they will need access to at least the runtime MQ interfaces.

We made it much easier to distribute applications with the release of the MQ Redistributable Client packages.

And now we’ve also made it easier to write Java applications, so that you do not need to explicitly install anything before using MQ’s interfaces.

Maven Central Repository

When it comes to Java, people use the word maven in two related but different contexts. Firstly, it is a tool to build applications. Secondly it refers to a repository holding artifacts that your application may want to access.  A fuller description of Apache Maven is here.

In its “build” guise, you might compare it to ant with build.xml files, make with Makefiles, gradle or a bunch of other tools.

But it is the second usage that we’re really concerned with. The Maven Repository (or more properly, the Central Repository) has a structure that allows files such as jars to have distinct versions and which are then easily discovered with a well-known naming mechanism. Build tools can then use those names to dynamically pull in the dependencies for your application. Something in the definition of your application – when using maven as a build tool, it’s called the POM file – just names the dependencies and the build process knows what to do from there.

The MQ client files

We have pushed copies of the MQ Java client interfaces to the Central Repository under the com.ibm.mq GroupId. You will find both com.ibm.mq.allclient.jar (typically used for standalone programs) and wmq.jmsra.rar (for use in JEE application servers). The allclient jar contains both the JMS and base Java classes for MQ.

The first released version of these files is 9.0.4.0, the same as the current Continuous Delivery release. We would expect newer versions of the MQ files to be shadowed into this repository when they are released. Then, in a pom.xml file processed by the maven command, you would write something like this, to show the relationship between your application code and the MQ jar.

<dependency>
  <groupId>com.ibm.mq</groupId>
  <artifactId>com.ibm.mq.allclient</artifactId>
  <version>9.0.4.0</version>
</dependency>

and for using the JEE Resource Adapter – the type may be required to override the default value of jar.

<dependency>
  <groupId>com.ibm.mq</groupId>
  <artifactId>wmq.jmsra</artifactId>
  <version>9.0.4.0</version>
  <type>rar</type>
<dependency/>

Other build tools such as gradle have a different syntax, but can also refer to the same object. Here is the corresponding syntax from a build.gradle file:

dependencies {
  compile("com.ibm.mq:com.ibm.mq.allclient:9.0.4.0")
}

Obviously to run your application, you will still need to point at a queue manager somewhere via a client channel, but there are lots of ways in which you might have one of those available. For example, you may run the queue manager in a Docker container.

Example

These screenshots come from a very simple project I created in Eclipse to run a JMS program. Because this was created as a Maven project, I did not need to set the classpath to a copy of any MQ code that had already been installed. Instead, Eclipse resolves the references to a local cache of files that is downloaded from the Central Repository when needed.

• Creating a Maven project in Eclipse sets up a standard directory structure

  

• Add the MQ JMS interface as a dependency

  

• And the detailed properties for that dependency

  

• Eclipse generates the corresponding POM text file

  

• The start of the program, showing references to JMS and MQ classes

  

The Maven Dependencies shown in the project screenshot were automatically added – not just the MQ piece, but the things that it in turn depends on. A developer does not have to name those further dependencies; definition chaining is one of the benefits you get from having someone else manage the artifacts.

Testimonials

It might sound a bit odd for something new to already have satisfied users, but as part of the process of testing this release process, I found two separate development projects locally in Hursley that wanted to release components that in turn depended on MQ. Both were having to create convoluted instructions for how you would have to go to a web page, download a zip file, unpack it, copy the MQ code to where it can be used etc. Both developers are now converting to simply point at this release instead. And they were very happy to see it.

Summary

Making it easier for developers to work with MQ is a key goal. We hope this will help some of you.

This post was last updated on February 9th, 2021 at 12:13 pm