Vagrant for a Java project: should you compile in the VM or on the host?

Question

Here’s the question: When using Vagrant for a Java project (or any compiled language project for that matter), should you compile in the VM or on the host? Also, would you want

Answer 1

After much thought and experimentation, I've decided on where to use Vagrant and how it integrates with the Java development workflow.

For JavaEE / deployed applications, configuring a web server and a database server are definitely things that have "enough" complexity to warrant the use of Vagrant. With two servers and the myriad ways to configure them, it's easy for configuration to get out of sync from one developer to another, bringing about the "works on my machine" syndrome. For this kind of software, it would work best to edit and compile the code on the host, and deploy to a Vagrant VM that mimics your production environment. The deployment folder for the web server could even be symlinked to a compile target on the host, removing the need to manually redeploy. So Vagrant could be an important part of your development lifecycle, but the cycle time for code/compile/deploy from the host and run on the VM with Java would be longer than the cycle time for code on the host and run on the VM that we see with PHP/Ruby/Node/etc.

For standalone Java applications (like libraries or desktop applications) the story changes a bit. In this case it makes the most sense to edit, compile, and run on the host machine, eschewing the use of Vagrant altogether. If you're using one of the big Java IDE's (Eclipse, Netbeans, IntelliJ...), you already have Java installed on the machine. At that point there is very little advantage compared to the overhead of using Vagrant, and only serves to put an extra layer of complexity in your development process. This is because by the time you are able to edit Java with an IDE you are able to run everything on the host anyway. One issue is that the version of Java required for the project may not match the version running the IDE on the host. In general (hopefully) this is not too much of a problem; as of this writing JDK6 is end-of-lifed and JDK8 is not yet released (guess where that leaves us). But if you did need to run multiple versions, you should be able to set JAVA_HOME on the host as needed. Though this does introduce extra complexity, it is less complexity than maintaining a Vagrant runtime just to work with projects using different versions of Java.

The interesting question is what to do with containerless web applications. Should the web server (in this case internal to the application) be run inside the VM as we did for the external web server? Or run on the host as we did for the standalone application? For containerless web applications, there is no external web server to worry about, but there is still likely a database. In this situation we can take a hybrid approach. Running a containerless web app is essentially the same as running a standalone application, so it would be effective to compile and run your code on the host machine. But with a database involved there is still enough complexity and configuration there that it makes sense to have the database server be on its own Vagrant VM.

Hopefully this gives Java developers who are interested in Vagrant some context about how to use it.

Answer 2

I was interested to this topic during the last year :)

My solution is to have a vagrant machine configurable with flags. For example one of this flag enable the desktop gui because some developer prefer to code on the host machine while others prefer to have a much more integrated environment with the desktop and the IDE in it.

To face the desktop slowness you should install a very useful vagrant plugin (yeah... vagrant has plugins that greatly improve the development environment) in this way: vagrant plugin install vagrant-vbguest This plugin will install virtual box guest addition on every guest to make it usable while using the virtualbox interface. Then to enable the gui edit the Vagrantfile in this way:

config.vm.provider "virtualbox" do |vb| vb.gui = true end

Instead to speed-up the shared folder performances I suggest to use rsync: config.vm.synced_folder "./git", "/home/vagrant/git", type: "rsync", rsync__exclude: ".git/" In this way the source code is edited on the host and then rsync-ed to the guest.