Différences entre fourmi et Maven [fermé]

Dans Maven: The Definitive Guide , j'ai écrit sur les différences entre Maven et Ant dans l'introduction le titre de la section est "Les Différences Entre Ant et Maven" . Voici une réponse qui est une combinaison de l'info de cette introduction avec quelques notes supplémentaires.

Une Simple Comparaison

je vous montre seulement ceci pour illustrer l'idée que, à la au niveau le plus élémentaire, Maven a intégré des conventions. Voici un simple fichier Ant build:

<project name="my-project" default="dist" basedir=".">
    <description>
        simple example build file
    </description>   
    <!-- set global properties for this build -->   
    <property name="src" location="src/main/java"/>
    <property name="build" location="target/classes"/>
    <property name="dist"  location="target"/>

    <target name="init">
      <!-- Create the time stamp -->
      <tstamp/>
      <!-- Create the build directory structure used by compile -->
      <mkdir dir="${build}"/>   
    </target>

    <target name="compile" depends="init"
        description="compile the source " >
      <!-- Compile the java code from ${src} into ${build} -->
      <javac srcdir="${src}" destdir="${build}"/>  
    </target>

    <target name="dist" depends="compile"
        description="generate the distribution" >
      <!-- Create the distribution directory -->
      <mkdir dir="${dist}/lib"/>

      <!-- Put everything in ${build} into the MyProject-${DSTAMP}.jar file
-->
      <jar jarfile="${dist}/lib/MyProject-${DSTAMP}.jar" basedir="${build}"/>
   </target>

   <target name="clean"
        description="clean up" >
     <!-- Delete the ${build} and ${dist} directory trees -->
     <delete dir="${build}"/>
     <delete dir="${dist}"/>
   </target>
 </project>

dans cet exemple de fourmi simple, vous pouvez voir comment vous devez dire à Fourmi exactement quoi faire. Il y a un but de compilation qui inclut la tâche javac qui compile la source dans le répertoire src/main/java vers le répertoire cible/classes. Vous devez dire à Ant exactement où est votre source, où vous voulez que le bytecode résultant soit stocké, et comment empaqueter tout cela dans un bocal fichier. Bien que certains développements récents contribuent à rendre Ant moins procédural, L'expérience D'un développeur avec Ant est de coder un langage procédural écrit en XML.

comparer L'exemple Ant précédent avec un exemple Maven. Dans Maven, pour créer un fichier JAR à partir D'une source Java, tout ce que vous avez à faire est de créer un simple pom.xml, placez votre code source dans ${basedir} / src/main / java et lancez mvn install à partir de la ligne de commande. L'exemple Maven pom.xml qui réalise le mêmes résultats.

<project>
  <modelVersion>4.0.0</modelVersion>
  <groupId>org.sonatype.mavenbook</groupId>
  <artifactId>my-project</artifactId>
  <version>1.0</version>
</project>

C'est tout ce dont vous avez besoin dans votre pom.XML. L'exécution de mvn install à partir de la ligne de commande permettra de traiter les ressources, de compiler les sources, d'exécuter des tests d'Unité, de créer un JAR et d'installer le JAR dans un dépôt local pour le réutiliser dans d'autres projets. Sans modification, vous pouvez lancer le site mvn et ensuite trouver un index.fichier html dans target / site qui contient des liens vers JavaDoc et quelques rapports sur votre code source.

certes, c'est le exemple de projet le plus simple possible. Un projet qui ne contient que du code source et qui produit un JAR. Un projet qui suit les conventions Maven et ne nécessite pas de dépendances ou de personnalisation. Si nous voulions commencer à personnaliser le comportement, notre pom.xml va croître en taille, et dans le plus grand des projets, Vous pouvez voir des collections de mamans très complexes qui contiennent beaucoup de personnalisation de plugin et de déclarations de dépendances. Mais, même lorsque les fichiers POM de votre projet deviennent plus substantiel, ils détiennent un type entièrement différent d'informations du fichier de construction d'un projet de taille similaire en utilisant Ant. Maven POMs contient des déclarations: "Ceci est un projet JAR", et "le code source est dans src/main/java". Les fichiers de construction Ant contiennent des instructions explicites:" Ceci est le projet", "la source est dans src/main/java ", "exécuter javac contre ce répertoire", "mettre les résultats dans target/classses ", " créer un bocal à partir de la ....", etc. Où Ant devait être explicite sur le processus, il y avait quelque chose "intégré" à Maven qui savait juste où était le code source et comment il devait être traité.

comparaison de haut niveau

les différences entre Ant et Maven dans cet exemple? Fourmi...

• n'a pas de conventions formelles comme une structure commune de répertoire de projet, vous devez dire à Ant exactement où trouver la source et où mettre la sortie. Informel des conventions sont apparues au fil du temps, mais elles n'ont pas été codifiées dans le produit.
• est procédurale, vous avez à dire Ant exactement quoi faire et quand le faire. Il fallait lui dire de compiler, puis de copier, puis de compresser.
• n'a pas de cycle de vie, il fallait définir des objectifs et des dépendances de but. Vous avez dû attacher une séquence de tâches à chaque but manuellement.

Où Maven...

• a des conventions, il savait déjà où était votre code source parce que vous avez suivi la convention. Il a mis le bytecode dans target/classes, et il a produit un fichier JAR dans target.
• est déclaratif. Tout ce que vous aviez à faire était de créer un pom.fichier xml et de mettre votre code source dans le répertoire par défaut. Maven a pris soin de tout le reste.
• a un cycle de vie, que vous avez invoqué lorsque vous avez exécuté mvn install . Cette commande dit à Maven d'exécuter une série de séquence des étapes jusqu'à ce qu'il atteigne le cycle de vie. Comme effet secondaire de ce voyage à travers le cycle de vie, Maven a exécuté un certain nombre d'objectifs de plugin par défaut qui ont fait des choses comme compiler et créer un JAR.

Et Ivy?

exact, donc Quelqu'un comme Steve Loughran va lire cette comparaison et appeler faute. Il va parler de la façon dont la réponse ignore complètement quelque chose appelé Ivy et le fait que Ant peut réutiliser construire une logique dans les versions plus récentes de Ant. Ce qui est vrai. Si vous avez un tas de gens intelligents utilisant Ant + antlibs + Ivy, vous finirez avec une construction bien conçue qui fonctionne. Même si je suis convaincu que Maven a du sens, je serais heureux D'utiliser Ant + Ivy avec une équipe de projet qui avait un ingénieur de construction très pointu. Cela étant dit, je pense que vous finirez par défaut sur un certain nombre de greffons comme la Jetée plugin et que vous finirez par avoir un tas du travail que tu n'avais pas besoin de faire au fil du temps.

plus Important que Maven vs. Ant

1. est que vous utilisez un gestionnaire de dépôt pour garder une trace des artéfacts logiciels. Je suggère télécharger Nexus . Vous pouvez utiliser Nexus Pour proxy des dépôts distants et pour fournir un endroit pour votre équipe de déployer des artéfacts internes.
2. vous avez la modularisation appropriée de les composants logiciels. Une grande composante monolithique s'échelonne rarement dans le temps. Que votre projet se développe, vous aurez envie d'avoir le concept de modules et sous-modules. Maven se prête très bien à cette approche.
3. vous adoptez quelques conventions pour votre construction. Même si vous utilisez Ant, vous devriez vous efforcer d'adopter une forme de convention qui est compatible avec d'autres projets. Quand un projet utilise Maven, cela signifie que n'importe qui familier avec Maven peut prendre la construction et commencer courir sans avoir à jouer avec la configuration de comprendre comment obtenir la chose à compiler.

Maven est un Cadre, la Fourmi est une boîte à outils

Maven est une voiture de route pré-construite, alors que Ant est un ensemble de pièces de voiture. Avec Fourmi, vous devez construire votre propre voiture, mais au moins, si vous avez besoin de faire du hors-route, vous pouvez construire le bon type de voiture.

autrement dit, Maven est un cadre tandis que Ant est une boîte à outils. Si vous êtes satisfait de travailler dans les limites du cadre, Maven s'en sortira très bien. Le le problème pour moi était que je n'arrêtais pas de me cogner dans les limites du cadre et il ne me laissait pas sortir.

"151930920 XML" Verbosité

tobrien est un gars qui en sait beaucoup sur Maven et je pense qu'il a fourni une très bonne, honnête comparaison des deux produits. Il a comparé un simple Maven pom.xml avec un simple fichier de construction de fourmis et il a fait mention de la façon dont les projets Maven peuvent devenir plus complexes. Je pense que cela vaut la peine de jeter un oeil à une comparaison d'un couple de dossiers que vous êtes plus susceptibles de voir dans un simple projet réel. Les fichiers ci-dessous représentent un module unique dans une construction multi-modules.

tout d'Abord, le Maven fichier:

<project 
    xmlns="http://maven.apache.org/POM/4.0.0" 
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-4_0_0.xsd">

    <parent>
        <groupId>com.mycompany</groupId>
        <artifactId>app-parent</artifactId>
        <version>1.0</version>
    </parent>

    <modelVersion>4.0.0</modelVersion>
    <artifactId>persist</artifactId>
    <name>Persistence Layer</name>

    <dependencies>

        <dependency>
            <groupId>com.mycompany</groupId>
            <artifactId>common</artifactId>
            <scope>compile</scope>
            <version>${project.version}</version>
        </dependency>

        <dependency>
            <groupId>com.mycompany</groupId>
            <artifactId>domain</artifactId>
            <scope>provided</scope>
            <version>${project.version}</version>
        </dependency>

        <dependency>
            <groupId>org.hibernate</groupId>
            <artifactId>hibernate</artifactId>
            <version>${hibernate.version}</version>
            <scope>provided</scope>
        </dependency>

        <dependency>
            <groupId>commons-lang</groupId>
            <artifactId>commons-lang</artifactId>
            <version>${commons-lang.version}</version>
            <scope>provided</scope>
        </dependency>

        <dependency>
            <groupId>org.springframework</groupId>
            <artifactId>spring</artifactId>
            <version>${spring.version}</version>
            <scope>provided</scope>
        </dependency>

        <dependency>
            <groupId>org.dbunit</groupId>
            <artifactId>dbunit</artifactId>
            <version>2.2.3</version>
            <scope>test</scope>
        </dependency>

        <dependency>
            <groupId>org.testng</groupId>
            <artifactId>testng</artifactId>
            <version>${testng.version}</version>
            <scope>test</scope>
            <classifier>jdk15</classifier>
        </dependency>

        <dependency>
            <groupId>commons-dbcp</groupId>
            <artifactId>commons-dbcp</artifactId>
            <version>${commons-dbcp.version}</version>
            <scope>test</scope>
        </dependency>

        <dependency>
            <groupId>com.oracle</groupId>
            <artifactId>ojdbc</artifactId>
            <version>${oracle-jdbc.version}</version>
            <scope>test</scope>
        </dependency>

        <dependency>
            <groupId>org.easymock</groupId>
            <artifactId>easymock</artifactId>
            <version>${easymock.version}</version>
            <scope>test</scope>
        </dependency>

    </dependencies>

</project>

et le fichier Ant équivalent:

<project name="persist" >

    <import file="../build/common-build.xml" />


    <path id="compile.classpath.main">
        <pathelement location="${common.jar}" />
        <pathelement location="${domain.jar}" />
        <pathelement location="${hibernate.jar}" />
        <pathelement location="${commons-lang.jar}" />
        <pathelement location="${spring.jar}" />
    </path>


    <path id="compile.classpath.test">
        <pathelement location="${classes.dir.main}" />
        <pathelement location="${testng.jar}" />
        <pathelement location="${dbunit.jar}" />
        <pathelement location="${easymock.jar}" />
        <pathelement location="${commons-dbcp.jar}" />
        <pathelement location="${oracle-jdbc.jar}" />
        <path refid="compile.classpath.main" />
    </path>


    <path id="runtime.classpath.test">
        <pathelement location="${classes.dir.test}" />
        <path refid="compile.classpath.test" />
    </path>


</project>

tobrien a utilisé son exemple pour montrer que Maven a intégré des conventions, mais cela ne signifie pas nécessairement que vous finissez par écrire moins de XML. J'ai trouvé le contraire pour être vrai. Le POM.xml est 3 fois plus long que le construire.xml et cela sans s'écarter des conventions. En fait, mon exemple Maven est affiché sans 54 lignes supplémentaires qui étaient nécessaires pour configurer les plugins. Ce pom.xml est un projet simple. Le XML commence vraiment à se développer de manière significative lorsque vous commencez à ajouter des exigences supplémentaires, ce qui n'est pas inhabituel pour de nombreux projets.

mais il faut dire à Ant ce qu'il faut faire

My Ant exemple ci-dessus n'est pas complet bien sûr. Il nous reste à définir les cibles utilisées pour nettoyer, compiler, tester, etc. Ceux-ci sont définis dans un fichier de construction commun qui est importé par tous les modules dans le projet multi-modules. Ce qui m'amène à la question de savoir comment tout cela doit être écrit explicitement dans Ant alors qu'il est déclaratif dans Maven.

c'est vrai, ça me ferait gagner du temps si je n'écrivais pas explicitement ces cibles de fourmis. Mais combien de temps? Le fichier de construction commun J'utilise maintenant est celui que j'ai écrit il y a 5 ans avec seulement de légères améliorations depuis. Après mon expérience de 2 ans avec Maven, j'ai sorti le vieux dossier des fourmis du placard, je l'ai dépoussiéré et je l'ai remis au travail. Pour moi, le coût d'avoir à dire explicitement et que faire s'est additionné à moins d'une semaine sur une période de 5 ans.

complexité

la prochaine grande différence que je voudrais mentionner est celle de la complexité et le monde réel effet. Maven a été construit dans le but de réduire la charge de travail des développeurs chargés de créer et de gérer les processus de construction. Pour ce faire, il doit être complexe. Malheureusement, cette complexité tend à nier l'objectif visé.

par rapport à Ant, le type de construction sur un projet Maven passera plus de temps:

• documentation de lecture: il y a beaucoup plus de documentation sur Maven, parce qu'il y a tellement beaucoup plus que vous devez apprendre.
• former les membres de l'équipe: ils trouvent plus facile de demander à quelqu'un qui sait plutôt que d'essayer de trouver des réponses eux-mêmes.
• dépannage de la construction: Maven est moins fiable que Ant, en particulier les plugins non-core. De plus, les constructions Maven ne sont pas reproductibles. Si vous dépendez d'une version SNAPSHOT d'un plugin, ce qui est très probable, votre construction peut se casser sans que vous ayez changé quoi que ce soit.
• Writing Plugins Maven: les Plugins sont généralement écrits avec une tâche spécifique à l'esprit, par exemple créer un pack webstart, ce qui rend plus difficile de les réutiliser pour d'autres tâches ou de les combiner pour atteindre un objectif. Donc, vous devrez peut-être en écrire un vous-même pour contourner les lacunes dans le jeu de plugin existant.

en contraste:

• Ant la documentation est concis, complet et en un seul endroit.
• Ant est simple. Un nouveau développeur essayer d'apprendre Ant seulement besoin de comprendre quelques concepts simples (objectifs, des tâches, des dépendances, des propriétés) afin d'être en mesure de comprendre le reste de ce qu'ils doivent savoir.
• Ant est fiable. Il n'y a pas eu beaucoup de sorties de Ant au cours des dernières années parce que cela fonctionne déjà.
• les constructions Ant sont reproductibles car elles sont généralement créées sans aucune dépendance externe, comme les dépôts en ligne, plugins tiers expérimentaux, etc.
• Ant est complet. Parce que c'est une boîte à outils, vous pouvez combiner les outils pour effectuer presque toutes les tâches que vous souhaitez. Si vous avez besoin d'écrire votre propre tâche, il est très simple à faire.

Familiarité

une autre différence est celle de la familiarité. Les nouveaux développeurs ont toujours besoin de temps pour se mettre au courant. La connaissance des produits existants aide à ce point de vue et les partisans du Maven soutiennent à juste titre qu'il s'agit d'un avantage du Maven. Bien sûr, la flexibilité de Ant signifie que vous pouvez créer toutes les conventions que vous voulez. Si la convention que j'utilise est de mettre mes fichiers source dans un nom de répertoire src/main/java. Mes classes compilées vont dans un répertoire nommé cible/classes. Semble familier n'est-ce pas.

j'aime la structure de répertoire utilisée par Maven. Je pense que cela a du sens. Également construire leur cycle de vie. J'ai donc utiliser le même conventions dans ma Fourmi construit. Non seulement parce qu'elle fait sens, mais parce qu'il sera familier à quiconque a utilisé Maven avant.

Fourmi est principalement un outil de construction.

Maven est un outil de gestion de projet et de dépendances (qui bien sûr construit aussi votre projet).

Ant+ Ivy est une assez bonne combinaison si vous voulez éviter Maven.

Maven ou Ant? est une question très similaire à celle-ci, qui devrait vous aider à répondre à vos questions.

Qu'est-ce que le Maven? sur le site officiel.

edit: pour un nouveau projet/greenfield, je recommande D'utiliser Maven:" convention over configuration " vous fera gagner un temps considérable dans l'écriture et la mise en place de scripts de construction et de déploiement. Lorsque vous utilisez ant, la construction script tend à croître avec le temps dans la longueur et la complexité. Pour les projets existants, il peut être difficile d'intégrer leur configuration/disposition dans le système Maven.

Juste a faire une liste de plus de différences:

"151930920 les Fourmis n'ont pas de conventions formelles. Vous devez dire à Ant exactement où trouver la source, où placer les sorties, etc.
• Ant est procédural. Vous devez dire à Ant exactement quoi faire; lui dire de compiler, copier, puis compresser, etc.
• Ant n'a pas de cycle de vie.
• Maven utilise des conventions. Il sait où est votre code source automatiquement, tant que vous suivez ces conventions. Tu n'as pas besoin de dire à Maven où il est.
• Maven est déclaratif; Tout ce que vous avez à faire est de créer un pom.fichier xml et de mettre votre code source dans le répertoire par défaut. Maven va prendre soin de tout le reste.
• Maven a un cycle de vie. Vous appelez simplement mvn install et une série d'étapes de séquence sont exécutées.
• Maven a des renseignements sur les tâches communes du projet. Pour exécuter des tests, il suffit d'exécuter mvn test , tant que les fichiers sont dans l'emplacement par défaut. Dans Ant, vous devez D'abord lancer le fichier JAR is, puis créer un chemin de classe qui inclut le JAR JUnit, puis dire à Ant où chercher le code source de test, écrire un but qui compile la source de test et enfin exécuter les tests unitaires avec JUnit.

mise à jour:

ça vient de Maven: The Definitive Guide . Désolé, j'ai totalement oublié de le citer.

Maven agit à la fois comme un outil de gestion de dépendances - il peut être utilisé pour récupérer des pots d'un dépôt central ou d'un dépôt que vous avez mis en place - et comme un outil de construction déclarative. La différence entre un outil de construction "déclaratif" et un outil plus traditionnel comme ant ou make, c'est que vous configurez ce qui doit être fait, et non la façon de le faire. Par exemple, vous pouvez dire dans un script maven qu'un projet doit être empaqueté comme un fichier de guerre, et maven sait comment gérer cela.

Maven s'appuie sur des conventions sur la façon dont les répertoires de projets sont établis afin d'atteindre sa "déclarativité."Par exemple, il a une convention pour où mettre votre code principal, où mettre votre web.xml, vos tests de l'unité, et ainsi de suite, mais donne également la possibilité de les changer si vous avez besoin.

vous devez également garder à l'esprit qu'il existe un plugin pour exécuter des commandes ant à partir de maven:

http://maven.apache.org/plugins/maven-ant-plugin /

aussi, les archétypes de maven font démarrer un projet très rapidement. Par exemple, il y a un archetype de Wicket, qui fournit une commande maven que vous exécutez pour obtenir un projet entier prêt à exécuter de type hello world.

https://wicket.apache.org/start/quickstart.html

je peux prendre une personne qui n'a jamais vu Ant - ses build.xml sont raisonnablement bien écrits-et ils peuvent comprendre ce qui se passe. Je peux prendre cette même personne et leur montrer un pompon Maven et ils n'auront aucune idée de ce qui se passe.

dans une organisation d'ingénieurs qui est énorme, les gens écrivent sur les fichiers Ant qui deviennent gros et ingérables. J'ai écrit ces types de scripts et . C'est vraiment comprendre à l'avance ce que vous devez faire pour aller de l'avant et concevoir un ensemble de modèles qui peuvent répondre au changement et à l'échelle sur une période de trois ans et plus.

à moins que vous n'ayez un projet simple, apprendre les conventions Maven et la façon Maven pour obtenir des choses faites est tout un travail.

à la fin de la journée, vous ne pouvez pas considérer le démarrage d'un projet avec Ant ou Maven comme un facteur: c'est vraiment le coût total de la propriété. Ce qu'il faut pour que l'organisation maintienne étendre son système de construction sur quelques années est l'un des principaux facteurs à prendre en considération.

les aspects les plus importants d'un système de construction sont la gestion des dépendances et la flexibilité dans l'expression de la recette de construction. Il doit être quelque peu intuitif lorsqu'il est bien fait.

ça dépend de la taille de votre projet... Personnellement, J'utiliserais Maven pour des projets simples qui nécessitent une compilation, un empaquetage et un déploiement simples. Dès que vous avez besoin de faire des choses plus compliquées (nombreuses dépendances, création de fichiers de mappage...), Je voudrais passer à la Fourmi...

Maven abrite également un grand dépôt de projets open source couramment utilisés. Pendant la construction Maven peut télécharger ces dépendances pour vous (ainsi que vos dépendances dépendances :)) pour rendre cette partie de la construction d'un projet un peu plus gérable.