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 GroupId. You will find both (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, 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.


and for using the JEE Resource Adapter


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 {

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.


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
    Eclipse Maven project
    Eclipse Maven project
  • Add the MQ JMS interface as a dependency
    The dependency definition
  • And the detailed properties for that dependency
    Dependency properties
  • Eclipse generates the corresponding POM text file:
    A POM file
  • The start of the program, showing references to JMS and MQ classes
    A JMS program

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.


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.


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

5 comments on"Developing Java applications for MQ just got easier with Maven"

  1. This is great news. Thank you. One less thing for us to worry about…

    Are you planning to publish older versions or just from

    • Mark E Taylor January 11, 2018

      We are not going to publish earlier versions; we might publish future fixpack levels on V9.0 LTS but probably not.

  2. “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.” We had exactly the same issue. This is brilliant, thank you Mark!

  3. How does this work when external web sites cannot be accessed from inside a corporate network?

    • Mark E Taylor January 10, 2018

      You can of course continue to use whatever mechanisms you currently use for accessing product components. And some organisations shadow the Maven repo into their internal space or have their own Maven-based repo, and use their POM files to point at that instead of the default public location. But there’s an awful lot of code out there that assists with app development – pretty much anyone doing JavaScript for example is going to require access to NPM. The “corporate firewall” is going to have to become more porous. Which does not mean you should not take care about what you download, whether that’s for code quality, support, or licensing etc. And each repository will have some level of control over who posts where – items on Central are signed for example, and there are access controls on who can use the GroupId for submission of new jars etc.

Leave a Reply