Building Java code on Linux using VSO Build.vNext

OK, one more post for today… This morning I promised you I would show you how to build Java code on a Linux build agent using the new Build.vNext build system in Visual Studio Online. This post is to deliver on that promise. Being a Linux and a Java newbie, I thought it would be a complex task. As it turns out, it isn’t. Once you have all the bits in place, the great new build system makes it easy to create a build definition that compiles the code. Actually, I even stuck some unit tests in there and got the test results to publish to VSO.

Before getting started, you should have two things in place:

• A Linux build agent, connected to your VSO account: Creating a Build.vNext agent on Linux
• Some Java code in a Git repository on VSO: Importing Java code into Git on Visual Studio Online from Eclipse

Project structure

For this post, I created a small demo Java project in Eclipse. I won’t go into all the details on how to do this, but there are a few things that I’d like to point out:

• The project uses Apache Maven to manage the build process. Maven is widely used for Java projects and support is integrated in Eclipse, as well as in Build.vNext.
• The project consists of a simple “Hello World” application. The main class file (“HelloMavenMain.java”) contains code that prints out a “Hello World” message and a method that performs an addition (not actually used anywhere).
• There are two unit tests for the project, which are defined in the “TestHelloMavenMain.java” file. These tests are written using the JUnit framework.

Prerequisites on the build agent

If you followed my post on creating a Build.vNext agent on Linux you’ll have most of the bits already installed on your agent. We only need to add some tools which are required specifically for building Java applications. Experienced Java developers will know this, but for all other developers I’ll mention them here.

• Java Development Kit (JDK): this contains the basic tools for compiling your source code
• Maven: the tool that will actually execute our build

You can install both by typing “sudo apt-get install default-jdk maven” in a console window.

You’ll notice that you will need A LOT of dependencies. I’m sure happy that apt-get is there to take care of installing those! Just type “Y” to get it going.

If you’re in need of a cup of coffee, this is the time to go and get it… After a while, all dependencies will have been installed. Now, restart your build agent so that it will pick up on the newly installed tools and register them as “capabilities” for the build service.

When you go into the VSO control panel and look at the properties of your build agent, you’ll notice that the agent has picked up on the newly installed Maven binary and registered it as a capability for itself.

We now have all the prerequisites figured out. Let’s get building!

Creating the build definition

The user experience for the Build.vNext system is entirely web-based. So, to create a Build.vNext build definition you’ll need to use the web interface. So, fire up your browser and connect to your VSO account. Navigate to the team project which holds your Java code and navigate to the “Build” tab. Then, click on the green “+” sign to create a new build definition.

There are a couple of templates pre-defined by the VSO team for Visual Studio, Xamarin and Xcode builds. Since we’re not doing any of that, we’ll start with a clean slate and select the “Empty” option.

This will create a new build definition, which currently does not contain any build steps.

We’ll start by configuring the repository from which we want to build the code. Navigate to the “Repository” tab and select your repository type and your repository and branch. Additionally, I’ve specified “Clean = true” so that the working directory of the agent is cleaned before each build.

On the “General” tab, set the default queue that this build definition should use. Since I want to build on Linux, I’m specifying my “Linux” build queue. Optionally, you can specify a description and a build number format.

If you want, you can go ahead and change the retention policy on the “Retention” tab. For now, I’m not bothering with that. We’ll now go ahead and define the build process itself. For that, navigate to the “Build” tab and click “Add build step…”.

You’ll be presented with a screen in which you can select from the available build tasks. The list is already quite long, but will likely be expanded in the future. You’ll notice that there is already a task there to perform a Maven build. We’ll go ahead and add that to our build process.

In the configuration of the Maven build task, we need to specify our POM file. In the “Options” field, I have specified “-e” so that Maven will print out a stack trace if anything goes wrong. That’ll help in debugging. The default goal is “package”, which is fine in our case. We’ll also leave the “Publish to VSO/TFS” check box marked for the JUnit Test Results so that we’ll be able to analyze our unit test runs later.

Next, we’ll add another build step for publishing our built binaries to the server, so we can get them from there later.

We’ll configure the “Publish Artifact” task to copy everything in the “target” folder to the server in an artifact called “drop”. Finally, set the “Always Run” checkbox to on, so that artifacts like buildlogs are published, even if a previous build step fails.

Finally, save your build definition and give it a useful name. Since build definitions are versioned in Build.vNext, you’ll also need to provide a comment which will appear in the history of the build definition.

That’s it! Our build definition is ready. Now we can run the build…

Running the build and viewing results

To queue a new build, click the little triangle before your build definition and click “Queue build…”.

Optionally, you can change the Queue, Branch or specify a commit id which you want to build. For now, just click “OK”.

  The build will start running and after a while you should be seeing the green “Build Succeeded” message!

Did you notice that we never specified on which operating system our build is running? This is one of the cool features of Build.vNext! Since the tasks are written using  Node.js they can execute on any platform. You can click the build number to navigate to the “Build summary” page.

The page will give you a basic overview of how the build went. Click the reload icon to load the test results. You can view details by click on the name of the run.

You’ll be able to view detailed results for the test run. Remember, this is Java code being tested by JUnit!

For getting the binaries that were produced by the build, go back to the build summary page, click “Artifacts” and then “Explore”.

You’ll be able to browse through the build output. This includes compiled classes, test reports and of course also the final .jar file. You can download a file by clicking the little triangle and then “Download”.

  And there you have it! Java code, imported into VSO from Eclipse, built on a Linux build agent. While the application that I’ve built in this post in itself isn’t very useful, I do think it is a very nice demonstration of the direction that Microsoft is headed in: develop, build and run on many platforms.

Happy building!