How to configure a Jenkins job to deploy to JBoss AS/EAP from Artifactory or Nexus using the JBoss CLI

PROBLEM: you’ve got your Jenkins continuous integration jobs running just fine. You’ve got your Jenkins-driven snapshot and release jobs doing what you need them to do, including uploading the artifacts to Artifactory or Nexus. But now you want to actually deploy those artifacts from the Artifactory or Nexus repository to a running JBoss AS7/EAP6 server instance without rebuilding the project. In other words, you don’t want to rely just on JBoss deployment plugin, slick as it is.

SOLUTION: create a new Jenkins freestyle job that (1) uses Maven to download the artifact and then (2) uses the JBoss CLI to run the “deploy” command. In my instance, my servers were running in domain mode.


Configure a new Jenkins job

Creating the job is straightforward and probably familiar to you. Set it up as a “Freestyle project.”


To make the job really flexible, I use a free form list of parameters. (It might be too much flexibility, so see my notes below.)


Here’s the full list of build parameters I configured:

  • groupId – corresponds to the first of the four parts of Maven coordinates, as in groupId:artifact:version:packaging
  • artifact
  • version
  • packaging, which I set up as a “choice” option so it was prepoluated with war, jar, and ear
  • controller – this refers to the domain controller, but could be your standalone server instance
  • as_user – the JBoss AS administrative user account
  • as_password – password for the administrative user
  • server_group – the server group to be used in the domain-based deployment (if you’re running in standalone, you won’t need this)

Run this script as the Jenkins build

In a Linux environment, you pick up the parameters you configured above using the dollar sign and curly braces. In Windows, you’re going to wrap the variable name with percentage symbols. For example, ${groupId} would be %groupId%.

The first step in the script is to download the artifact — wherever it may live by using Maven’s built in artifact resolution technology. Some solutions I saw proposed hacking your want through the HTTP server URLs that power Maven, but I think this would be too difficult to maintain. Besides, the mvn dependency:get plugin does this for us — it resolves and installs the dependency, whatever it may be, for us.

The dependency:get plugin is useful, but it simply puts the artifact in your local Maven repository. We need to get the artifact in the Jenkins workspace directory. For that, we use mvn dependency:copy, which copies the artifact from your local repository into a workspace folder, target/dependency by default.

Finally, we’re going to issue the JBoss AS/EAP command line utility (“CLI”) to run the deployment. One interesting wrinkle to notice is that you have to add the –server-groups flag within the quotes for your command. I couldn’t find this neatly documented anywhere, so I hope it saves you a little time.

Interesting. But what can we do to improve it?

With the solution I proposed, anyone with a password could deploy any artifact anywhere. In reality, you’d want to tighten this down eventually by hard coding some of the values and controlling access to “who can deploy to what” environment, likely with the build pipeline (or similar) Jenkins plugin.

Unfortunately, even though I configured the as_password as a password field, for some reason it continues to display the clear text password in the log files. This is probably fixable so it will print a “masked” version of the password.

I created a little demo project along with the script in a Github repo, jboss-cli-deploy.

Leave a Reply

Your email address will not be published. Required fields are marked *