Voici mon retour après la lecture du livre Apache Maven.

Synthèse

Ce livre est bâti tout au long sur des exemples concrets issues de l'expérience terrain des deux auteurs (Nicolas De loof et Arnaud Héritier).
Il n'est pas une bible exhaustive de Maven. N'essayer donc pas de trouver dans ce livre le paramètre manquant pour configurer votre plugin. Néanmoins, tous les concepts de Maven et autour de Maven son présentés. En effet, chaque chapitre aborde toutes les problématiques que nous pouvons rencontrer à sa mise en place sur des projets. Et ce livre est vraiment constitué de chapitres d'une excellente qualité avec une approche très pragmatique des auteurs. Mon seul regret est que quelques concepts non pas été plus approfondis.

En résumé, si vous connaissez déjà Maven, ce livre vous permettra de conforter vos connaissances; et la démarche du livre vous servira surement lorsque vous voudrez expliquer Maven à votre entourage. Et si vous ne connaissez pas Maven, ce livre vous donnera une vision globale de Maven et vous permettra de connaître toutes les problématiques sous-jacentes à la mise en place de Maven dans les projets.

Quelques phrases clés qu'il faudra retenir:

• Maven est un fédérateur
• La philosophie de Maven est d'éviter que les développeurs passent de longues heures à mettre leur environnement au carré pour pouvoir coller aux attentes du projet
• Les conventions on été choisis pour refléter les bonnes pratiques et des règles simples d'organisation
• Quel que soient le projet Maven, la commande mvn install sera toujours le seul et unique point d'entrée pour construire le projet en intégrant toutes les étapes nécessaires
• Ne pas chercher à plier Maven à des besoins complexes mais plutôt essayer de comprendre comment traiter nos besoins selon la philosophie de Maven.

--> N'hésitez donc pas à acheter ce livre, vous devez l'avoir dans votre bibliothèque.

Les autres critiques

• Critique par Romain Linsolas sur Developpez.com
• Critique par Nicolas Giard sur NooCodeCommit
• Les critiques sur le site de Pearson

L'objectif de cet article de vous montrer comment déployer les artefacts produits par un projet dans un repository de type Maven2. Le repository contiendra les artefacts déployés et les méta données Maven générées. Cet article illustre le cas d'utilisation dont le projet est géré par le couple Ant/Ivy ou par Gradle.

Gradle est un système de build à base de plugins. Chaque plugin apporte un ensemble de conventions et le traitement nécessaire à l’exécution de la chaîne de build. En dehors des plugins Gradle core comme java, groovy, ant, maven, jetty, …, vous pouvez avoir le besoin de créer votre propre plugin.

Cette fonctionnalité n'est actuellement pas documentée, et une série de billets sur ce sujet va vous montrer pas à pas la création d'un plugin avec un cycle de vie.

Gradle est un système de build innovant dont les fonctionnalités ne cessent de croître. Ce billet présente en exclusivité la fonctionnalité d’import d’un script Ant depuis un script Gradle. Cette fonctionnalité n'est disponible pour le moment que dans la branche développement du SCM de Gradle.

TestNG est un framework de test basé sur Junit apportant plusieurs fonctionnalités comme

• Distribution sur plusieurs machines
• Modèle d’exécution avancé
• Configuration flexible

Ce billet montre un exemple de mise en œuvre du framework TestNG avec le builder Ant et le builder Gradle.

Quel que soit l’outil de build, il est souvent utile de pouvoir spécifier un traitement par défaut. Les outils Ant et Gradle ont deux approches différentes.

Ivy est outil de gestion de dépendances très utilisé et très flexible. Parmis ses fonctionnalités, nous allons illustrer son utilisation pour récupérer des artefacts dans un repository distant de type Maven. Dans l'exemple de ce billet, nous utiliserons Ivy avec le builder Ant.

Dans le cadre d'un repository distant de type Maven, il est très simple de récupérer l'artefact binaire avec ses dépendances transitives, grâce à la lecture par Ivy du descripteur Maven. Néanmoins, il est souvent méconnu de savoir comment récupérer depuis Ivy les artefacts des sources, les artefacts de la javadoc ou un artefact d'un type ou d'un classifier particulier.

Il vient de sortir une release majeure de Gradle.

Parmis les nouvelles fonctionnalités, Gradle fournit une nouvelle DSL beaucoup plus riche et plus user-friendly.

Dans le billet sur le concours du dévelopement d'une application Web en Wicket, une solution de l'application Zencontact avait été donnée. Cette solution utilise le système de construction Maven. Nombre d'entre vous ne savent pas très bien utiliser Maven, ou n'ont tout simplement pas envie d'installer la très lourde infrastructure Maven.

Maven est un outil de build très populaire et très utilisé. Néanmoins, il souffre de nombreuses lacunes. Il ne s’agit pas de la solution ultime; la preuve avec la naissance de nombreux autres outils de builds après Maven comme Gant, Gradle, Quokka, Kundo, EasyAnt, ...

La section suivante présente l'utilisation du builder Gradle sur l'application Web Wicket Zencontact.