Pourquoi avons-nous besoin de Maven ou de Ant, si nous avons déjà Eclipse?

1. Parce que votre collègue pourrait préférer NetBeans ou IDEA
2. Parce que les parameters peuvent varier d’une installation éclipse à une autre
3. Parce que vous pourriez vouloir obtenir vos dépendances automatiquement
4. Parce que vous voulez automatiser l’intégralité de la construction: créer, parsingr, appliquer une parsing de code statique, exécuter les tests unitaires, générer la documentation, copier dans un répertoire, ajuster certaines propriétés en fonction de l’environnement, etc.
5. Parce qu’une fois automatisé, vous pouvez utiliser un système d’continuous integration qui construit l’application à chaque changement ou à chaque heure pour vous assurer que tout fonctionne encore et que les tests réussissent encore …
6. Parce que Maven utilise la convention sur la configuration.
7. Parce que votre EDI peut ne pas prendre en charge la génération / transformation de code sophistiquée dont vous avez besoin.
8. Parce qu’un script de génération documente le processus de génération.

Eclipse est un environnement de développement. Mais ce n’est pas un outil de construction.

Je déteste personnellement Maven, mais YMMV. Il existe de nombreuses alternatives: gradle, buildr, etc.

Maven me semble être un cas écrit par un groupe de kiddies de script c-shell passés, qui pensent que autoconf est à la pointe de l’automatisation du code et ne comprend pas que le code object nécessite un environnement d’object tout moyen efficace pour le développement ou le déploiement. Ant était assez mauvais, mais Maven combine toutes les pires caractéristiques de Ant et Ivy. Il ne crée pas un environnement d’object et ne fonctionne pas bien avec les outils qui le font.

Simplement, un environnement d’object doit avoir tous les objects de classe, c’est-à-dire les objects qui déterminent les types d’objects disponibles pour le système, en direct et disponibles à tout moment. À partir de là, je peux faire ce que je veux, instancier plusieurs objects d’une classe, configurer différentes séquences et règles d’instanciation, etc. Comme l’environnement doit être complètement actif, je ne devrais pas du tout avoir besoin d’ un outil de construction. En termes de déploiement de mon application, il n’est pas difficile pour l’environnement de simplement lancer tous les objects de classe qui ne sont jamais référencés par le code dans les espaces de noms qui composent mon application. Le ramasse-miettes dans la JVM fait presque la même chose à la volée aujourd’hui. A ce stade, j’ai un environnement de déploiement composé de mes objects et de tous les objects (principalement des objects de classe) auxquels mes objects font référence, à savoir mon application et toutes les dépendances. Voici comment fonctionnent les machines virtuelles. (Le fait que nos machines virtuelles soient si mal écrites que nous devons exécuter une machine virtuelle Spring sur une machine virtuelle Java sur une machine virtuelle Linux sur une machine virtuelle VMWare sur une autre machine virtuelle Linux est un autre exemple d’idiotisation du développement logiciel). Lorsque les dépendances sont mises à jour, il est assez simple pour l’environnement d’inviter le développeur à fusionner son ancien code avec les nouvelles bibliothèques, à fusionner le code en utilisant les nouvelles libs à l’ancienne version ou à conserver les deux versions. L’invitation encourage le développeur à apporter les légères modifications parfois nécessaires pour éviter d’avoir vingt versions de chaque bibliothèque, tandis que des outils tels que Maven masquent le fait que vous ayez vingt versions et que les applications Java subissent un flot d’exécution massif.

Dans l’espace de développement Java, Eclipse se rapproche le plus d’un environnement d’object approprié, bien qu’il y ait beaucoup de plugins qui brisent le paradigme de différentes manières. La plupart des raisons invoquées pour utiliser Maven s’effondrent lors d’un examen critique.

Netbeans et Idea sont des éditeurs de texte exagérés, pas des environnements d’objects, mais si vous souhaitez utiliser leurs outils pour des éléments non couverts par les milliers de plugins Eclipse, tous deux peuvent importer et gérer des projets Eclipse. en utilisant Eclipse, mais alors, ils seraient si lents s’ils étaient des projets de Netbeans ou d’Idea de toute façon.

Pas une raison sérieuse d’utiliser Maven.

La facilité d’exportation / importation des parameters dans Eclipse (ce que chaque équipe devrait faire dans tous les IDE) rend les problèmes de paramétrages différents de la paresse de l’équipe de développement (ou d’un argument religieux sur les espaces et les tabulations, lol) .

Encore une fois, ce n’est pas une raison sérieuse d’utiliser Maven.

Environnement d’équipe? Montrez-moi une équipe qui n’utilise pas déjà un référentiel comme GIT ou SVN. Pourquoi devons-nous dupliquer les fonctionnalités et les problèmes de maintenance en configurant également les référentiels Nexus?

C’est en fait une bonne raison de ne pas utiliser Maven.

Lancer un build de serveur? Une bonne idée, maintenant, ne devrait-il pas être déclenché par un code qui est effectivement archivé dans le repo source plutôt que par un build aléatoire qui arrive à être poussé vers Nexus? Cela soulève un point contre Git, en particulier Git avec Maven. Puisque dans Git je ne travaille pas sur une twig, teste localement, puis valide (en partie parce que mon test local ne prouve pas que la construction du serveur fonctionne en raison des différences dans la configuration de Maven dans Jenkins et Eclipse) une twig différente afin de voir que la construction du serveur Maven échoue, puis commettre une autre modification pour résoudre le problème, ce qui entraîne un historique de la source illisible dans le repository. Le code à vérifier doit au moins créer et passer des tests unitaires, qui, si Git et Maven étaient exclus, devraient être garantis.

Exporter une compilation sans tête à partir d’Eclipse est sortingvial si vous l’examinez – tout ce dont vous avez besoin est ant ou Gradle, la version de développement déjà maintenue par Eclipse, et quelques jar d’Eclipse (Eclipse exportera tous les fichiers nécessaires répertoire ou fichier zip, ou leur ftp au serveur de construction). Les outils de construction de serveur tels que Hudson / Jenkins peuvent extraire du code mis à jour de la plupart des repos sources et appeler n’importe quel script de construction, il n’y a pas de dépendance sur Maven. Avec Maven, vous forcez les développeurs à utiliser un outil qui ne convient à personne, mais créez des ingénieurs (il faut plus de temps pour construire, même en utilisant M2E, pour créer ce cas), ou vous avez la possibilité que le serveur ne fonctionne pas tout à fait comme la construction de la station de travail, ce qui est toujours le cas si vous passez par toutes les tâches d’intégration des deux en utilisant la pléthore de plug-ins M2E. Dans un cas comme dans l’autre, vous obtenez une construction de poste de travail plus lente et plus fragile, dans un souci de création de serveur tout aussi lente et plus fragile. Sur tous les projets basés sur Maven sur lesquels j’ai travaillé, j’ai vu des erreurs transitoires de Hudson / Jenkins qui n’apparaissaient pas dans Eclipse à moins que vous ayez absolument tous les plug-ins M2E installés et correctement configurés, et la plupart des développeurs ne le font jamais.

Semble une autre bonne raison d’éviter Maven.

Cela ne couvre pas certains des problèmes les plus fondamentaux avec Maven, tels que ses espaces de noms qui brisent les espaces de noms Java et les espaces de noms XML, son unité de génération (le POM) n’ayant aucun lien avec l’environnement de déploiement Par POM, qu’est-ce que vous accomplissez réellement dans le produit fini? Rien. Tout ce qu’il accomplit est un faux sentiment que vous avez séparé les préoccupations et les fonctionnalités en différentes unités de construction qui fonctionnent toutes comme un morceau de code monolithique); le problème de la gestion manuelle des fichiers de configuration complexes, qui ne fait qu’empirer si vous devez utiliser OSGi ou un autre conteneur et gérer d’autres fichiers de configuration qui affectent et sont affectés par la configuration Maven avec un sens évident; les problèmes causés par la tentative d’exécution de tests unitaires sans environnement complet pour que le code s’exécute; la myriade de versions non seulement des dépendances mais aussi des plugins spécifiques à Maven (j’ai déjà vu JAR en enfer dans la version de Maven où plusieurs plugins Maven utilisaient des dépendances conflictuelles – un des problèmes que Maven était censé résoudre .

Oui, vous pouvez créer du code object avec Maven. Vous pouvez également écrire du code object pur en C ou même en assembleur, mais je ne sais pas pourquoi.

La meilleure raison d’éviter Maven est la quantité phénoménale de travail nécessaire pour désamorcer un ensemble de projets lorsque vous en avez assez de tous les problèmes mentionnés ci-dessus (et de nombreux autres non mentionnés).

La mentalité, héritée du développement C, selon laquelle le cycle de développement consiste en un code d’écriture, de compilation, d’assemblage, de construction, de déploiement, de test, de reprise, est désespérément obsolète dans un environnement d’objects. À un moment donné, nous devons dire à tous les gens avec cet état d’esprit qu’ils doivent réapprendre à développer, périodiquement. Cela permettrait de ne plus avoir besoin de Maven, de Git et d’autres outils qui ne feraient que perdre du temps.

Le développement d’object doit être effectué dans un environnement d’object en direct, où un changement de code est testé au fur et à mesure de sa sauvegarde car l’object modifié est actif. Le déploiement doit consister à supprimer les artefacts de développement uniquement de cet environnement, en créant un environnement d’exécution doté de toutes les fonctionnalités utilisées par l’application en cours de développement et de test.

Je suis actuellement confronté à un problème lié à la création d’assemblys de déploiement pour une application OSGi à l’aide du plug-in maven-assembly. L’application fonctionne parfaitement dans l’environnement Eclipse, qui déploie à chaud toutes les modifications de code dans un conteneur OSGi en cours d’exécution dans l’environnement. Cependant, la configuration ne rest pas intacte à travers le processus d’assemblage Maven, bien qu’il y ait un très bon ingénieur de configuration / construction dont l’unique tâche est d’accomplir ce processus. Si nous nous débarrassions de Maven (très difficile maintenant en raison de la quantité de code, mais possible) et utilisions le plug-in BNDTOOLS Eclipse, nous pourrions simplement exporter la version Eclipse en tant que build Ant ou Gradle (notez que les développeurs OSGi qui écrivent BNDTOOLS ne supporte pas Maven, et pour cause, le plugin Maven est écrit par les développeurs Felix qui utilisent eux-mêmes Netbeans et Maven, et aucun environnement en direct autre que le cycle de déploiement), où les deux outils sont configurés de la même façon. environnement comme Eclipse, sans les objects d’interface graphique qui sont uniquement destinés aux développeurs. Le résultat serait une configuration identique et générée pour le déploiement. Cela permettrait d’économiser 2 à 3 heures par jour, par développeur, sur les versions lentes de Maven ou M2E, et de libérer l’ingénieur de configuration / configuration pour qu’il teste davantage l’application sur les hôtes de déploiement.

Surmonter l’état d’esprit d’écriture / compilation / assemblage / construction / déploiement / test est le seul obstacle majeur. Faire semblant de coder sur un terminal VT100 de 1979 plutôt que sur une machine moderne ne fait pas de vous un développeur «réel», cela démontre simplement que vos méthodes sont obsolètes depuis 35 ans.

Parmi les développeurs de l’équipe, aucun des autres ne comprend correctement un environnement d’object en direct comme Eclipse pour le faire fonctionner comme environnement live avec M2E et OSGi, et ils sont les principaux développeurs, ils n’y ont pas été exposés. à la prévalence des outils de développement de ligne de commande obsolètes. Ils ont seulement réalisé qu’il était possible de le faire quand nous étions en programmation pour résoudre le problème de configuration et je partageais mon écran, ce qui a poussé l’un des autres membres de l’équipe à s’exclamer: changement de code se teste instantanément dans le conteneur OSGi en arrière-plan. Je peux utiliser un shell bash quand il le faut, par exemple lorsque je consulte des journaux sur un serveur distant. En fait, je le fais de manière assez précise pour pouvoir sortir de cet environnement le plus rapidement possible et revenir au 21ème siècle.

Il y a tellement d’avantages à utiliser Ant ou Maven.

Maven est plus ou moins un concept de mise à jour de Ant. Au lieu de vous donner une réponse éclair, j’ai décidé de prendre une autre approche pour répondre à cette question. Je vais vous poser une question simple. Je suppose ici que vous seriez un développeur; ou avoir une sorte d’arrière-plan de programmation OO.

Donc, si votre responsable devait vous demander de copier deux cents répertoires, mais ignorez jar, war and ear fichiers jar, war and ear dans ces répertoires et une fois copiés. Vous déployez ensuite ces deux cents répertoires vers une autre destination, mais ne déployez que des fichiers .class ; copier le rest des fichiers dans une autre destination, etc.

Pour vous de faire cela en Java; ce sera beaucoup de logique, beaucoup de code et ne serait pas extensible ou adaptable au changement. C’est pourquoi Ant ou Maven réalisera et préparera tout cela à la volée avec moins de temps pour votre application. La taille du code dans ant ou Maven sera 1/4 comparée à Java.

Cliquez sur les liens pour plus d’avantages techniques:

Maven

Ant Je n’ai pas pu trouver une réponse authentique avec des avantages, mais je suis sûr que cela vous convaincrait;)

Maven et Ant sont habitués à créer des scripts pour qu’ils puissent être exécutés dans des travaux par lots comme Jenkins ou sur la ligne de commande.

En fait, Eclipse utilise beaucoup Ant pour construire des plugins.

Si vous apprenez l’un des deux, apprenez Maven, c’est celui que tout le monde utilise ces jours-ci (en remplacement de Ant).

Maven est généralement utilisé pour créer les plugins ou les fichiers JAR pour une application particulière.

Supposons que vous ayez développé une application mais que vous ne voulez pas append manuellement les jars nécessaires à cette application. Dans cette situation, Maven ou Ant est très utile. Une fois que vous avez écrit votre code juste pour exécuter As -> Maven Build (cliquez sur Maven Build), il générera tous les plugins ou fichiers JAR requirejs et sera inclus dans le chemin de compilation de votre bibliothèque d’applications. Un doute peut survenir quant à la manière dont l’application va obtenir ces fichiers. Pour chaque application, il existe un fichier XML nommé POM.xml, où la référence de tous les fichiers JAR est conservée à des fins de téléchargement.