Maven: The definitive Guide FR

Le paradigme "Convention over Configuration" (en français convention plutôt que configuration) repose sur une idée simple. Par défaut, les systèmes informatiques, les bibliothèques et les frameworks devraient avoir un comportement raisonnable. Un système devrait être "prêt à l'emploi" sans demander de configuration superflue. De célèbres frameworks comme Ruby on Rails et EJB3 ont commencé à appliquer ces principes en réaction à la complexité du paramètrage de frameworks tels que les spécifications initiales EJB 2.1. On retrouve une illustration de ce principe au travers de la persistance EJB3 : pour rendre une classe persistante tout ce que vous avez à faire est de l'annoter avec @Entity. Le framework va considérer que les noms de la table et des colonnes seront ceux de la classe et de ses attributs. Si le besoin s'en ressent, vous pouvez surcharger ces noms prédéfinis, mais la plupart du temps, l'usage de ces conventions implicites du framework procurera un gain de temps appréciable au projet.

Maven intègre ce concept en ayant un comportement logique par défaut. Sans configuration spécifique, le code source est supposé se trouver dans ${basedir}/src/main/java et les différentes ressources dans ${basedir}/src/main/resources. Les tests, eux, sont supposés être dans ${basedir}/src/test, et un projet est supposé produire un fichier JAR. Maven suppose que vous voulez compiler en bytecode dans ${basedir}/target/classes et ensuite créer votre fichier JAR distribuable dans ${basedir}/target. Même si tout cela peut sembler trivial, n'oubliez pas que pour la plupart des scripts Ant vous devez définir les emplacements de ces différents répertoires. Ant n'a pas la moindre idée d'où se trouve le code source et les différentes ressources, vous devez le lui indiquer. L'adoption par Maven de ce principe de "convention plutôt que configuration" va plus loin que les répertoires, les plugins au cœur de Maven appliquent un ensemble de conventions pour compiler le code source, packager les éléments à distribuer, produire des sites web, et bien d'autres traitements. La force de Maven vient de ses "convictions", il a un cycle de vie bien défini et un ensemble de plugins de base pour construire et assembler un logiciel. Si vous suivez les conventions, Maven ne va vous demander quasiment aucun effort - vous n'avez qu'à mettre votre code source dans le bon répertoire et Maven s'occupe du reste.

Une des conséquences des systèmes respectant le principe de "convention plutôt que configuration" est que leurs utilisateurs peuvent se sentir contraints de suivre une certaine méthodologie. S'il est vrai que Maven a fait certains choix qui ne doivent pas être remis en cause, la plupart des valeurs par défaut peuvent être adaptées. Par exemple, il est tout à fait possible de modifier l'emplacement du code source et des ressources pour un projet, de redéfinir les noms des fichiers JAR, et il est possible d'adapter presque tous les comportements aux spécificités de votre projet par le développement de plugins spécifiques. Si vous ne souhaitez pas suivre les conventions, Maven vous permettra de changer les valeurs par défaut selon vos propres besoins.