Vagrant para um projeto Java: você deve compilar na VM ou no host?

Aqui está a pergunta: ao usar o Vagrant para um projeto Java (ou qualquer projeto de linguagem compilada), você deve compilar na VM ou no host? Além disso, você gostaria que seu IDE e todas as suas ferramentas de desenvolvimento fossem executados de dentro da VM também ou no host?

Parece não estar muito bem definido exatamente como um IDE Java e o processo de compilação / implantação funcionam com uma VM Vagrant. Geralmente, minha impressão é que o código é editado no host e executado na VM, o que funciona muito bem para linguagens não compiladas. Outras respostas no Stackoverflow implicaram que o Vagrant é menos útil para linguagens compiladas por causa da etapa extra de compilação, mas ainda quero ver o que pode ser feito.

Algumas coisas já pensei:

Por que compilar na VM

• se estiver compilando no host, o java é mais um software a ser instalado
• se estiver compilando no host, a versão do java no host deve ser mantida manualmente atualizada com a da VM
• a versão java correspondente no host pode estar indisponível (digamos, em um Mac)

Por que ter IDE na VM

• integração mais estreita entre o ambiente e IDE, pode usar atalhos para executar o aplicativo
• pode conectar o depurador para aplicativos java sem depuração remota (uma etapa de execução / depuração)

Por que compilar no host

• tempos de compilação mais rápidos
• deseja manter a VM o mais próximo possível da aparência de produção

Por que ter IDE no host

• é a convenção do vagrant editar o código no host e executá-lo na VM
• melhor desempenho da IU (encaminhamento X e VNC são lentos)

O que você acha: devo executar meu IDE de dentro da VM ou do host? Devo compilar de dentro da VM ou do host?

Depois de muito pensar e experimentar, decidi onde usar o Vagrant e como ele se integra ao fluxo de trabalho de desenvolvimento Java.

Para aplicativos JavaEE / implantados, configurar um servidor web e um servidor de banco de dados são definitivamente coisas que têm complexidade "suficiente" para garantir o uso do Vagrant. Com dois servidores e as inúmeras maneiras de configurá-los, é fácil para a configuração sair de sincronia de um desenvolvedor para outro, causando a síndrome "funciona na minha máquina". Para esse tipo de software, funcionaria melhor editar e compilar o código no host e implantar em uma VM Vagrant que imita seu ambiente de produção. A pasta de implantação para o servidor web pode até mesmo ser ligada simbolicamente a um destino de compilação no host, eliminando a necessidade de reimplantar manualmente. Portanto, o Vagrant pode ser uma parte importante do seu ciclo de vida de desenvolvimento,

Para aplicativos Java autônomos (como bibliotecas ou aplicativos de desktop), a história muda um pouco. Nesse caso, faz mais sentido editar, compilar e executar na máquina host, evitando o uso do Vagrant por completo. Se você estiver usando um dos grandes IDE do Java (Eclipse, Netbeans, IntelliJ ...), você já tem o Java instalado na máquina. Nesse ponto, há muito pouca vantagem em comparação com a sobrecarga de usar o Vagrant e só serve para colocar uma camada extra de complexidade em seu processo de desenvolvimento. Isso ocorre porque, no momento em que você é capaz de editar Java com um IDE, você é capaz de executar tudo no host de qualquer maneira. Um problema é que a versão do Java necessária para o projeto pode não corresponder à versão que executa o IDE no host. Em geral (espero), isso não é um grande problema; no momento em que este livro foi escrito, o JDK6 chegou ao fim da vida e o JDK8 ainda não foi lançado (adivinhe onde isso nos deixa). Mas se você precisar executar várias versões, deverá ser capaz de definir JAVA_HOME no host conforme necessário. Embora isso apresente complexidade extra, é menos complexo do que manter um runtime Vagrant apenas para trabalhar com projetos que usam versões diferentes do Java.

A questão interessante é o que fazer com os aplicativos da web sem contêiner. O servidor web (neste caso interno ao aplicativo) deve ser executado dentro da VM como fizemos para o servidor web externo? Ou executar no host como fizemos para o aplicativo independente? Para aplicativos da web sem contêiner, não há um servidor web externo com o qual se preocupar, mas provavelmente ainda haverá um banco de dados. Nessa situação, podemos adotar uma abordagem híbrida. Executar um aplicativo da web sem contêiner é essencialmente o mesmo que executar um aplicativo autônomo, portanto, seria eficaz compilar e executar seu código na máquina host. Mas, com um banco de dados envolvido, ainda há complexidade e configuração suficientes para que faça sentido ter o servidor de banco de dados em sua própria VM Vagrant.

Espero que isso dê aos desenvolvedores Java que estão interessados ​​no Vagrant algum contexto sobre como usá-lo.

Fiquei interessado neste tópico durante o ano passado :)

Minha solução é ter uma máquina vagrant configurável com sinalizadores. Por exemplo, um deste sinalizador habilita a interface do desktop porque alguns desenvolvedores preferem codificar na máquina host, enquanto outros preferem ter um ambiente muito mais integrado com o desktop e o IDE nele.

Para enfrentar a lentidão da área de trabalho, você deve instalar um plugin vagrant muito útil (sim ... o vagrant tem plugins que melhoram muito o ambiente de desenvolvimento) desta forma: plugin vagrant install vagrant-vbguest Este plugin irá instalar a adição de convidado virtual box em cada convidado para torná-lo utilizável ao usar a interface do virtualbox. Então, para habilitar a interface do usuário, edite o Vagrantfile desta forma:

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

Em vez de acelerar o desempenho da pasta compartilhada, sugiro usar rsync: config.vm.synced_folder "./git", "/ home / vagrant / git", digite: "rsync", rsync__exclude: ".git /" Neste forma como o código-fonte é editado no host e, em seguida, rsync-ed para o convidado.