Vagrant pour un projet Java: devriez-vous compiler dans la VM ou sur l'hôte?

Question

Voici la question: Lors de l'utilisation de Vagrant pour un projet en Java (ou de tout langage compilé projet), vous devez le compiler dans la machine virtuelle ou sur l'hôte? Aussi, souhaitez-vous que votre IDE et tous vos outils de développement pour être exécuté à partir de l'intérieur de la VM, ou sur l'hôte?

Il semble être pas très bien défini exactement comment un IDE Java et de le compiler et déployer des processus de travail avec un Vagabond VM. Généralement, mon impression est que le code est modifié sur l'hôte, et de l'exécuter sur la machine virtuelle, qui fonctionne très bien pour les non-langages compilés. D'autres réponses sur Stackoverflow est implicite que l'Errance est moins utile pour les langages compilés en raison de l'extra étape de compilation, mais j'ai encore envie de voir ce qui peut être fait.

Certaines choses que j'ai pensé déjà:

Pourquoi compiler sur la VM

• si la compilation de l'hôte, java est un plus de morceau de logiciel à installer
• si la compilation de l'hôte, la version de java sur l'ordinateur hôte doit être manuellement mis à jour avec que sur la VM
• le correspondant de la version de java sur l'ordinateur hôte est peut-être indisponible (par exemple, sur un Mac)

Pourquoi avez-IDE sur la VM

• une intégration plus étroite entre l'environnement et de l'IDE, pouvez utiliser des raccourcis pour exécuter l'application
• peut se connecter débogueur pour les applications java sans débogage à distance (une étape run/debug)

Pourquoi compiler sur l'ordinateur hôte

• plus rapide temps de compilation
• voulez garder la machine virtuelle en tant que proche de ce qu'est la production dirait que possible

Pourquoi avez-IDE sur l'ordinateur hôte

• c'est le vagabond de la convention d'éditer le code sur l'ordinateur hôte et l'exécuter sur la machine virtuelle
• meilleure INTERFACE de performance (X forwarding et VNC est lent)

Quelles sont vos pensées: dois-je exécuter mon IDE de l'intérieur de la machine virtuelle ou l'hôte? Dois-je compiler à partir de l'intérieur de la VM ou de l'hôte?

Answer 1

Après beaucoup de réflexion et d'expérimentation, j'ai décidé d'utilisation de Vagrant et comment il s'intègre avec le développement de Java.

Pour JavaEE / applications déployées, la configuration d'un serveur web et un serveur de base de données sont certainement des choses qui ont "assez" complexité pour justifier l'utilisation de Vagrant. Avec deux serveurs et les nombreuses façons de les configurer, il est facile pour la configuration de sortir de la synchronisation à partir d'un développeur à l'autre, portant sur la "fonctionne sur ma machine" syndrome. Pour ce genre de logiciel, il serait préférable de modifier et compiler le code de l'hôte, et de déployer d'un Vagabond VM qui imite votre environnement de production. Le dossier de déploiement du serveur web pourrait même être liés à une cible de compilation sur l'hôte, en supprimant la nécessité de redéployer manuellement. De manière Erratique pourrait être une partie importante de votre cycle de développement, mais le temps de cycle pour le code/compilation/déploiement à partir de l'hôte et de l'exécuter sur la machine virtuelle de Java devrait être plus long que le temps de cycle pour le code sur l'ordinateur hôte et l'exécuter sur la machine virtuelle que nous voyons avec PHP/Ruby/Node/etc.

Autonome, pour les applications Java (comme les bibliothèques ou les applications de bureau) l'histoire change un peu. Dans ce cas, il est plus logique de modifier, compiler et exécuter sur la machine hôte, renonçant à l'utilisation de Vagrant tout à fait. Si vous utilisez l'un des grands Java IDE (Eclipse, Netbeans, IntelliJ...), vous avez déjà installé Java sur la machine. À ce point, il y a très peu d'avantages par rapport à la surcharge de l'utilisation de Vagrant, et ne sert qu'à mettre une couche supplémentaire de complexité dans le processus de développement. C'est parce que par le temps que vous êtes en mesure de modifier Java avec l'IDE, vous êtes en mesure d'exécuter tout sur l'hôte de toute façon. Un problème est que la version de Java requis pour le projet peut ne pas correspondre à la version de l'exécution de l'IDE sur l'ordinateur hôte. En général (je l'espère), ce n'est pas trop un problème; de cette écriture JDK6 est en fin de lifed et JDK8 n'est pas encore sorti (devinez d'où que nous laisse). Mais si vous avez besoin d'exécuter plusieurs versions, vous devriez être en mesure de définir JAVA_HOME sur l'hôte en tant que de besoin. Si ce n'introduire davantage de complexité, il est de moins en moins de complexité que le maintien d'un Vagabond runtime juste pour travailler avec des projets à l'aide de différentes versions de Java.

La question intéressante est de savoir quoi faire avec containerless applications web. Si le serveur web (dans ce cas interne de l'application) être exécuté à l'intérieur de la VM comme nous l'avons fait pour le serveur web externe? Ou de s'exécuter sur l'hôte comme nous l'avons fait pour l'application autonome? Pour containerless applications web, il n'y a pas de serveur web externe à s'inquiéter, mais il est encore susceptible d'une base de données. Dans cette situation, on peut adopter une approche hybride. L'exécution d'un containerless web app est essentiellement la même que l'exécution d'une application autonome, de sorte qu'il serait efficace de compiler et d'exécuter le code sur la machine hôte. Mais avec une base de données impliqués il ya encore assez de complexité de la configuration et de là qu'il est logique d'avoir le serveur de base de données dans son propre Errance des VM.

Espérons que cela donne des développeurs Java qui sont intéressés par Vagabond en contexte pour savoir comment l'utiliser.