septembre
2009
Un article de Baptiste Wicht
Cela fait maintenant environ un mois que j’ai commencé à regarder les possibilités de Maven 2 et à l’utiliser pour le build de mon projet JTheque. Au début, je pensais juste l’utiliser pour faire mes « publications » sur Sonar étant donné que je ne voulais pas passer du temps à migrer de Ant à Maven 2. Il faut également dire que je ne trouvais pas le concept très intéressant.
Mais petit à petit, je me suis rendu compte que Maven 2 était beaucoup plus intéressant que je ne le pensais et offrait des possibilités beaucoup plus élevées qu’Ant.
J’ai donc gentiment intégré petit à petit les possibilités de Maven 2 tout d’abord pour remplacer mes petits scripts Ant, ensuite dans mon système d’intégration continue puis maintenant pour ce qui est de la génération de site et du déploiement automatique d’artifacts.
Et je dois dire que je suis de plus en plus ravi par cet outil super complet. Il me permet de faire des builds beaucoup plus complets qu’Ant, me génère automatiquement des rapports et un site et me permet de déployer le tout directement sur mon serveur FTP sans aucun problème. C’est donc un gain de temps non négligeable. Bref que du bonheur.
Bien qu’il faille un certain temps d’adaptation et d’études pour appréhender correctement l’outil, une fois qu’on en a saisi la philosophie, il est assez facile d’avancer et d’intégrer petit à petit les immenses possibilités de Maven 2. Je suis d’ailleurs encore loin de toutes les connaître et les utiliser.
Néanmoins, il y a quand même quelques petits problèmes que j’ai pu constater. Premièrement, la prise en main n’est pas des plus facile. La philosophie est en effet tout à fait différente de ce que l’on trouve dans les système de build basé sur le script. Ensuite, la documentation n’est pas toujours des plus clairs, surtout en ce qui concerne les projets multi-modules. Et enfin, beaucoup de choses se répètent dans les POM de différents projets, mais pour ce point là, je l’avais déjà avec Ant.
Pour conclure, je dirais que Maven 2 est infiniment plus puissant et agréable à utiliser qu’Ant et bien qu’il faille un certain temps pour le prendre en main, n’est pas des plus difficiles à utiliser.
12 Commentaires + Ajouter un commentaire
Archives
- novembre 2011
- avril 2010
- mars 2010
- février 2010
- janvier 2010
- décembre 2009
- novembre 2009
- octobre 2009
- septembre 2009
- juillet 2009
- juin 2009
- avril 2009
- mars 2009
- février 2009
- octobre 2008
- septembre 2008
- mars 2008
- février 2008
- janvier 2008
- décembre 2007
- novembre 2007
- octobre 2007
- septembre 2007
- août 2007
- juillet 2007
- juin 2007
- mai 2007
- avril 2007
Catégories
- AMD
- Apple
- Cartes graphiques
- Chrome
- Conception
- Divers
- Eclipse
- English
- Hardware
- Informatique générale
- Intégration continue
- IntelliJ Idea
- Java
- JTheque
- Linux
- Logiciels
- Mes articles
- Mes critiques de livres
- Mes projets
- Microsoft
- Mon serveur perso
- Office 2007
- Open Source
- Outils
- Perso
- PHP
- Processeurs
- Programmation
- Sécurité
- Spring
- Windows Vista
- Windows XP
Effectivement, je vais essayer de faire avec l’activation avec valeur de property, ça devrait bien aller
En tout cas, merci à tous
Les profils peuvent être activés en fonction de certaines conditions, cf : http://www.sonatype.com/books/maven-book/reference/profiles-sect-activation.html. Tu devrais pouvoir y trouver ton bonheur
Ah effectivement, les profiles pourraient faire l’affaire.
En fait, ce que j’aimerais, c’est avoir 2 modèles : un modèle avec tests unitaires et un autre sans tests unitaires. Les rapports et les plugins étant différents d’un modèle à l’autre.
Tu penses que c’est possible si je crée 2 profiles dans le projet parent et en fonction de la présence d’une variable ou d’une autre, un profil ou l’autre est sélectionné ?
Salut,
Je me demande si tu pouvait utiliser le concept de profile pour centraliser l’exécution d’un tache dans le pom parent. le profile est ensuite activé en ligne de commande ou via la présence d’une variable.
http://www.sonatype.com/books/maven-book/reference/profiles.html
Et bientot le meilleur des mondes entres ant et maven http://www.gradle.org/! la souplesse de ant, les dépendances et le cycle de build de maven, le tout en scripting avec groovy
C’est ce qui est fait effectivement.
re
encore une fois, je ne génère rien concernant mes projets, du coup la génération de rapports je ne connais guère… Par contre, pour ton souci de projet n’ayant aucun code, quel packaging as tu mis ? Normalement on met « pom » pour ce type de projet parent (pom).
Merci Zedros, mais : J’ai déja un serveur d’intégration continue (TeamCity), je suis déja la qualité de mes projets avec Checkstyle depuis longtemps et maintenant avec Sonar (raison pour laquelle j’ai vu la lumière
) et pour ce qui est d’Eclipse, je ne l’utilise plus, je suis passé à IntelliJ Idea 
Par contre, l’idée de passer par un pom parent « modèle » est pas mauvaise, mais avec ça, je vais perdre la génération du breadcrumb et des liens vers le site parent dans la génération du site…
Oui, c’est surtout pour ce qui est des rappports pour le site que j’ai du code dupliqué. Mais j’ai également ce souci au niveau des plugins qui sont intégrés au niveau du build. Le projet parent n’a aucune source Java, donc pas de tests unitaires, d’analyse de qualité, de rapports, etc… mais tous les sous-projets ont à peu près le même style.
Erf, les liens ne passent pas…
Bref, les liens présents étaient :
– hudson : https://hudson.dev.java.net/
– checkstyle : http://maven.apache.org/plugins/maven-checkstyle-plugin/
– m2eclipse : http://m2eclipse.sonatype.org/
– codesmell : http://www.codesmell.org/blog
++
ah, tu as vu la lumière
lol
Maintenant tu peux aisément plugger hudson sur ton projet pour y faire de l’intégration continue. Tu peux aussi vérifier ton style (checkstyle) et le tout s’intègre fort joliment dans eclipse via m2eclipse. Et ça c’est qu’un début… Dans l’absolu d’ailleurs je serai curieux de la liste des plugins utilisés de ci de là (ma petite liste est tout sauf exhaustive).
Bien sûr, j’oublie plein d’autres choses comme vérifier les TODO/FIXME, compresser le code javascript présent, le tout via des plugins écrit soi même, qui sont très simples à réaliser.
NB : on a pas mal causé de maven sur le blog auquel je participe, codesmell, si jamais ça intéresse qq’un.
NB2 : pour ton souci de reports, tu parles de mvn site ? Je ne connais pas bien mais… pourquoi ne pas avoir deux pom, le premier avec ton projet parent, qui ne génére alors pas de report, et tous les autres héritant d’un projet intermédiaire, ajoutant la génération des reports ? Maintenant, je dis ça « ex nihilo », sans trop avoir de contexte sur ton souci pour éventuellement aider.
Pour ce qui est de l’héritage, j’ai commencé à l’utiliser, mais ça ne répond pas à tout…
Tu peux utiliser pluginManagement pour ne configurer qu’une seule fois les plugins, ça c’est cool, ça marche très bien
Par contre, comment tu veux dire que les x sous-projets d’un projet doivent générer tous les mêmes rapports quand le projet parent ne doit pas générer ces rapports.
C’est ça que j’aimerais trouver en fait. Une sorte de template de reports et de plugin de build à activer quand le projet parent ne déclare aucun report ou build…
Peut être que ça existe, mais j’ai pas encore trouvé pour le moment.
Avec Ant, c’est pareil, tu peux éviter des répétitions en faisant des imports, des tâches, …
Je n’ai jamais réussi à franchir le pas sur Maven …
Pour « beaucoup de choses se répètent dans les POM de différents projets », il faut utiliser l’héritage en faisant un pom parent, voire http://www.sonatype.com/books/maven-book/reference/multimodule-sect-simple-parent.html#ex-multimodule-parent-pom.