Building Wholly Graal with Truffle!

Citation: credits to the feature image go to David Luders and reused under a CC license, the original image can be found on this Flickr page.

Introduction

It has been some time, since the two posts [1][2] on Graal/GraalVM/Truffle, and a general request was when are you going to write something about “how to build” this awesome thing called Graal. Technically, we will be building HotSpot’s C2 compiler (look for C2 in the glossary list) replacement, called Graal. This binary is different from the  GraalVM suite you download from OTN via http://graalvm.org/downloads.

I wasn’t just going to stop at the first couple of posts on this technology. In fact, one of the best ways to learn and get an in-depth idea about any tech work, is to know how to build it.

Getting Started

Building JVMCI for JDK8, Graal and Truffle is fairly simple, and the instructions are available on the graal repo. We will be running them on both the local (Linux, MacOS) and container (Docker) environments. To capture the process as-code, they have been written in bash, see https://github.com/neomatrix369/awesome-graal/tree/master/build/x86_64/linux_macos.

During the process of writing the scripts and testing them on various environments, there were some issues, but these were soon resolved with the help members of the Graal team — thanks Doug.

Running scripts

Documentation on how to run the scripts are provided in the README.md on awesome-graal. For each of the build environments they are merely a single command:

Linux & MacOS

$ ./local-build.sh

$ RUN_TESTS=false           ./local-build.sh

$ OUTPUT_DIR=/another/path/ ./local-build.sh

Docker

$ ./docker-build.sh

$ DEBUG=true                ./docker-build.sh

$ RUN_TESTS=false           ./docker-build.sh

$ OUTPUT_DIR=/another/path/ ./docker-build.sh

Both the local and docker scripts pass in the environment variables i.e. RUN_TESTS and OUTPUT_DIR to the underlying commands. Debugging the docker container is also possible by setting the DEBUG environment variable.

For a better understanding of how they work, best to refer to the local and docker scripts in the repo.

Build logs

I have provided build logs for the respective environments in the build/x86_64/linux_macos  folder in https://github.com/neomatrix369/awesome-graal/

Once the build is completed successfully, the following messages are shown:

[snipped]

>> Creating /path/to/awesome-graal/build/x86_64/linux/jdk8-with-graal from /path/to/awesome-graal/build/x86_64/linux/graal-jvmci-8/jdk1.8.0_144/linux-amd64/product
Copying /path/to/awesome-graal/build/x86_64/linux/graal/compiler/mxbuild/dists/graal.jar to /path/to/awesome-graal/build/x86_64/linux/jdk8-with-graal/jre/lib/jvmci
Copying /path/to/awesome-graal/build/x86_64/linux/graal/compiler/mxbuild/dists/graal-management.jar to /path/to/awesome-graal/build/x86_64/linux/jdk8-with-graal/jre/lib/jvmci
Copying /path/to/awesome-graal/build/x86_64/linux/graal/sdk/mxbuild/dists/graal-sdk.jar to /path/to/awesome-graal/build/x86_64/linux/jdk8-with-graal/jre/lib/boot
Copying /path/to/awesome-graal/build/x86_64/linux/graal/truffle/mxbuild/dists/truffle-api.jar to /path/to/awesome-graal/build/x86_64/linux/jdk8-with-graal/jre/lib/truffle

>>> All good, now pick your JDK from /path/to/awesome-graal/build/x86_64/linux/jdk8-with-graal :-)

Creating Archive and SHA of the newly JDK8 with Graal & Truffle at /home/graal/jdk8-with-graal
Creating Archive jdk8-with-graal.tar.gz
Creating a sha5 hash from jdk8-with-graal.tar.gz
jdk8-with-graal.tar.gz and jdk8-with-graal.tar.gz.sha256sum.txt have been successfully created in the /home/graal/output folder.

Artifacts

All the Graal and Truffle artifacts are created in the graal/compiler/mxbuild/dists/ folder and copied to the newly built jdk8-with-graal folder, both of these will be present in the folder where the build.sh script resides:

jdk8-with-graal/jre/lib/jvmci/graal.jar
jdk8-with-graal/jre/lib/jvmci/graal-management.jar
jdk8-with-graal/jre/lib/boot/graal-sdk.jar
jdk8-with-graal/jre/lib/truffle/truffle-api.jar

In short, we started off with vanilla JDK8 (JAVA_HOME) and via the build script created an enhanced JDK8 with Graal and Truffle embedded in it. At the end of a successful build process, the script will create a .tar.gz archive file in the jdk8-with-graal-local folder, alongside this file you will also find the sha5 hash of the archive.

In case of a Docker build, the same folder is called jdk8-with-graal-docker and in addition to the above mentioned files, it will also contain the build logs.

Running unit tests

Running unit tests is a simple command:

mx --java-home /path/to/jdk8 unittest

This step should follow the moment we have a successfully built artifact in the jdk8-with-graal-local folder. The below messages indicate a successful run of the unit tests:

>>>> Running unit tests...
Warning: 1049 classes in /home/graal/mx/mxbuild/dists/mx-micro-benchmarks.jar skipped as their class file version is not supported by FindClassesByAnnotatedMethods
Warning: 401 classes in /home/graal/mx/mxbuild/dists/mx-jacoco-report.jar skipped as their class file version is not supported by FindClassesByAnnotatedMethods
WARNING: Unsupported class files listed in /home/graal/graal-jvmci-8/mxbuild/unittest/mx-micro-benchmarks.jar.jdk1.8.excludedclasses
WARNING: Unsupported class files listed in /home/graal/graal-jvmci-8/mxbuild/unittest/mx-jacoco-report.jar.jdk1.8.excludedclasses
MxJUnitCore
JUnit version 4.12
............................................................................................
Time: 5.334

OK (92 tests)

JDK differences

So what have we got that’s different from the JDK we started with. If we compare the boot JDK with the final JDK here are the differences:

Combination of diff between $JAVA_HOME and jdk8-with-graal and meld will give the above:

diff -y --suppress-common-lines $JAVA_HOME jdk8-with-graal | less

meld $JAVA_HOME ./jdk8-with-graal

Note: $JAVA_HOME points to your JDK8 boot JDK.

Build execution time

The build execution time was captured on both Linux and MacOS and there was a small difference between running tests and not running tests:

Running the build with or without tests on a quad-core, with hyper-threading:

 real 4m4.390s
 user 15m40.900s
 sys 1m20.386s
 ^^^^^^^^^^^^^^^
 user + sys = 17m1.286s (17 minutes 1.286 second)

Similar running the build with and without tests on a dual-core MacOS, with 4GB RAM, SSD drive, differs little:

 real 9m58.106s
 user 18m54.698s 
 sys 2m31.142s
 ^^^^^^^^^^^^^^^ 
 user + sys = 21m25.84s (21 minutes 25.84 seconds)

Disclaimer: these measurements can certainly vary across the different environments and configurations. If you have a more accurate way to benchmark such running processes, please do share back.

Summary

In this post, we saw how we can build Graal and Truffle for JDK8 on both local and container environments.

The next thing we will do is build them on a build farm provided by Adopt OpenJDK. We will be able to run them across multiple platforms and operating systems, including building inside docker containers. This binary is different from the GraalVM suite you download from OTN via http://graalvm.org/downloads, hopefully we will be able to cover GraalVM in a future post.

Thanks to Julien Ponge for making his build script available for re-use and the Graal team for supporting during the writing of this post.

Feel free to share your feedback at @theNeomatrix369. Pull requests with improvements and best-practices are welcome at https://github.com/neomatrix369/awesome-graal.

Why not build #OpenJDK 9 using #Docker ? – Part 2 of 2

…continuing from Why not build #OpenJDK 9 using #Docker ? – Part 1 of 2.

I ran into a number of issues and you can see from my commits, I pulled myself out of it, but to run this Dockerfile from the command-line I used this instruction:

$ docker build -t neomatrix369/openjdk9 .

you can also do it using the below if you have not set your permissions:

$ sudo docker build -t neomatrix369/openjdk9 .

and get the below (summarised) output:

Sending build context to Docker daemon 3.072 kB
Sending build context to Docker daemon 
Step 0 : FROM phusion/baseimage:latest
 ---> 5a14c1498ff4
Step 1 : MAINTAINER Mani Sarkar (from @adoptopenjdk)
 ---> Using cache
 ---> 95e30b7f52b9
Step 2 : RUN apt-get update &&   apt-get install -y     libxt-dev zip pkg-config libX11-dev libxext-dev     libxrender-dev libxtst-dev libasound2-dev libcups2-dev libfreetype6-dev &&   rm -rf /var/lib/apt/lists/*
 ---> Using cache
 ---> 1ea3bbb15c2d
Step 3 : RUN apt-get update
 ---> Using cache
 ---> 6c3938f4d23d
Step 4 : RUN apt-get install -y mercurial ca-certificates-java build-essential
 ---> Using cache
 ---> e3f99b5a3bd3
Step 5 : RUN cd /tmp &&   hg clone http://hg.openjdk.java.net/jdk9/jdk9 openjdk9 &&   cd openjdk9 &&   sh ./get_source.sh
 ---> Using cache
 ---> 26cfaf16b9fa
Step 6 : RUN apt-get install -y wget &&   wget --no-check-certificate --header "Cookie: oraclelicense=accept-securebackup-cookie" http://download.oracle.com/otn-pub/java/jdk/8u45-b14/jdk-8u45-linux-x64.tar.gz
 ---> Using cache
 ---> 696889250fed
Step 7 : RUN tar zxvf jdk-8u45-linux-x64.tar.gz -C /opt
 ---> Using cache
 ---> c25cc9201c1b
Step 8 : RUN cd /tmp/openjdk9 &&   bash ./configure --with-cacerts-file=/etc/ssl/certs/java/cacerts --with-boot-jdk=/opt/jdk1.8.0_45
 ---> Using cache
 ---> 4e425de379e6
Step 9 : RUN cd /tmp/openjdk9 &&   make clean images
 ---> Using cache
 ---> 2d9e17c870be
Step 10 : RUN cd /tmp/openjdk9 &&   cp -a build/linux-x86_64-normal-server-release/images/jdk     /opt/openjdk9
 ---> Using cache
 ---> 9250fac9b500
Step 11 : RUN cd /tmp/openjdk9 &&   find /opt/openjdk9 -type f -exec chmod a+r {} + &&   find /opt/openjdk9 -type d -exec chmod a+rx {} +
 ---> Using cache
 ---> d0c597d045d4
Step 12 : ENV PATH /opt/openjdk9/bin:$PATH
 ---> Using cache
 ---> 3965c3e47855
Step 13 : ENV JAVA_HOME /opt/openjdk9
 ---> Using cache
 ---> 5877e8efd939
Successfully built 5877e8efd939

The above action creates an image which is stored in your local repository (use docker images to enlist the images in the repo). If you want to load the image into a container, and access the files it has built or see anything else, do the below:

$ sudo docker run -it --name openjdk9 neomatrix369/openjdk9 /bin/bash

this will take you to a bash prompt into the container and you can run any of your linux commands and access the file system.

Explaining docker run

$ sudo docker run -it --name openjdk9 neomatrix369/openjdk9 java -version

will show you this

openjdk version "1.9.0-internal"
OpenJDK Runtime Environment (build 1.9.0-internal-_2015_06_04_06_46-b00)
OpenJDK 64-Bit Server VM (build 1.9.0-internal-_2015_06_04_06_46-b00, mixed mode)

Here’s a breakdown of the docker run command:

docker run	The command to create and start a new Docker container.
-it	To run in interactive mode, so you can see the after running the container.
neomatrix369/openjdk9	This is a reference to the image tag by name (which we created above).
java -version	Runs the java command asking its version, inside the containing, which is assisted by the two environment variables PATH and JAVA_HOME which was set in the Dockerfile above.

Footnotes

You might have noticed I grouped very specific instructions with each step, especially the RUN commands, its because, each time I got one of these wrong, it would re-execute the step again, including the steps that ran fine and didn’t need re-executing. Not only is this unnecessary its not using our resources efficiently which is what Docker brings us. So any addition, edition or deletion to any step will only result in that step being executed, and not the other steps that are fine.

So one of the best practises is to keep the steps granular enough and pre-load files and data beforehand and give it to docker. It has amazing caching and archiving mechanisms built in.

Save our work

As we know if we do not save the container into the image, our changes are lost.

If I didn’t use the docker build command I used earlier I could have, after the build process was completed and image created, used the below command:

$ sudo docker commit [sha of the image] neomatrix369/openjdk9

Sharing your docker image on Docker hub

Once you are happy with your changes, and want to share it with community at large, do the below:

$ sudo docker push neomatrix369/openjdk9

and you will see these depending on which of your layers have been found in the repo and which ones are new (this one is an example snapshot of the process):

The push refers to a repository [neomatrix369/openjdk9] (len: 1)
5877e8efd939: Image already exists 
3965c3e47855: Image already exists 
d0c597d045d4: Image already exists 
9250fac9b500: Image already exists 
2d9e17c870be: Buffering to Disk
.
.
.

There is plenty of room for development and improvement of this Docker script. So happy hacking and would love to hear your feedback or contributions from you.

BIG Thanks

Big thanks to the below two who proof-read my post and added value to it, whilst enjoying the #Software #Craftsmanship developer community (organised and supported by @LSCC):
Oliver Nautsch – @ollispieps (JUG Switzerland)
Amir Bazazi (@Codurance) – @amirbazazi

Special thanks to Roberto Cortez (@radcortez) for your Docker posts, these inspired and helped me write my first Docker post.

Resources

[1] Docker
[2] Get into Docker – A Guide for Total Newbies
[3] Docker for Total Newbies Part 2: Distribute Your Applications with Docker Images
[4] Docker posts on Voxxed
[5] OpenJDK
[6] Building OpenJDK
[7] Building OpenJDK on Linux, MacOs and Windows
[8] Virtual Machines (OpenJDK)
[9] Build your own OpenJDK
[10] Vagrant script (OpenJDK)
[11] YOUR DOCKER IMAGE MIGHT BE BROKEN without you knowing it
[12] Dockerfile on github
[13] Adopt OpenJDK: Getting Started Kit
[14] London Java Community

Installing SonarQube ™ (formerly Sonar ™) on Mac OS X Mountain Lion 10.8.4

Introduction

How do we know “how it is being done” when we look at a product or even a code-base of a F/OSS project? In today’s high-speed, fast-paced software industry getting something out quick and earning lots points at the end of a sprint, is becoming a mainstream practise these days. If you want to make sure you are sticking to your Software Craftsmanship motto: “We do not want to ship s**t” like Uncle Bob very rightly says – then you have gotta find a better way to streamline your development process to achieve just that!

That’s when tools like SonarQube ™ (formerly known as Sonar ™) come to our rescue or at least help us in the interim to get a better understanding of what software metrics and software quality can mean for your team! How to compare progress on a timeline and use it to get quick feedback to assess and improve the quality of the code we write and maintain is certainly an important thing to be able to do.

Installing SonarQube on a Mac OS X system hasn’t been as smooth as on systems with a Linux/Unix environment hence this blog. With some tweaks, assistance from third-party sites and following the do-s and don’t-s you should be able to get long and successfully install SonarQube and SonarQube Runner!

As installing and configuring SonarQube is an involved process, a number of items need to be taken into consideration and they have been categorised below under the various topics and sub-topics. Hopefully this makes the journey easier for all of us – since we have done it once and it has been a bit painful, its here for everyone else’s benefit.

Requirements

The below is a list of hardware/software installations are required to get success out of the instructions put together in this blog:

• Mac OS X Mountain Lion 10.8.4
• SonarQube 3.7 artefacts
• SonarQube Runner 2.3 artefacts
• MySQL 5.6.12
• JDK/JRE 1.7.0 or 1.8.0

Environment

These instructions have been performed on a system with the below configuration:

Model Name: MacBook Pro    
  Processor Name: Intel Core i7
  Processor Speed: 2.3 GHz
  Total Number of Cores:  4
  Memory: 8 GB

HDD Capacity:  249.8 GB (SSD)

System Version:  OS X 10.8.4
Java version: 1.8.0-ea-b103

Downloading, installing and configuring MySQL

A suitable MySQL binary can be downloaded from [01] or directly from [02].

Installing & configuring

MySQL must be present on the machine running SonarQube – which is the data store where all the relevant metrics per project are stored. To find out on how to go about installing MySQL on the Mac, please refer to the blog post How to install and configure MySQL on MacOS X for UTS [13]. The below window is an indication of a successful installation (System Preferences > Other > MySQL – blue icon at the bottom of the window):

Once the installation is complete, the create SonarQube database SQL script [14]will require to be run via the MySQL console or through another SQL client that can connect to the currently running MySQL server.

Hint: MySQL Workbench for the Mac can be downloaded from this MySQL dev site [03].

Command-line Interface (CLI)

There’s also a few other commands to know as part of daily MySQL operations:

(start the MySQL)
$ sudo $MYSQL_HOME/bin/mysqld_safe &
- or -
$ sudo $MYSQL_HOME/support-files/mysql.server start &

(restart the MySQL if its running)
$ sudo $MYSQL_HOME/support-files/mysql.server restart &

(stop the MySQL if its running)
$ sudo $MYSQL_HOME/bin/mysqladmin shutdown &
- or -
$ sudo $MYSQL_HOME/support-files/mysql.server stop &

Where MYSQL_HOME was set to /usr/local/mysql (check if it is the same in your case) in the respective bash configuration file.

In order to not perform the above command on a regular basis, ensure that the Automatically Start MySQL Server on Startup is switched on.

Check if the database has been created correctly, by performing the below commands on the CLI (look for the highlighted database, you will also need to enter the root password for your MySQL server here):

$ mysql -u root -p

mysql> show databases
+--------------------+
| Database           |
+--------------------+
| information_schema |
| mysql              |
| performance_schema |
| sonar              |
| test               |
+--------------------+

Installing & configuring JDK/JRE

A JDK/JRE must be present on the machine running SonarQube (the java –version command on the CLI, followed by the whereis java or a peek into the  /Library/Java/JavaVirtualMachines/ should indicate the version and location of the JDK/JRE on the machine concerned). A version of the JDK/JRE can be downloaded from either Oracle or Apple’s Java support and download websites. Once installed (or if already present on the system), ensure that the JAVA_HOME is set to the appropriate location, for e.g.:

JAVA_HOME = /Library/Java/JavaVirtualMachines/jdk1.7.0_25.jdk/Contents/Home/jre

Downloading, installing and configuring SonarQube

Downloading
Download the latest binaries from the SonarSource downloads site [04].

Installing & configuring

Unzip the archive into a folder of your choice for e.g. the /opt/ folder. Once done, set the SONAR_HOME environment variable to point to this location, in the respective bash configuration file:SONAR_HOME = /opt/sonar-3.7/

Source the bash configuration file and perform the below actions to ensure that SonarQube can connect with the available MySQL database:

$ cd $SONAR_HOME/conf
$ vim sonar.properties

1. comment the derby configuration
2. uncomment the mysql configuration,
3. save the changes and close the file.

Also note SonarQube’s JDBC credentials are:

login: sonar
password: sonar

By default the web port where SonarQube is listening, is set to 9000, which can be changed in the $SONAR_HOME/conf/sonar.properties file. Change the sonar.web.port property to another setting if port 9000 is being used by another application, i.e.

    sonar.web.port=9100

There’s one more place where this is defined and must be in sync with this file, see below in the settings.xml file – the line referring to …localhost:9000… which should be changed as well (to …localhost:9100… if the port settings in the $SONAR_HOME/conf/sonar.properties  is also changed).

Install maven if it does not exists already (recent versions of the Mac OS X comes with maven installed), ensure it is included in system path i.e. PATH and run the below command at the CLI to verify this:

mvn -version

Check if the below maven options are set otherwise set the MAVEN_OPTS environment variable in the respective bash configuration files:

export MAVEN_OPTS="-Xmx512m -XX:MaxPermSize=128m"

Finally put the settings.xml containing the below lines into the ./m2 folder (maven’s configuration folder):

<settings>
    <profiles>
        <profile>
            <id>sonar</id>
            <activation>
                <activeByDefault>true</activeByDefault>
            </activation>
            <properties>
                <!-- Example for MySQL-->
                <sonar.jdbc.url>
                  jdbc:mysql://localhost:3306/sonar?useUnicode=true&characterEncoding=utf8
                </sonar.jdbc.url>
                <sonar.jdbc.username>sonar</sonar.jdbc.username>
                <sonar.jdbc.password>sonar</sonar.jdbc.password>
 
                <!-- Optional URL to server. Default value is http://localhost:9000 -->
                <sonar.host.url>
                  http://myserver:9000
                </sonar.host.url>
            </properties>
        </profile>
     </profiles>
</settings>

(additional reference: Installing and Configuring Maven [05])

Upgrading SonarQube from the current 3.x.y to version 3.7

In case you already have SonarQube installed from a previous attempt, then you would just need to upgrade to the new version. But before upgrading to a newer version, please ensure the existing database is backed up, just in case the upgrade process does not restore the existing data (use the Backup facility available under the Settings menu option or go to it directly via http://localhost:9000/backup).

Upgrading to a newer version of SonarQube is as easy as downloading the latest binary and placing the expanded folder into the /opt/ folder or elsewhere on your system, updating the environment variables via the respective bash configuration files (see previous section).Restart SonarQube (see below section to know how to do that), wait for a couple of minutes, and finally run the database migration process by opening the below location via the browser and clicking on the Upgrade button:

http://localhost:9000/setup

…this should take few minutes and the databases should be migrated to the latest version.

Once finished, navigate to the web address http://localhost:9000/ to see the very familiar SonarQube dashboard (see below the screen-shot of the live SonarQube implementation i.e. Nemo [06] on  as an example):

Once the dashboard has been been presented, log in by clicking on the Log in link on the top right corner of the browser window with the below credentials:

username: admin
password: admin

Running SonarQube via the CLI

Starting SonarQube from the CLI with the below command:

$ sudo $SONAR_HOME/bin/<b>macosx-universal-64</b>/sonar.sh <b>start</b>

or restarting it, if it is already running:

$ sudo $SONAR_HOME/bin/<b>macosx-universal-64</b>/sonar.sh <b>restart</b>

…stopping it is the same:

$ sudo $SONAR_HOME/bin/<b>macosx-universal-64</b>/sonar.sh <b>stop</b>

A few other parameters are available i.e. console, status and dump – SonarQube needs to be running in order for any of these to work, which you will find out very easily with the “sonar is not running.” message.

Note: MySql must be running when SonarQube is (re)started. In the above case it is assumed that SonarQube is installed in the /opt/ folder.


Download, install and configure SonarQube Runner

SonarQube can be setup to analyse projects through various ways, one of the other ways is to use SonarQube Runner, which requires a sonar-projects.properties file that would contain the basic definitions of the nature of the project. It is used in case the project to analyse is not maven project (does not have a pom.xml file).SonarQube Runner can be downloaded from the same location where the SonarQube binaries are kept [04].

Unzip the archive containing the binary for SonarQube Runner into a folder i.e. /opt/ folder and set the environment variable SONAR_RUNNER to this location in the respective bash configuration files.

SONAR_RUNNER = /opt/sonar-runner-2.3/

Now open the $SONAR_RUNNER/conf/sonar-runner.properties file to enable the configuration to refer to the running SonarQube instance. Uncomment all the lines except the ones containing the settings to Postgres, Oracle and Microsoft servers.

Checking SonarQube or SonarQube Runner 

We will cover the two ways SonarQube can be used to analyse a project (written in one of the SonarQube supported programming languages [07]) by either via maven or through sonar-runner (for non-maven projects).

via maven

 

Here are a couple of links to sample pom.xml files which should help with creating new/ amend existing configurations to integrate maven projects with SonarQube (including additional maven CLI switches) i.e. Analyzing with Maven [08] and SonarQube examples on Github [09]

via sonar-runner

 

Here are a couple of links to sample sonar-project.properties files to assisting in creating new ones i.e. Sonar setup for non-maven Java project [10] and Analyzing with SonarQube Runner [11].

Troubleshooting

The log files created in the $SONAR_HOME/logs folder is a good place to look when faced with build failures or when the web GUI throws unexplainable errors. Also examine this file during the migration process from an older version to a newer one.

In particular $SONAR_HOME/logs/sonar.log contains SonarQube specific system level log messages.

Tips

All the CLI commands can be set as aliases in the respective bash configuration files as shown here [12].

Add the below settings to the environment variable PATH definition in the respective bash configuration files:

 $SONAR_HOME/bin
 $SONAR_RUNNER/bin
 $MYSQL_HOME/bin

Always source the bash configuration files after amending them.

Terminologies used
 bash configuration file    ---  $HOME/.bashrc    -or-   $HOME/.bash_profile
 CLI                              ----   command-line interface

External resources

During the installation of SonarQube, a number of links came to rescue by helping tackle some technical challenges and have been mentioned throughout the blog including some below.

[01] http://dev.mysql.com/downloads/mysql/%C2%A0
[02] http://dev.mysql.com/downloads/mirror.php?id=413090
[03] http://dev.mysql.com/get/Downloads/MySQLGUITools/mysql-workbench-gpl-5.2.47-osx-i686.dmg/from/http://cdn.mysql.com/
[04] http://www.sonarsource.org/downloads/
[05] http://docs.codehaus.org/display/SONAR/Installing+and+Configuring+Maven
[06] http://nemo.sonarqube.org/ (Live SonarQube implementation)
[07] http://docs.codehaus.org/display/SONAR/Plugin+Library (List of languages, plugins & tools supported by SonarQube)
[08] http://docs.codehaus.org/display/SONAR/Analyzing+with+Maven
[09] https://github.com/SonarSource/sonar-examples
[10] http://sohamniyogi.wordpress.com/2012/12/20/sonar-setup-for-non-maven-java-project/
[11] http://docs.codehaus.org/display/SONAR/Analyzing+with+SonarQube+Runner
[12] http://www.cyberciti.biz/tips/bash-aliases-mac-centos-linux-unix.html
[13] http://www.extensis.com/support/knowledge-base/how-to-connect-uts-to-mysql-server-on-macos-x/
[14] http://svn.codehaus.org/sonar/branches/GSOC/sonar-application/src/main/assembly/extras/database/mysql/create_database.sql

SonarQube website
SonarQube screen-shots

Sonar project examples on github (multi-languages)

Extend Sonar Integration
Eclipse Sonar plugin

MySQL Tuner
Installing Sonar on the CI server (2011)
Installing Sonar on a linux build server (2009)

Notes

In theory these instructions should work on other versions of Mac OS X as well, but they have only been tested on the above environment (see section Environment). 

These instructions are in principle similar to the steps for Ubuntu or other Unix/Linux based OSes – with some tweaks it should be possible to install and run SonarQube in such environments as well.

The terms Sonar and SonarQube have been used interchangeably in a number of places above. Some of it is due to the referred links not being updated, and others are due to the fact that scripts and program references have continued to be used with their original names to prevent issues with dependencies.

Do not take the settings, paths and file locations, url references, excetra mentioned in this blog literally, in some cases they would need to be adjusted to settings relevant to your environment.

Please note all the external links on this blog may or may not stay actual and is not feasible to maintain them as part of this blog post.

Please feel free to contribute to the above post in the form of constructive comments, useful links, additional information, excetra to improve the quality of the information provided. If something hasn’t worked for you and you have managed to make it work or have a work-around / alternative solution, please do share it with us!

---

Also see “How to use SonarQube and SonarQube Runner on the Mac OS X…“

---