View Christos Tranoris's profile on LinkedIn

Visit The Model Driven Software Network

Who's online

There are currently 0 users and 0 guests online.

Recent comments


Syndicate content

Using Vagrant with Eclipse on Developing/Testing/Building applications targeting different OSs

If you are a developing applications on your favorite OS and toolchain targeting other OS then virtualization is your friend. Vagrant (  is a free and open-source software for creating and configuring virtual development environments. What is particularly useful with Vagrant is that you describe your environment in a Ruby like text file , together with some orchestration commands which you can maintain together with your source code in our SCM tool.

Thus, Vagrant helps developers share reproducible development environments. It can be also combined with Docker (, making Integration tests a toy, while simultaneously can help you develop your application exactly as it will run on the production environment, or even deploy it with that same Docker container. Since Docker is another new exciting virtualization technology we can explore it further in a future note. Here I will share how I use Vagrant for my development needs.
Lately I develop Java web apps and APIs on my Eclipse Windows 7 installation. The thing here is that my apps are interacting with the underlying OS, that is Linux, thus making developing and testing  on the target OS really painful. In such scenarios Vagrant combined with a virtualization technology like VirtualBox can really drastically decrease your development/testing/deploy cycle. To summarize  here is what you can do:
    - Write code on your OS and tool
    - Instrument Vagrant to prepare your target environment
    - Configure Vagrant to share your workspace folder between your Host OS and Target OS
    - Use the VM to compile, build, test, deploy your application
In an Eclipse project you can just maintain a Vagrantfile together with any bootstrap of your VM environment within your source code. Like the image shows:

Having this portable format, another developer will very easily recreate your target environment and start using your developing environment.

Some key configuration in a Vagrantfile is the following:


 # Every Vagrant virtual environment requires a box to build off of. The base VM image. You get from ready VM images = "astral1/saucy64"
  config.vm.provision :shell, path: ""
  # Create a forwarded port mapping which allows access to a specific port
  # within the machine from a port on the host machine. :forwarded_port, guest: 80, host: 80, auto_correct:true :forwarded_port, guest: 443, host: 443, auto_correct:true :forwarded_port, guest: 8443, host: 8443, auto_correct:true :forwarded_port, guest: 8080, host: 8080, auto_correct:true

# memory and CPUs
  config.vm.provider "virtualbox" do |v|
    v.customize ["modifyvm", :id, "--memory", "4096", "--cpus", "4"]

 # Share an additional folder to the guest VM.  Here I share both my project folder, but also the whole Eclipse workspace
  config.vm.synced_folder "./", "/home/vagrant/myproject", disabled: true
  config.vm.synced_folder "C:/Users/ctranoris/myeclipseworkspace", "/home/vagrant/ws"

Here is an example of my boostrap file. (It executes only the first time that the VM is created, not every reboot time)

#!/usr/bin/env bash

set -ex

# Adding an apt gpg key is idempotent.
wget -q -O - https :// | apt-key add -
# Creating the docker.list file is idempotent, but it may overwrite desired
# settings if it already exists. This could be solved with md5sum but it
# doesn't seem worth it.
echo 'deb http :// docker main' >> /etc/apt/sources.list

apt-get update

apt-get -y --force-yes install \
openjdk-7-jdk \
git \
lxc-docker \
maven \

usermod -a -G docker "vagrant"

echo "Done installing, putting in place bootstrap content.."

As you see in my example just to get an idea, I install, openjdk, git, maven, subversion and docker.
The following image displays how the development environment looks in the end

Since I use maven for my Java applications, I execute all the maven commands directly to the guest Linux VM. Since folders are shared the result is the same as you work on the same machine




Posted in Submitted by tranoris on August 9, 2014 - 16:44.

Anonymous | November 10, 2014 - 13:56

Hi, thanks for the great article!

I'm planning to test similar setup for scala/play development. I was wondering why do you need to whole workspace mapped to the virtual machine?