Java 项目的流浪者: 应该在 VM 中编译还是在主机上编译？

这里有一个问题: 当在 Java 项目(或任何编译语言项目)中使用 Vagrant 时，应该在 VM 中编译还是在主机上编译？另外，您希望您的 IDE 和所有开发工具也在 VM 内部运行，还是在主机上运行？

这似乎正是 Java IDE 和编译/部署进程在 Vagrant VM 中的工作方式。一般来说，我的印象是，代码是在主机上编辑的，并在 VM 上运行，这对于非编译语言非常有效。关于 Stackoverflow 的其他答案已经暗示由于额外的编译步骤，Vagrant 对于编译语言没有多大用处，但是我还是想看看能做些什么。

有些事我已经想清楚了:

为什么要在 VM 上编译

  • 如果在主机上编译，Java 就是另一个需要安装的软件
  • 如果在主机上编译，那么主机上的 java 版本必须手动更新到 VM 上
  • 主机上相应的 java 版本可能不可用(比如，在 Mac 上)

为什么在虚拟机上安装 IDE

  • 环境和 IDE 之间更紧密的集成，可以使用快捷方式运行应用程序
  • 可以连接 Java 应用程序的调试器而无需进行远程调试(一步运行/调试)

为什么要在主机上编译

  • 更快的编译时间
  • 希望使虚拟机尽可能接近生产的样子

为什么主机上有 IDE

  • 在主机上编辑代码并在 VM 上运行代码是一种流行的惯例
  • 更好的 UI 性能(X 转发和 VNC 都很慢)

您的想法是什么: 我应该从虚拟机还是主机运行 IDE？我应该从虚拟机还是主机内部编译？

22612 次浏览
小开
最佳答案

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.

小开

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.


提交答案