Pourquoi avons-nous besoin de Maven ou Ant, si nous avons déjà Eclipse?
Je pense que cette question est une extension de Comparez avec le IDE pour Java, avons-nous encore besoin de Ant?
Il y a des réponses à la question ci-dessus, mais je souhaite connaître un exemple concret d'utilisation de Maven ou Ant sur simplement Eclipse.
Lorsque je développe dans Eclipse, Eclipse fait tout pour moi et j'ai juste besoin de cliquer sur le bouton Exécuter. De plus, Eclipse peut vous permettre d'exporter votre code vers un fichier exécutable ou même .exe pour Windows.
Donc je ne sais vraiment pas pourquoi j'ai besoin de Maven ou Ant.
Et aussi si j'ai besoin, lequel dois-je choisir, Maven ou Ant?
- Parce que votre collègue pourrait préférer NetBeans ou IDEA
- Parce que les paramètres peuvent varier d'une installation Eclipse à une autre
- Parce que vous voudrez peut-être obtenir vos dépendances automatiquement
- Parce que vous voulez automatiser la construction complète: construire, jar, appliquer une analyse de code statique, exécuter les tests unitaires, générer la documentation, copier dans un répertoire, régler certaines propriétés en fonction de l'environnement, etc.
- Parce qu'une fois automatisé, vous pouvez utiliser un système d'intégration continue qui construit l'application à chaque changement ou toutes les heures pour vous assurer que tout se construit toujours et que les tests passent toujours ...
- Parce que Maven utilise la convention sur la configuration.
- Parce que votre IDE peut ne pas prendre en charge la génération/transformation de code sophistiquée dont vous avez besoin.
- Parce qu'un script de build documente le processus de build.
Eclipse est un environnement de développement. Mais ce n'est pas un outil de construction.
Personnellement, je déteste Maven, mais YMMV. Il existe de nombreuses alternatives: gradle, buildr, etc.
Maven me semble être le cas de quelque chose écrit par un tas de kiddies de script c-Shell passés à la date de vente qui pensent qu'autoconf mène l'automatisation du code Edge et ne comprennent pas ce code objet nécessite = un environnement objet pour être efficace de quelque manière que ce soit pour le développement ou le déploiement. Ant était déjà assez mauvais, mais Maven combine toutes les pires caractéristiques de Ant et Ivy. Il ne crée pas un environnement objet et ne fonctionne pas bien avec les outils qui le font.
Simplement, un environnement d'objet doit avoir tous les objets de classe, c'est-à-dire les objets qui déterminent les types d'objets disponibles pour le système, vivants et disponibles à tout moment. De là, je peux faire tout ce que je veux, instancier plusieurs objets d'une classe, mettre en place diverses séquences et règles d'instanciation, etc. Puisque l'environnement doit être complètement vivant, je ne devrais pas besoin un outil de construction à tout. En termes de déploiement de mon application, il n'est pas difficile pour l'environnement de simplement jeter tous les objets de classe qui ne sont jamais référencés par du code dans les espaces de noms qui composent mon application. Le garbage collector de la JVM fait presque la même chose à la volée aujourd'hui. À ce stade, j'ai un environnement de déploiement composé de mes objets et de tous les objets (principalement des objets de classe) auxquels mes objets font référence, c'est-à-dire mon application et toutes les dépendances. C'est ainsi que fonctionnent les machines virtuelles. (que nos VM sont si mal écrites que nous devons exécuter un Spring VM sur un Java VM sur un Linux = VM sur un VMWare VM sur un autre Linux VM est un autre exemple de l'idiotie du développement logiciel). Lorsque les dépendances sont mises à jour) , il est assez simple pour que l'environnement invite le développeur à fusionner son ancien code avec les nouvelles bibliothèques, à fusionner le code en utilisant les nouvelles bibliothèques vers l'ancienne version ou à conserver les deux versions. L'invite encourage le développeur à apporter les légères modifications qui sont parfois nécessaire pour éviter d'avoir vingt versions de chaque bibliothèque, tandis que des outils comme Maven masquent le fait que vous avez vingt versions et entraînent le ballonnement d'exécution massif commun dans les applications Java Java.
Dans l'espace de développement Java Java, Eclipse se rapproche le plus d'un environnement d'objet approprié, bien qu'il soit accordé qu'il existe de nombreux plugins qui brisent le paradigme de diverses manières. La plupart des raisons avancées pour utiliser Maven s'effondrent lorsque examiné de façon critique.
Netbeans et Idea sont des éditeurs de texte exagérés, pas des environnements d'objets, mais si vous voulez utiliser leurs outils pour quelque chose qui n'est pas couvert par les milliers de plugins Eclipse, les deux peuvent importer et maintenir des projets Eclipse, votre build sera juste excessivement lent par rapport aux développeurs en utilisant Eclipse, mais alors, ils seraient si lents s'ils étaient de purs projets Netbeans ou Idea de toute façon.
Pas une raison sérieuse d'utiliser Maven.
La facilité d'exportation/importation des paramètres dans Eclipse (quelque chose que chaque équipe devrait faire dans tous les IDE dans tous les cas) rend le problème des différents paramètres rien de plus que la paresse de la part de l'équipe de développement (ou un argument religieux sur les espaces vs tabs, 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 à la fois la fonctionnalité et le problème de maintenance en configurant également les référentiels Nexus?
C'est en fait une bonne raison PAS pour utiliser Maven.
Vous exécutez une version de serveur? Une bonne idée, maintenant, ne devrait-elle pas être lancée par du code qui est en fait archivé au référentiel source plutôt qu'une construction aléatoire qui se trouve poussée vers Nexus? Cela soulève un point contre Git, en particulier Git avec Maven. Étant donné que dans Git, je ne travaille pas sur une branche, teste localement, puis valide (en partie parce que mon test local ne prouve pas que la construction du serveur fonctionne en raison de différences dans la configuration Maven dans Jenkins et Eclipse) Je dois valider mes modifications dans une branche différente afin de voir que la construction du serveur Maven échoue, puis validez une autre modification pour résoudre le problème, résultant en un historique source illisible dans le référentiel. Le code archivé devrait à tout le moins générer et passer des tests unitaires, ce qui, si Git et Maven étaient hors de l'image, devrait être garanti.
L'exportation d'une build sans tête à partir d'Eclipse est triviale si vous y regardez réellement - tout ce dont vous avez besoin est ant ou Gradle, la build de développeur déjà maintenue par Eclipse, et quelques pots Eclipse (Eclipse exportera tous les fichiers nécessaires pour une build sans tête vers un répertoire ou fichier Zip, ou les ftp sur le serveur de build). Les outils de construction de serveur comme Hudson/Jenkins peuvent extraire le code mis à jour de la plupart des dépôts source et appeler n'importe quel script de construction, il n'y a aucune dépendance à Maven. Avec Maven, vous forcez les développeurs à utiliser un outil qui ne convient à personne mais aux ingénieurs de construction (les amplitudes plus longues à construire, même en utilisant M2E, sont suffisantes pour que ce cas soit fait), ou vous vivez avec la possibilité que la construction du serveur ne fonctionne pas tout à fait comme la construction du poste de travail, ce qui est toujours vrai si vous passez par tous les tracas de l'intégration des deux en utilisant la pléthore de plugins M2E. Dans les deux cas, vous obtenez une version de station de travail plus lente et plus fragile pour une version de serveur tout aussi lente et plus fragile. Sur chaque projet basé sur Maven sur lequel j'ai travaillé, j'ai vu des erreurs transitoires Hudson/Jenkins qui n'apparaissent pas dans Eclipse à moins que vous n'ayez absolument chaque possible plug-in M2E installé et correctement configuré, et la plupart des développeurs jamais fait.
On dirait 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 cassant Java espaces de noms et espaces de noms XML, c'est une unité de construction (le POM) n'ayant aucune relation avec quoi que ce soit dans le déploiement réel environnement (pensez-y, lorsque vous séparez via POM 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 que tous exécuter comme un morceau de code monolithique); les tracas de la maintenance manuelle des fichiers de configuration complexes, qui ne font qu'empirer si vous devez utiliser OSGi ou un autre conteneur et devez conserver d'autres fichiers de configuration qui affectent et sont affectés par la configuration Maven avec très peu de sens évident pour lui; les problèmes causés par la tentative d'exécuter des tests unitaires sans un environnement complet pour le code à exécuter; les innombrables versions non seulement des dépendances mais des plugins spécifiques à Maven (j'ai en fait vu l'enfer JAR dans t il Maven build lui-même où plusieurs plugins Maven utilisaient des dépendances conflictuelles - l'un des problèmes que Maven était censé résoudre.
Oui, vous pouvez construire du code objet avec Maven. Vous pouvez aussi écrire du code objet pur en C ou même assembleur, mais je ne sais pas pourquoi vous voudriez.
La meilleure raison d'éviter Maven est la quantité phénoménale de travail requise pour démavaliser 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 à écrire du code, compiler, assembler, construire, déployer, tester, recommencer, est désespérément dépassée dans un environnement objet. À un moment donné, nous devons dire à toutes les personnes ayant cet état d'esprit qu'elles doivent réapprendre à se développer, point final. Cela supprimerait tout besoin de Maven, Git et d'une multitude d'autres outils qui ne font que perdre du temps.
Le développement d'objet doit être effectué dans un environnement d'objet actif, où un changement de code est testé au fur et à mesure qu'il est enregistré puisque l'objet modifié est actif. Le déploiement doit consister à supprimer uniquement les artefacts de développement de cet environnement, à créer un environnement d'exécution qui utilise tout ce qui est utilisé par l'application en cours de développement et de test.
Je suis actuellement confronté à un problème causé par 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 survit pas intacte à travers le processus d'assemblage maven, malgré un très bon ingénieur de configuration/construction dont le seul travail consiste à 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 plugin BNDTOOLS Eclipse, nous pourrions simplement exporter la build Eclipse en tant que build sans tête Ant ou Gradle (notez, les développeurs OSGi qui écrivent BND et BNDTOOLS ne pas supporte Maven, et pour cause, le plugin Maven est écrit par les développeurs Felix qui eux-mêmes utilisent Netbeans et Maven, et aucun environnement live autre qu'à la fin du cycle de déploiement), où les deux outils configurent l'environnement même comme Eclipse, sans les objets GUI qui ne sont de toute façon destinés qu'aux développeurs. Le résultat serait une configuration et une construction identiques pour le déploiement. Cela économiserait facilement 2 à 3 heures par jour par développeur actuellement passé à regarder les builds Maven ou M2E lents, et libérerait l'ingénieur config/build pour faire plus de tests de l'application sur les hôtes de déploiement.
Surmonter la mentalité d'écrire/compiler/assembler/construire/déployer/tester est le seul obstacle majeur. Prétendre que vous codez sur un terminal VT100 de 1979 au lieu d'une machine moderne ne fait pas de vous un "vrai" développeur, cela démontre simplement que vos méthodes sont périmées depuis 35 ans.
Parmi les développeurs de l'équipe, aucun des autres ne comprend suffisamment un environnement d'objets en direct comme Eclipse pour le faire fonctionner comme un environnement en direct avec M2E et OSGi, et ce sont des développeurs de haut niveau, ils n'y ont tout simplement pas été exposés en raison à la prévalence d'outils de développement de ligne de commande obsolètes. Ils ont seulement réalisé que c'était possible de le faire lorsque nous programmions en binôme pour résoudre le problème de configuration et que je partageais mon écran, ce qui a poussé l'un des autres membres de l'équipe à s'exclamer "c'est = comment vous écrivez du code si vite ", quand il a vu mon code changer instantanément se tester dans le conteneur OSGi en arrière-plan. Je peux utiliser un shell bash quand je le dois, comme quand je regarde les journaux sur un serveur distant, en fait je le fais assez efficacement pour que je puisse sortir de cet environnement le plus rapidement possible et revenir au 21 siècle.
Il y a tellement d'avantages à utiliser Ant ou Maven.
Maven est plus ou moins un concept de mise à jour d'Ant. Au lieu de vous donner une réponse sous forme de puce, j'ai décidé d'adopter une autre approche pour répondre à cette question. Je vais vous poser une question simple. Je suppose ici que vous seriez développeur; ou avoir une sorte de fond de programmation OO.
Donc, si votre responsable vous demandait de copier deux cents répertoires, mais ignorez jar, war and ear fichiers dans ces répertoires et une fois copiés. Vous déployez ensuite ces deux cents répertoires vers une autre destination, mais déployez uniquement .class des dossiers; copier le reste des fichiers dans une autre destination, etc.
Pour vous de le faire en Java; ce sera beaucoup de logique, beaucoup de code et ne serait pas extensible ou adaptable au changement. Pour que l'esprit ou Maven accomplisse et prépare tout cela à la volée avec moins de frais généraux pour que votre application puisse l'utiliser. La taille du code dans ant ou Maven sera 1/4 comparer à Java.
Cliquez sur les liens pour plus d'avantages techniques:
Ant Je n'ai pas pu trouver une réponse authentique avec des avantages, mais je suis sûr que cela vous convaincra;)
Maven et Ant sont utilisés pour créer des scripts afin qu'ils puissent être exécutés dans des travaux par lots comme avec Jenkins ou sur la ligne de commande.
En fait, Eclipse lui-même utilise beaucoup Ant pour créer des plugins.
Si vous deviez apprendre l'un des deux, apprenez Maven, c'est celui que tout le monde utilise de nos jours (en remplacement de Ant).
Maven est généralement utilisé pour créer des plugins ou des pots pour une application particulière.
Supposons que vous ayez développé une application mais que vous ne souhaitiez pas ajouter manuellement les pots nécessaires à cette application. Dans cette situation, Maven ou Ant est très utile. Une fois que vous avez écrit votre code dans Run As -> Maven Build (cliquez sur Maven Build), il générera tous les plugins ou jars requis et les inclura dans le chemin de construction de votre bibliothèque d'applications. Un doute peut survenir quant à la manière dont l'application obtiendra ces fichiers JAR. Pour chaque application, il existe un fichier xml nommé POM.xml où les références de tous les fichiers JAR sont conservées à des fins de téléchargement.