Java aktuell published an article I wrote on a topic at work for TRIOLOGY GmbH.
You can find an English version on the TRIOLOGY Blog: Automatic checks for vulnerabilities in Java project dependencies. The article shows an approach to keeping your Java project dependencies free of known vulnarabilities (e.g. CVEs) using the OWASP Dependency check with Jenkins and Maven. There also is an example project on GitHub.
The original article PDF (in German) is available for download here: Automatisierte Überprüfung von Sicherheitslücken in Abhängigkeiten von Java-Projekten.
TRIOLOGY also published a short Q&A on the article, which can be found here.
Earlier this year, while working on a project for TRIOLOGY GmbH, I once again used maven to write a version name into an application, using the mechanism described in my post Maven: Create a simple build number. As a more sophisticated version name was required for this project, we expanded it by a time stamp, SCM information (branch and commit), build number and a also created a special name for releases. You can find a how-to here – Version names with Maven: Creating the version name – which is the first part of a small series of blog posts on this topic.
The second part shows how the version name can be read from within the application. While writing the examples for the post, I wondered how many times I must have implemeted reading a version name from a file in Java. Way too often! So I decided that this would be the very last time I had to do it, and extracted the logic into a small library: versionName, availble on GitHub. What it does and how to use it is described in the second part of the post: Version names with Maven: Reading the version name.
Hopefully, this will be useful for someone else. Funny enough, in the new project I’m on, I’m about to reuse it once again. I’m glad I don’t have to write it again. Here’s to reusability 🍺
Time for an update of the post Building GitHub projects with Jenkins, Maven and SonarQube 4.1.1 on OpenShift, because SonarQube 5.2 is out: It’s the first version since 4.1.1 that can be run on OpenShift. That is, it’s the first version of SonarQube 5 and the first one that contains Elasticsearch and many other features that are now available on OpenShift!
Interested? Then let’s see how to set up SonarQube on OpenShift.
- If you’re starting from scratch, just skip to this section.
- If you got a running instance of SonarQube
Install new SonarQube instance
To install SonarQube 5.2, execute the following steps on your machine:
rhc app create sonar diy-0.1 postgresql-9.2
Make sure to remember the login and passwords!
git rm -r diy .openshift misc README.md
git remote add upstream -m master https://github.com/schnatterer/openshift-sonarqube.git
git pull -s recursive -X theirs upstream master
- Login to your SonarQube instance at
Note that the initial setup may take some minutes. So be patient.
The default login and passwords are
You might want to change the password right away!
Basic installation Jenkins
Basically, the following is an updated (and a lot simpler) version of my post about SonarQube 4.1.1.
- Create Jenkins app
rhc app create jenkins jenkins-1
- Install Plugins
Check Now (as described here).
Then go to the
Available tab and install
- Sonar Plugin,
- GitHub plugin,
- embeddable-build-status (if you’d like to include those nifty build badges in you README.md).
Install without restart or
Download and install after restart. If necessary, you can restart your app anytime like so
rhc app restart -a jenkins
- Set up maven settings.xml to a writable location.
- SSH to Jenkins
echo -e "&amp;lt;settings&amp;gt;&amp;lt;localRepository&amp;gt;$OPENSHIFT_DATA_DIR/.m2&amp;lt;/localRepository&amp;gt;&amp;lt;/settings&amp;gt;" &amp;gt; $OPENSHIFT_DATA_DIR/.m2/settings.xml
- Browse to
Default settings provider: Settings file in file system
- Either see my post on how to introduce a dedicated slave node to this setup or
set up the Jenkins master to run its own builds as follows (not recommended on small gears, as you might run out of memory pretty fast during builds):
# of executors: 1
- Setup sonar plugin (the following bases on SonarQube Plugin 2.3 for Jenkins)
On the Jenkins frontend, go to
Configure build for a repository
Now lets set up our first build.
- Go to
Item name: <your Project name>
(Unfortunately, Maven projects do not work due to OpenShift’s restrictions.)
- On the next Screen
https://github.com/<your user>/<your repo>/
Source Code Management:
https://github.com/<your user>/<your repo>.git
Branch Specifier (blank for 'any'): origin/master
Build Triggers: Tick
Build when a change is pushed to GitHub
Build Environment: Tick
Prepare SonarQube Scanner environment
# Start the actual build
mvn clean package $SONAR_MAVEN_GOAL --settings $OPENSHIFT_DATA_DIR/.m2/settings.xml -Dsonar.host.url=$SONAR_HOST_URL
- I’d also recommend the following actions
Add post-build action|
Publish JUnit test result report
Test report XMLs=target/surefire-reports/TEST-.xml*
Add post-build action|
Recipients=<your email address>
- Finally, press
Save and start you first build. Check Jenkins console output for errors. If everything succeeds you should see the result of the project’s analysis on SonarQube’s dashboard.
[EDIT (2016-06-02): OpenShift now provides different JDK “alternatives”, e.g.
So you might want to skip the steps bellow, regarding a custom JDK. The steps described for using a custom maven still apply, however.
In previous posts I pointed out how to build GitHub projects with Jenkins, Maven and SonarQube and how to run these builds on dedicated Jenkins slaves. The following shows how to replace the “stock” versions of maven and JDK that are provided by OpenShift.
At the time of writing OpenShift features Maven 3.0.4 and OpenJDK Server 1.7.0_85. Why would you want to change those? Best example is a Java8 project to be build on Jenkins. Can we just advise Jenkins to download the newest Oracle JDK and we’re good to go? Nope, it’s not that simple on OpenShift! Jenkins does download the new JDK, sets the
JAVA_HOME variable and the correct
PATH, but maven is always going to use the stock JDK. Why? Running this command provides the answer
$ cat `which mvn`
exec $M2_HOME/bin/$prog &quot;$@&quot;
The stock maven is setting its own environment variables that cannot be overridden by Jenkins!
So, in order to exchange the JDK, we need to exchange maven first.
- SSH to the machines where your builds are executed (e.g. your slave node). The following example show what to do for maven 3.3.3:
tar -xvf apache-maven-3.3.3-bin.tar.gz
- Edit maven config
Add the following to the
<settings> tag (replace
<UID> by your OpenShift UID first)
i button for edit mode, insert, then press
esc button, enter
:wq, finally press return button)
- Browse to
Set Environment variables
- And that’s it, your builds are now running on the custom maven!
This allows for using a specific JDK in Jenkins. You could just choose a specific JDK via Jenkins console. This is comfortable, but has one disadvantage: It takes a lot of memory (approx. 600MB per JDK), because the JDK is stored twice – compressed in cache to be sent to slave and again uncompressed to be used on the master. If you got enough memory, you’re done here.
However, In case you’re running a small gear with only 1GB of memory, you might want to save a bit of your precious memory. The following example shows how to do so for JDK 8 update 51 build 16.
wget --no-check-certificate --no-cookies --header &quot;Cookie: oraclelicense=accept-securebackup-cookie&quot; http://download.oracle.com/otn-pub/java/jdk/8u51-b16/jdk-8u51-linux-x64.tar.gz
tar -xvf jdk-8u51-linux-x64.tar.gz
- Then go to Jenkins
JDK installations | JDK
This post showed how to build GitHub projects with Jenkins, Maven and SonarQube 4 on OpenShift. For starters, it used the Jenkins master node for running build jobs. However, when running on a small gear, the master node might run out of memory pretty fast, resulting in a reboot of the node during builds.
In order to resolve this issue, there are two options:
- limitting the memory of the build or
- running the build on a slave node.
As spawning additional nodes is easy in a PaaS context such as OpenShift and provides a better performance than running builds with small memory, the slave solution seems to be the better approach.
This post shows how.
- Create new DYI app as a slave node (a how-to can be found here), name the node e.g.
- Create node in Jenkins
- Go to Jenkins web UI and create new node:
- Set the following values:
Remote FS root:/app-root/data folder on slave. Typically this is
/var/lib/openshift/<slave's UID>/app-root/data/jenkins, you can find out by SSHing to the slave node and calling
Labels: Some label to use within builds to refer the node, e.g.
OS Slave #1
Host: the slave’s hostname, e.g.
- Add Credentials
Private Key File:Path to a private key file that is authorized for your OpenShift account. In the first post this path was used:
/var/lib/openshift/<UID of your jenkins>/app-root/data/git-ssh/id_rsa. Note:
$OPENSHIFT_DATA_DIR seems not to work here.
BTW: You can change the credentials any time later via this URL
- Prepare slave node: Create same environment as on master in the first post
- Create folder structure
echo -e "<settings><localRepository>$OPENSHIFT_DATA_DIR/.m2</localRepository></settings>" > $OPENSHIFT_DATA_DIR/.m2/settings.xml
- Copy SSH directory from master to same directory on slave, e.g.
scp -rp -i $OPENSHIFT_DATA_DIR/.ssh $OPENSHIFT_DATA_DIR/.ssh <slave's UID>@slave-<your account>.rhcloud.com:app-root/data/.ssh
- As the different cartridges (jenkins and DIY) have different environment variables for their local IP addresses (
$OPENSHIFT_DIY_IP) we’ll have to improvise at this point. There are two options: Either
- Replace all occurrences of
In all builds and in
- Create an
$OPENSHIFT_JENKINS_IP environment variable on your slave machine
rhc env set OPENSHIFT_JENKINS_IP=<value of $OPENSHIFT_DIY_IP> -a slave
You can find out the value of $OPENSHIFT_DIY_IP by SSHing to the slave and execute
- I’d love to hear suggesstions that do better 😉
- Adapt Build
Easiest way is to not use the master at all.
To do so, go to
# of executors to
- Limit memory usage.
Make sure the slave does not run out of memory (which leads to a restart of the node):
Global properties |
- Now run a build. It should run on the slave and hopefully succeed 🙂
See also Libor Krzyzanek’s Blog: Jenkins on Openshift wi… | JBoss Developer
After finishing the migration from Actionbarsherlock to appcompat described in the first Post on modernizing android UIs, it turns out there are even more things to modernize in terms of android UIs.
Tabs and design support library
If you used Tabs within the ActionBar, after migrating to appcompat-v7 API 22 you might recognize a warning, that tells you that they are now deprecated.
In order to modernize those, you should use the design support library that was added to the Android SDK with API level 22. Similar to the appcompat -v7, the design support library provides backports of material design components of Android lollipop (5.x) for older versions of Android.
Here’s the steps that rid you of the deprecation warning
- Add the design library to your eclipse workspace and link it with your project in pretty much the same way as appcompat described in the first Post. The library can be found on the following path: <
Import it into eclipse as
Existing Android Code Into Workspace, change the build target to level 22, and link the appcompat project with it.
The screenshots bellow show a before-after comparison – deprecated tabs vs material design tabs.
Tabs: design support library, API-22
Tabs: AppCompat-v7, API-22, deprecated
Checkboxes to switches
Android API level 14 introduces the switch component, that according to google should be used when only one option is available. For API levels < 14 there’s no such thing as switches. So we’ll have to rely on checkboxes there. Here’s how to replace checkbox preferences by switches for devices running API level 14 and above
- In a preference XML, replace
SwitchPreference (see commit ab16eb1997dfba743abcd488b6b20de71b5c3ff0 for an example).
- However, If you want to keep compatibility with API levels < 14, you’re only choice is to keep redundant copies of the same preferences.xml in
res/xml/ that contains the preferences with
res/xml-v14/ that contains the same file with
Another before-after comparison is shown bellow – checkboxes vs switches.
Preferences: AppCompat-v7, with checkboxes
AppCompat-v7, API-22 with switches
Using Action Buttons
Action Buttons are icons that realize the most important actions on the actionBar if there is enough room to display them. These could have been used in Actionbarsherlock already, but if you still didn’t modernized them then it’s about time 🙂
One reason for not using action buttons might be that you don’t have suitable icons. Here’s the solution: Google provides a huge amount of material design icons under open source (CC-BY) license. They can be found on this site, or you can just clone their git repository.
So it’s as easy as that
And that’s it. See bellow for an example. For an example see the commit that realized this change.
AppCompat-v7, API-22, ActionBar with menu
AppCompat-v7, API-22, ActionBar with action buttons
This post shows by example the steps that are necessary for migrating an android application from Actionbarsherlock to Material Design (introduced in android KitKat/Version 5.x/API level 21/22), while keeping compatibility with at least android Gingerbread/Version 2.3 /API level 9). It uses the appcompat-v7 library on API level 22. The app that was migrated (nusic) in this example is developed using Eclipse, Maven and RoboGuice.
Let’s begin with some before-after screenshots:
Preferences: AppCompat-v7, API-22
Basic migration (appcompat-v7)
The following lists the steps that were implemented in order to change the app as depicted in the screenshots above.
- Update Android SDK Tools
- Setup Eclipse project for appcompat described here.
- Link your project with it. Right click on your project |
- Remove action bar sherlock. Same menu as above.
- Set Up Maven Build
- Migrate from Actionbarsherlock to appcompat
For further info please see