Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Ligne de commande, Makefile ou script
Ant
Ant + Ivy
Maven 1
Maven 2
Gradle
Ce qui est intégré à mon IDE
Un outil maison
Je ne sais pas
Autre chose (merci de préciser)
Quel(s) outil(s) de build Java utilisez-vous et pourquoi ?
Bonjour,
Afin de compléter un article en cours d'écriture, j'aurais voulu savoir quels sont les outils de builds que vous utilisez pour construire vos projets Java.
N'hésitez absolument pas (c'est même recommandé) à lister les avantages et inconvénients de l'outil que vous utilisez...
Personnellement j'utilise Ant depuis longtemps et depuis peu, je commence à le remplacer par Maven 2 dans mes projets.
Maven 2 permet de faire plus de chose de base qu'Ant sans avoir besoin de configurer de long script. De plus, les possibilités sont plus nombreuses (couverture de code, release, génération de rapports, site, ...).
Pour ma part j'utilise ant
+lisibilité (étant habitué à manipuler de l'XML)
+ simplicité pour des tâches usuelles comme la compilation, l'exécution du projet ou encore générer la javadoc
+Eclipse peut le générer (parfois il ne vaut mieux pas!)
-construction parfois complexe pour des tâches importantes
-propriétés pas toujours claires
De mon côté, j'utilise essentiellement Maven2, mais je commence à jeter un oeil sur Gradle (à mon avis, c'est plus pour le fun que pour vraiment l'utiliser, mais on ne sait jamais).
Concernant Maven 2 :
Les bons points :
- Si on respecte les conventions de Maven 2, l'écriture d'un pom.xml est très simple et peu verbeux.
- La gestion des dépendances, qui, sans être parfaite, a beaucoup simplifié les choses.
- L'héritage et les projets multi-modules.
- Les plugins de rapports.Le développement de nouveaux plugins est relativement simple.
- Pour des projets simples, avec un pom.xml, on peut faire plein de choses facilement (compilation, tests, création de sites, rapports, etc.).
- Bien supporté dans la plupart des outils d'Intégration Continue.
- Le principe de décrire son projet plutôt que de décrire les tâches que l'on souhaite réaliser (mais c'est un aussi un point négatif, dès que l'on veut faire quelque chose qui sorte de l'ordinaire).
Les mauvais points :
- Dès que l'on veut sortir un peu du système Maven2, que l'on veut faire des choses un peu en dehors du cadre de l'outil, ça devient vite complexe.
- Trop verbeux sur les dépendances. Pourquoi n'avoir pas dès le début permis une syntaxe à la Ivy (<dependency groupId="xxx" artifactId="xxx" version="xxx"/>) ?
- On utilise trop de plugins, parfois pour des tâches simples. Par exemple, si on a 2 répertoires de sources Java, le pom.xml est
- Documentation mal fichue sur le site (mais on a le droit à des livres gratuits en anglais et en français, ça compense).
- Les métadonnées XML sont très obscures je trouve (celles qui se trouvent dans le repository).
- XML parfois redondant, même en utilisant l'héritage.
- Mauvais support sur les IDE, en particulier sur les projets multi-modules, bien que ça s'améliore...
- Même si c'est de plus en plus rare avec un nombre croissant de plugins, c'est dommage d'avoir recours à Ant dans Maven2 pour faire certaines tâches qui sortent un peu de l'ordinaire (ou alors il faut développer son propre plugin).
- Développement et support des plugins "officiels" inégaux.
Bon, la liste n'est sans doute pas tout à fait complète, mais ça devrait refléter mon avis.
Pour conclure, je dirais que si je dois aller sur un nouveau projet, je choisirais clairement Maven2, malgré ses défauts.
Etant donné ma connaissance de l'outil, j'arrive généralement à m'en sortir sans trop de dégâts, dès qu'il y a des choses un peu exotiques à réaliser...
pour ma part c'est ant+ivy, mais suis souvent obligé de subir maven (je pourrais parler des heures de ma haine pour maven
j'espere beaucoup de gradle !
Juste pour ce point, je ne suis pas vraiment d'accord. Je ne connais pas le support Maven 2 de tous les IDE, mais pour ce qui est de IntelliJ Idea, il est vraiment excellent et réalise tout ce que ce que je veux, également pour les projets multi-modules.Envoyé par romaintaz
Je package occasionnellement avec eclipse.
Pour mes anciens projets, c'était tout en Ant.
Maitenant, je ne fais que du Maven.
Ant tout seul.
Avec un système Write-once, build anywhere on tient tous nos développements en modifiant 2 lignes lors d'un nouveau projet. Aucun souci.
Pour ma part, j'utilise Maven 2 depuis près de 6 mois, et le temps qu'il m'a fait gagner est considérable.
Les points faibles que je trouves sont certes anectotiques mais bon ...
- Customisation brouillon du site web généré
- Temps de build variant
- Tout est plugin, mais du coup le nombre de plugin est conséquent sur un projet
Buildr
Simple/puissant/pratique/explicite/succinct
Seul bémol : Ce n'est pas le "standard-d-entreprise-de-facto" (c'est mieu
D'expérience, un build (il est vrai pourri) est passé de 20 minutes en maven 1 à 3 minutes en buildr.
Salut,
Je suis toujours a Maven 1 (intégré dans eclipse) mais j'espère passer prochainement a la 2 mais cela ne me semble pas si "facile" .
Merci sylez pour ce retour.
Si tu pouvais nous en dire un peu plus sur Buildr, pour une fois qu'on a quelqu'un qui n'utilise ni Ant ni Maven
Bonjour,
J'ai découvert Maven avec la version 1. Franchement, je n'ai pas du tout accroché. Je ne voyais pas trop ce que cela apportait et que la mise en place était lourde. De plus, cela remonte à une précédente version d'Eclipse et le plugin n'était pas super super.
Mais depuis quelques temps, j'ai découvert Maven 2 avec l'intégration dans NetBeans 6.5 (puis 6.7). Et cette seconde expérience fut plus intéressante. L'intégration dans l'IDE est vraiment très bien, le RepoBrowser est utile tout comme l'autocomplétion dans le pom.xml.
L'utilisation des archetypes dans Maven2 et leur nombre est vraiment intéressant pour commencer un projet sur un standard de développement.
Par contre, le pom.xml est toujours très verbeux. Et il est quelque fois difficile de sortir des sentiers battus car il faut alors trouver la bonne balise à mettre au bon endroit.
Dans des projets TELECOM, où il s'agit des développements de grande echelle, on utilise principalement MAVEN 2.
Pour les raisons suivantes :
- Il réalise complètement la séparation entre la description du projet, et ce qu'on veut faire avec ( à l'oposé d'ant )
- Une fois la structure du projet réalisé en format MAVEN, on peut faire beaucoup de choses avec ce projet en utilisant différents plugin (Audit de qualité, test unitaires, alimentation d'un dashboard sonar, .... )
- On maitrise complètement notre socle de développement grâce à l'utilisation d'un projet DEPENDANCE qui encapsule notre Socle.
- Facilité de la maintenance du socle et la mise à jour sans perturber les développements.
Aussi on gagne en automatisation de build sur différent projet non Java en adoptant MAVEN 2 .
Salut,
J'ai voté pour Ant, Ivy, Eclipse et autres.
J'utilise généralement Ant pour coder mes builds. J'essais de me mettre à Ivy aussi (quoi que je suis devenu expert dans la résolution manuelle des dépendances en partantdes exceptions ClassNotFoundException).
J'utilise aussi Eclipse pour l'export des bundles OSGi.
Et enfin, je me suis mis à SBT (Simple Build Tool) pour le développement Scala (couplé à emacs) vu que le plugin Scala d'eclipse est limite inutilisable.
oui, je l'ai vu aussi, vu qu'en ce moment je regarde scala de pres aussi
C'est hyper simple d'emploi (pour les besoins basiques). un simple sbt dans un dossier, puis il te demande queques resneignements, et hop, ça te configure un projet directement fonctionnel.oui, je l'ai vu aussi, vu qu'en ce moment je regarde scala de pres aussi
SBT offre aussi la possilbité de générer un pom.xml à partir de tout ça.
Cela fait plus de deux ans que je suis passé de Maven 1 à Maven 2 et je dois avouer qu'à l'époque, je me suis fait un peu peur. La migration des plugins les plus importants de Maven 1 vers Maven 2 ne semblait pas encore complètement terminée. De plus, les différences entre Maven 2 et Maven 1 sont suffisantes pour que l'on subisse une certaine perturbation en passant à Maven 2.
De nos jours, un passage de Maven 1 à Maven 2 devrait être plus simple. En effet, les plugins Maven 2 essentiels sont devenus beaucoup plus stables et on trouve de plus en plus de plugins Maven 2 dans les différents projets et outils open source Java. Autre point important pour ceux qui développent sous Eclipse : le plugin (au sens d'Eclipse cette fois-ci !) m2eclipse s'est considérablement stabilisé et étoffé ces deux dernières années. Il peut être une aide pour comprendre comment fonctionne Maven 2.
Il m'a fallu de l'entrainement pour passer de Maven 1 à Maven 2 mais depuis que je l'ai fait, je n'ai plus du tout envie de revenir à Maven 1.
Pour les projets Java, c'est Maven 2, systématiquement.
Côté avantages, on peut noter l'existence de très nombreux plugins, dont l'utilisation se fait sans autre effort que de les configurer (cette configuration se limitant assez souvent à déclarer le plugin !) ; par ailleurs, il offre un cadre standardisé sans configuration (même si ce standard peut être critiqué), et permet ainsi de se retrouver très facilement dans les différents projets sans trop d'efforts.
Côté inconvénients, c'est le manque de souplesse. En effet, le lifecycle d'un projet est bien défini, et on ne peut que le paramétrer, pas le changer. Par ailleurs, pour des projets de petite taille, Maven peut sembler lourd.
Ensuite, j'utilise ant+ivy de temps à autre, mais sans accrocher : c'est flexible, certes, on fait ce qu'on veut, mais c'est encore plus verbeux qu'un pom bien factorisé. L'intégration avec ivy permet d'avoir une bonne gestion des dépendances, mais la configuration des classpaths est une horreur à mon goût.
Répondre avec citation
Partager