Pourquoi si peu de gens utilisent Maven ? Existe-t-il des outils alternatifs ?

Question

Je suis novice en Java, et lorsque j'ai commencé mon développement, mes amis m'ont recommandé Maven pour la gestion de projet. J'ai presque immédiatement compris qu'il s'agissait d'un outil indispensable, et à ce moment-là, je pensais que tous les programmeurs l'utilisaient. Mais lorsque j'ai vu les statistiques sur le site de NetBeans, j'ai eu un choc : 67 % des développeurs n'utilisent pas Maven. Pourquoi ? Existe-t-il des outils alternatifs qui facilitent la gestion de projet ?

UPDATE

Je suis d'accord avec feicipet à 100%.

1) IDE indépendants c'est vraiment bien. J'en ai eu la preuve par ma propre expérience. D'abord, notre équipe a utilisé Eclipse, puis nous avons décidé de passer à NetBeans, les personnes qui nous aident avec le projet utilisant IDEA. Et cela n'a pas d'importance car le projet peut être exécuté même avec la console :)

2)Projet bien structuré et propre. Je pense que la convention de structure Maven est très utile, car les tests et le code principal sont séparés.

3)Gestion de projet. Maven n'est pas seulement un outil de construction Il vous permet de configurer votre environnement, d'exécuter des tests unitaires et de créer des rapports.

Pour moi, il a été surpris quand les programmeurs expérimentés parlent des difficultés de Maven, quand j'ai vu Ant dans un certain projet Maven m'a montré un miracle. Et tous les commentaires sur la complexité de la transition de Ant sont étranges. Il s'agit de deux logiques différentes, à quoi vous attendez-vous ?

Il y a quelques problèmes avec la documentation, c'est vraiment mauvais. Mais je pense que cette situation va s'améliorer.

Answer 1

Il existe de nombreuses alternatives - dans la communauté java et dans la communauté ruby. Pour un aperçu, consultez cette photo

Answer 2

IMO Maven est une sur-ingénierie. Machine Rube Goldberg ou, pour reprendre les mots de Graeme Rocher (fondateur de Grails), "le EJB2 des outils de construction". .

Je pense que les objectifs du projet Maven sont très louables. La convention sur la configuration ? Super ! Résolution automatique des dépendances ? Super ! Mais malheureusement, la pratique est très différente de la théorie. D'après mon expérience, l'introduction de Maven dans des projets qui étaient auparavant construits avec Ant a invariablement créé plus de problèmes qu'elle n'en a résolus. Dans un cas, Maven a commencé à nous prendre tellement de temps que nous avons fini par revenir à Ant.

Je pense que Maven pourrait valoir la peine si vous construisez un grand nombre de projets qui dépendent tous les uns des autres, et si le développement est largement distribué. Mais si vous construisez une seule application, et que vous voulez juste faire quelque chose de simple comme "construire un WAR à partir des éléments contenus dans ces répertoires", alors je m'éloignerais de Maven.

Un problème que j'ai rencontré avec Maven est qu'il est en fait assez inflexible si vous avez besoin de faire quelque chose qui va à l'encontre des conventions de Maven. Bien que vous puissiez passer outre ces conventions dans certains cas triviaux (par exemple, changer le nom du dossier source de src a source ), certaines de ses conventions semblent être gravées dans le marbre, par exemple un artefact par projet. Prenons l'exemple d'un projet Web Maven dont l'artefact est un fichier .war. Imaginons maintenant que nous voulions inclure le numéro de révision SVN actuel dans le nom du fichier .war. Cela ne semble pas particulièrement difficile à réaliser, mais à moins que vous ne trouviez un plugin qui le fait déjà, vous devrez probablement écrire votre propre plugin pour y parvenir, ce qui n'est pas une tâche triviale, car cela nécessite de comprendre le modèle de cycles de vie et d'objectifs de Maven.

De même, en termes de gestion des dépendances, le comportement par défaut de Maven est contraire aux bonnes pratiques de gestion des versions. Plus précisément, les dépendances d'un projet devraient être enregistrées dans le contrôle de version en même temps que le code source et les autres ressources qu'il utilise. Cependant, le comportement par défaut de Maven consiste à spécifier de manière déclarative vos dépendances qui sont ensuite téléchargées "magiquement" depuis les dépôts Maven au moment de la construction. Ainsi, si ces dépendances disparaissent des dépôts ou si vous perdez votre connexion Internet, vous ne pouvez plus construire votre projet ! L'utilisation d'un référentiel Maven local qui met en cache les dépendances téléchargées à partir de référentiels distants (et vous donne un endroit où publier vos propres artefacts) atténue ce risque.

Pour répondre à la deuxième partie de votre question sur les alternatives : Je ne l'ai pas utilisé personnellement, mais j'ai entendu de très bonnes choses à son sujet. Gradle . Un certain nombre de projets JVM de premier plan, tels que Spring et Hibernate, qui étaient auparavant construits avec Maven, sont récemment passés à Gradle.

Answer 3

J'aime Maven et je l'utilise presque exclusivement dans mon entreprise. Mais je justifierais mes raisons de le faire :

1. Je dirige une équipe de développeurs et nous avons besoin de structure. J'ai besoin que la plupart de mes développeurs suivent un certain ensemble de conventions jusqu'à la mise en page projets. C'est pour faciliter pour les transferts lorsque l'attrition se produit.
2. Les archétypes de Maven sont une grande bénédiction à cet égard. Les seniors créent simplement des archétypes pour certains projets des modèles que tous les développeurs basent leurs projets. Il y a un générique très simple pour les cas cas pour lesquels nous n'avons pas réussi à prendre en compte. L'extraction d'un modèle basé sur ant à partir de SVN est moins intuitif à cet moins intuitif à cet égard, car le développeur devra toujours supprimer le fichier .svn métadonnées une fois qu'il a été vérifié sortie.
3. Maven nous aide à rester agnostique vis-à-vis des IDE. Je ne veux pas baser l'un de mes projets de politique d'embauche sur l'IDE que le développeur préfère utiliser. Au moins 2 principaux IDEs (Eclipse et NetBeans) ont une assez bonne intégration à Maven, de sorte qu'un pom.xml Le fichier est déjà le site définition d'un projet IDE. Je peux dire à tout nouveau développeur qu'il peut utiliser l'IDE qu'il préfère tant que le système de construction lui-même est basé sur Maven.
4. J'ai trouvé que le développement processus de démarrage pour reprendre les choses à mi-chemin a été drastiquement réduit quand je suis passé à Maven. Les nouveaux développeurs de développeurs, même ceux qui ne sont pas familiers avec le projet en question, ont pu au moins compiler, empaqueter et déployer déployer dans la demi-heure qui suivait du projet. Le personnel de soutien (qui n'est généralement pas aussi techniquement compétents) ont pu se concentrer sur le dépannage et sans se préoccuper de la construction du projet, ce qui est une irritation inutile.

Dans l'ensemble, Maven répond parfaitement à mes besoins. Je suis d'accord dans une certaine mesure pour dire qu'un développeur indépendant qui a son propre flux de travail et ses propres pratiques de gestion de projet n'en tirera peut-être pas grand profit, mais aucun d'entre nous ici ne travaille dans le vide par lui-même.

Answer 4

Un grand nombre des problèmes liés à Maven que j'ai rencontrés sont énumérés et résolus dans ce document. blog entrée. D'après mon expérience, les développeurs Java sont habitués à avoir un contrôle total sur leurs projets. La plupart des raisons pour lesquelles ils sont contre Maven sont essentiellement "ce n'est pas ant" ou je ne peux pas faire X comme je peux le faire dans ant".

Il y a certainement des griefs valables. La documentation est souvent lamentable, la courbe d'apprentissage peut être abrupte et la configuration est verbeuse. En raison de l'importance des conventions, lorsque quelque chose ne va pas, il peut être très difficile de déterminer si c'est votre faute ou celle d'une fonctionnalité ou d'un bug d'un plugin.

Compte tenu des points négatifs, il est compréhensible que les gens ne soient pas enclins à investir du temps et des efforts dans un outil de construction lorsque vous pouvez utiliser ce que vous connaissez (ant/make/quelque chose) et continuer à "faire le travail", après tout vos clients ne se soucient pas de savoir si votre processus de construction est sexy.

Answer 5

Je pense que Maven souffre d'une barrière à l'entrée relativement élevée par rapport à des outils comme Ant. Les difficultés rencontrées avec les versions antérieures et la complexité de la version 2.0 m'ont tenu à l'écart. Il n'est pas nécessaire à 100%, surtout si vous avez un bon IDE.