Projects Filter

VersionEye can monitor your projects on GitHub, Bitbucket or Stash and notify you about out-dated dependencies, license violations and security vulnerabilities. If you have a couple hundred, or even a couple thousand, projects it can be hard to find the desired project on VersionEye. That’s why there is a filter now.

Screen Shot 2015-05-26 at 21.14.15

With that filter you can filter the project list by

  • name
  • language

and you can sort it by

  • number of out-dated dependencies
  • number of license violations
  • name

The filter works via HTTP GET. That means that you can bookmark the search results. That should help you to get along with a big amount of projects :-)

Email templates optimised for mobile

On VersionEye you can follow software libraries and as soon a new version comes out you will receive an email notification. Beside that VersionEye can monitor your project on GitHub/Bitbucket/Stash and notify you about out-dated dependencies in your project. Some people complaint that the email isn’t optimised for mobile and that some emails are not readable on mobile. Now the email templates just got an update. Now there are optimised for mobile and look similar to that one.


Your feedback is welcome ;-)

PHP Security Vulnerabilities

Now VersionEye has notifications for security vulnerabilities! This new feature currently only works for PHP. Right now we have 118 security vulnerabilities in our database which affects some of the most used PHP frameworks and libraries. The security vulnerabilities are fetched from the SensioLabs security database. VersionEye is displaying the security vulnerabilities directly on the VersionEye detail pages. Here is an example.

Screen Shot 2015-05-07 at 14.08.05

VersionEye is displaying at least 1 link to an article where the security vulnerability is documented in great detail. Beside that the affected versions are displayed as well.

But that’s not all. If VersionEye is monitoring your PHP project directly on GitHub/Bitbucket or Stash, you will see a “Security” tab in your project view. Here is an example.

Screen Shot 2015-05-13 at 15.28.22

In the “Security” tab we display known vulnerabilities for your project. If there are any security vulnerabilities for your project the dependency badge turns red to “update!”.

This feature is strongly based on locked versions. If VersionEye has access to your composer.lock file it knows exactly which version you are using in production and it can assign security vulnerabilities 100% accurate. If VersionEye has only access to your composer.json file, but not to your composer.lock file it doesn’t know which versions exactly you are using in production. In that case VersionEye assumes that all version expressions are resolved to the newest version. But because we don’t know it for sure, it doesn’t affect the dependency badge. For composer.json files we display that hint in the security tab.

Screen Shot 2015-05-13 at 15.35.58

If you want to take full advantage of this feature you should commit your composer.lock file to your git repository and give VersionEye access to it. That is anyway best practice.

This feature is very new and we heavily rely on your feedback. Please try it out and let us know if you find anything odd.

Improvement for License Whitelist Auditlogs

At VersionEye you can easily create a license whitelist which will be checked continuously against your open source dependencies and if there is a violation you will receive an email notification.

Every action on the whitelist is tracked in the Auditlogs. Every time somebody adds or removes a license it creates an Entry in the Auditlogs. Until now the entry on the Auditlog displayed the full license name and the license list itself displayed the SPDX identifier. That was a little bit confusing because it was not a 100% match and difficult to manually reproduce the whitelist.


Now this is fixed in the current version. VersionEye is using the SPDX identifier in the Auditlogs as well. Now it looks like this.


Now the Auditlogs for the whitelist is much easier to understand.

Setting up a dev. environment with Vagrant

Maybe you know that situation. You work in a company with a big software development department and you have high fluctuation. Every couple weeks a new intern is starting. Every couple months a new employee or freelancer is starting and you always have the problem of on boarding. They all need a development environment to get started. And in the best case all dev. environments should be identical. You want to ensure that everybody is working with the exact same version of MongoDB, Java, Ruby, PHP, Eclipse, NetBeans and whatever.

In some companies this on boarding and the whole process of setting up a new development environment takes 5 days. A whole week, until somebody can start to become productive. With Vagrant that whole ramp up time can be cut down to less than 1 hour!

In the previous blog post I described how to get started with Vagrant quickly. This blog post will describe how to use Vagrant to setup a whole development environment.

Ubuntu with XFCE4

Let’s start with the “ubuntu/trusty64” Vagrant box, which is a basic Ubuntu 14.04 LTS image. By default the GUI for a Vagrant box is disabled and the “ubuntu/trusty64” box has anyway no XServer installed. If your developers are writing C code with Vim that is all you need. Otherwise you should install an XServer and some additional graphical development tools, like a proper IDE and a Browser. I prefer XFCE4 as XServer because it is very lightweight and doesn’t require much resources. First of all we need to enable GUI in Vagrant and we should setup the RAM memory to 8 GB.

Vagrant.configure(2) do |config| = “ubuntu/trusty64”

  config.vm.provider “virtualbox” do |vb|
    vb.gui = true
    vb.memory = “8192”

Now in the provision section we need to install XFCE4 and the VirtualBox guest utilities to enable a smooth integration into our host system.

sudo apt-get install -y xfce4 virtualbox-guest-dkms virtualbox-guest-utils virtualbox-guest-x11

That will start XFCE4 without any icons. And because buttons without icons are not very user friendly we need some themes and icons from the Gnome project.

sudo apt-get install gnome-icon-theme-full tango-icon-theme

To be able to start XFCE4 as non privileged user we need this additional line.

sudo echo “allowed_users=anybody” > /etc/X11/Xwrapper.config

Ensure encoding

Weird thinks can happen if developers are using different encodings. That’s usually causing issues like “It works on my machine” :-) That’s why let’s ensure encoding!

sudo echo “LANG=en_US.UTF-8” >> /etc/environment
sudo echo “LANGUAGE=en_US.UTF-8” >> /etc/environment
sudo echo “LC_ALL=en_US.UTF-8” >> /etc/environment
sudo echo “LC_CTYPE=en_US.UTF-8” >> /etc/environment

Install Java 8

This code snippet will install the JDK 8 from Oracle. It will automatically accept the terms without asking you.

sudo add-apt-repository -y ppa:webupd8team/java
sudo apt-get update
sudo apt-get -y upgrade
echo debconf shared/accepted-oracle-license-v1-1 select true | sudo debconf-set-selections
echo debconf shared/accepted-oracle-license-v1-1 seen true | sudo debconf-set-selections
sudo apt-get -y install oracle-java8-installer

Install Eclipse

If you work with Java you probably want to install Eclipse. It is still the most used Java IDE on earth.

sudo wget -O /opt/eclipse-java-luna-SR2-linux-gtk-x86_64.tar.gz
cd /opt/ && sudo tar -zxvf eclipse-java-luna-SR2-linux-gtk-x86_64.tar.gz


The complete Vagrantfile can be found in this gist.

Start Up

Usually the Vagrantfile is stored in VCS, for example in a git repository. New employees simply need to check out the Vagrantfile and run

vagrant up

Depending on the network, CPU and RAM this can take a couple minutes. On my MacBook Pro it took 15 minutes. After the setup is done we can login with

vagrant ssh

And now we can start the XServer with


That will bring up the XFCE4 Desktop like here.

Screen Shot 2015-05-05 at 11.42.20

Instead of 5 days this takes less than 1 hour to provide new employees a standardised development environment.

This was just a very simple example, but I think the idea behind Vagrant is clear. It’s a great way to standardise development environments and to cut down on boarding time to minutes.

Let me know what you think. Either here in the comments or on Twitter.

Vagrant Up

Vagrant is a pretty cool project which enables you to describe / provision a complete virtual machine instance in a single text file. The Vagrantfile. The basic idea behind Vagrant is that the whole VM is described in a Vagrantfile. Instead of giving somebody a whole VM with several giga bytes you simply share the Vagrantfile. By executing

vagrant up

in the directory where the Vagrantfile is placed, will setup the VM like described in the Vagrantfile. Executing “vagrant up” the very first time can take a couple minutes. Later on the command will simply start the VM. The advantages are clear.

  • A Vagrantfile can be easily committed to a git repository which enables version control.
  • Sharing a Vagrantfile is much easier than sharing a several giga byte image.
  • Updating a VM means updating text in a Vagrantfile.
  • The provisioning of a VM is reproducible.


VM Providers

Vagrant is supporting multiple virtualisation technologies. For example VirtualBox, VMWare, EC2 and many more. By default Vagrant is using VirtualBox because it’s for free. Please make sure that VirtualBox is installed before you start using Vagrant.

Vagrant box

A Vagrant box is a preconfigured VM instance which can be used by Vagrant. In the Vagrantfile there is always a reference to a Vagrant box. is a hub for Vagrant boxes.


The Vagrantfile has a reference to a Vagrant box and describes how to provision the VM instance. This here is a very simple example of a Vagrantfile.

Vagrant.configure(2) do |config| = “ubuntu/trusty64”

This Vagrantfile is referencing the “ubuntu/trusty64” Vagrant box, which is a minim. installation of Ubuntu 14.04 LTS.

The Vagrantfile can also contain information about Networking, RAM, UI and a bootstrap script which will be executed by running vagrant up the very first time for a Vagrantfile.

Vagrant SSH

After running

vagrant up

the VM can be accessed with

vagrant ssh

This will you directly login into the VM without any password. It’s that easy to get started with Vagrant.


Until now we just started a simple Ubuntu virtual machine. Now we come to the interesting part. The provisioning. In the Vagrantfile we can describe what else should be installed and executed on vagrant up. Assume we want to install MariaDB Server 5.5 on the VM. That’s how it would look like.

Vagrant.configure(2) do |config| = “ubuntu/trusty64”

  config.vm.provision “shell”, inline: <> /etc/environment
    sudo echo “LANGUAGE=en_US.UTF-8” >> /etc/environment
    sudo echo “LC_ALL=en_US.UTF-8” >> /etc/environment
    sudo echo “LC_CTYPE=en_US.UTF-8” >> /etc/environment

    sudo export DEBIAN_FRONTEND=noninteractive
    sudo debconf-set-selections <<< ‘mariadb-server-5.5 mysql-server/root_password  password rootpass’
    sudo debconf-set-selections <<< ‘mariadb-server-5.5 mysql-server/root_password_again password rootpass’
    sudo apt-get install -y mariadb-server


running vagrant up the first time will execute the provision part and install MariaDB Server 5.5. Beside that it will set the encoding to en_US.UTF-8.


Assume you want to ensure that everybody on your team is working with the same version of MariaDB Server and with the same encoding. In that case you can simply setup a Vagrantfile for that which exactly describes the version and encoding of MariaDB. That way everybody is using the exact same backend. Beside that the Vagrantfile can be part of the regular source code and checked in into VCS (git | svn). Upgrading MariaDB or changing the encoding can be simply done by updating the Vagrantfile. The changes can be committed back to VCS and the team members only have to run

vagrant destroy
vagrant up

to update their environment.

Vagrant is a great way to ensure that everybody is using the exact same software.

Here is another article how to setup a complete dev. environment with Vagrant.

Biicode Integration

Biicode is a new programming environment for C and C++ developers. It is a package manager and dependency manager for C/C++ which works on ALL platforms. Biicode is the Maven for C/C++.


It is a young project, but absolute necessary. Finally there is a common way to manage C/C++ dependencies. And that’s why VersionEye supports Biicode. VersionEye is crawling the whole biicode repository once an hour. ALL biicode packages are available on VersionEye as well. Every biicode package has a page at VersionEye, where you can see the most important KPIs and all dependencies.


You can follow any biicode package and VersionEye will notify you about new versions via email. But that’s not all. With biicode you describe your C or C++ dependencies in an biicode.conf file. VersionEye can monitor your biicode.conf file directly on GitHub or Bitbucket and notify you about Updates for your open source dependencies.


VersionEye makes your dependencies visible and keeps you informed.

Screen Shot 2015-04-27 at 16.28.03

Try out the new Biicode integration and let us know what you think, either here in the comments or on Twitter.