Maven

Tout le monde se secoue !

J'ai commencé (samedi 23 janvier 2016 à 19h03) la rédaction d'un tutoriel au doux nom de « Maven » et j'ai dans l'objectif de proposer en validation un texte aux petits oignons. Je fais donc appel à votre bonté sans limite pour dénicher le moindre pépin, que ce soit à propos du fond ou de la forme. Vous pourrez consulter la bêta à votre guise à l'adresse suivante :

Merci !

J'aime pas le titre et le sous-titre.

Ensuite, c'est embêtant car tu ne présentes maven que comme un package manager alors que c'est un outil de build avancé. Dans sa philosophie maven implémente un vrai workflow, notamment avec la différenciation snapshot/release.

Maven permet de faire tourner plein de choses aussi. Je me souviens avoir mis en place des findbugs and co avec ça justement pour améliorer la qualité du code. Et globalement tu oublies les tests unitaires qui sont intégrés à maven.

Y'a encore des gens qui utilisent éclipse à l'heure d'IntelliJ?

Le cours est une introduction à Maven pour les débutants qui souhaitent utiliser cet outil professionnel.

En effet, Maven propose beaucoup de choses, des concepts qui lui sont parfois particulier, pour ce qui est des findbugs un tutoriel complet pourrait être dédié à Sonar. Je ne pense pas avoir oublié de parler des tests unitaires, j'en fais référence avec la non-régression.

Oui il y a encore beaucoup de gens qui utilisent Eclipse, la version community d'IntelliJ n'est pas adapté pour Java EE.

Le cours est une introduction à Maven pour les débutants qui souhaitent utiliser cet outil professionnel.

Du coup ton cours n'apporte qu'une seule chose par rapport à un "create maven project" sur netbeans/eclipse/intelliJ : la soumission au maven repository.

En effet, avec ce que tu nous donnes finalement, l'archi aurait pu être différente que ça ne changerait rien pour le développeur lambda.

Ensuite parler de maven comme outil professionnel sans parler des workflow c'est ultra dommage.

Et justement dire "passer de débutant à pro" c'est pas forcément le truc qui motive. Surtout si maven n'est présenté que comme un package manager. Un débutant qui fait des projets perso et sans visée pro pourra tout à fait être heureux avec un maven. C'est même conseillé.

J'approuve fortement les dires d'Artragis. J'utilise Maven mais sans me considérer comme un professionnel, et je considère également que le limiter à cet usage est très dommage, vu tous les avantages qu'il apporte. Et là c'est presque plus une question de présentation de l'outil que de contenu. Ce sans compter le fait que Maven est bien plus qu'un gestionnaire de dépendances (workflow, tests unitaires, etc.), car ça a déjà été rappelé (mais ça reste vrai).

Sinon, tu conseilles d'installer, sous Linux, Maven via une archive téléchargée sur le site, on préférerais plutôt passer par le gestionnaire de paquets.

Aussi, il est dommage de pré-supposer que le lecteur ne sait rien : je ne dis pas ça en sous-entendant qu'il ne faut pas expliquer le concept, certainement pas, mais ce genre de phrase me gêne un peu, par exemple. Elle gagnerait à être légèrement formulée, en posant par exemple en condition le fait que le lecteur ne connaît rien¹.

Notez que lors de la création du projet la console va vous poser des questions, comme vous ne connaissez pas suffisamment assez Maven appuyez juste sur la touche Entrée pour prendre les valeurs par défaut.

Il n'est fait aucune mention des dépôts Maven externes : il n'y a pas que Maven Central, et nombre de projets ne sont disponible que via d'autres dépôts. Ceci inclut donc la section repositories du pom.xml.

L'aperçu de Maven est finalement très introductif, le cours gagnerait à être approfondi, en parlant de ce que j'ai mentionné plus haut, de ce qu'Artragis a dit, de l'exécution des tests unitaire (en parler, pas juste le mentionner), de la gestion des dépendances sans les inclure dans le JAR éventuellement (si applicable à l'environnement), du shading…

de l'exécution des tests unitaire

à mon avis faut pas se focaliser là-dessus.

Faut présenter les phases et les goals pourquoi plus les tests unitaires que les tests d'intégration ?

Après, je serais aussi d'avis d'y aller molo. Il manque le build lifecycle dans le tutoriel, vous avez raison. Mais je n'irais pas plus loin, et surtout je ne parlerais pas des plugins.

Maven c'est bien c'est rigolo, au début on s'en sert pour tout et n'importe quoi (genre ça) et quand on a repris en maintenance des projets maven qui build du JS qui build du python qui build du Java qui crée un site qui fait appel à un autre plugin qui check la couverture de code du plugin lui-même etc. c'est un sac de noeuds. Et je suis complètement contre présenter ça à un débutant. Il faut utiliser pour ce qu'il sait bien faire : construire un projet Java de façon plus ou moins incrémentale).

Et si je rentrais dans le jeu du troll, je serais tenté de dire "Y'a encore des gens qui utilisent Maven en tant que gestionnaire de dépendance à l'heure de Ivy ?" ou "Y'a encore des gens qui font des décrivent leur build en… … XML ??? en 2016 :\ ". Mais bref.

S'il s'agit de présenter un usine à gaz, autant y aller molo :|

Et si je rentrais dans le jeu du troll, je serais tenté de dire "Y'a encore des gens qui utilisent Maven en tant que gestionnaire de dépendance à l'heure de Ivy ?" ou "Y'a encore des gens qui font des décrivent leur build en… … XML ??? en 2016 :\ ". Mais bref.

Comme je te l'ai dit ma question était honnête, j'avais vraiment l'impression que non seulement le développement d'éclipse était mort et que de plus en plus de monde le fuyait ou souhaitait ne plus l'utiliser (un peu comme VB6, c'est encore utilisé mais tout le monde veut en sortir).

En effet, avec ce que tu nous donnes finalement, l'archi aurait pu être différente que ça ne changerait rien pour le développeur lambda.

Je présente l'architecture, /main/java pour le code du projet, /test/java pour les tests unitaire, /resources pour les fichiers statiques, /webapp pour les fichiers webs. C'est tout de même différent d'une architecture Dynamic Web Project d'Eclipse ou autre.

Sinon, tu conseilles d'installer, sous Linux, Maven via une archive téléchargée sur le site, on préférerais plutôt passer par le gestionnaire de paquets.

Je propose un moyen d'installer la même version que pour ceux qui sont sous Windows, utiliser le gestionnaire de paquets n'est pas bien compliqué (sudo apt-get install maven), mais cet utilitaire ne propose pas forcément la version de l'outil que toi tu souhaites installer sur ta machine.

Il n'est fait aucune mention des dépôts Maven externes : il n'y a pas que Maven Central, et nombre de projets ne sont disponible que via d'autres dépôts. Ceci inclut donc la section repositories du pom.xml.

Je veux bien mais je ne connais pas de projet aussi simple que jsoup, n'hésite pas à me proposer un projet simple faisant parti d'un dépôt externe.

de l'exécution des tests unitaire (en parler, pas juste le mentionner)

Le souci c'est que cela nécessite la création d'un exemple de test unitaire (et du code supplémentaire qui va avec, avec un risque d'alourdir le tutoriel), le concept de test unitaire est très compliqué pour un débutant, si je me met à lui montrer du JUnit/Mockito il n'en comprendra pas forcément le sens et l'intérêt.

Il manque le build lifecycle dans le tutoriel, vous avez raison. Mais je n'irais pas plus loin, et surtout je ne parlerais pas des plugins.

Je présente déjà clean et package, je pourrais aussi présenter les autres phases comme validate, compile, verify, install sans perdre le lecteur. Je pourrais aussi faire mention de test en disant que cela va lancer le code des tests unitaires présents dans /test/java, de deploy pour dire que cela va mettre le package vers un repo distant (et non local comme install), ou integration-test pour que le projet soit testé dans un environnement d'intégration (je tiens à préciser entre nous que je n'ai jamais eu à utiliser integration-test et que je préfère ne pas parler de chose que je n'ai jamais mis en oeuvre dans la réalité).

PS: Parler des goals n'est pas prévu.

Merci pour vos retours

Salut,

Voici mes retours sur ton tutoriel :

Maven est parfois qualifié de « Dependency Management Tool »

Si tu dis ça, il faudrait un peu étoffer. Là, tu le mentionnes mais tu n'expliques rien.

Maven permet de mieux structurer son projet Java

"Mieux", je ne sais pas. En tout cas, il propose une structure commune à tous les projets Maven standards (tu peux changer les emplacements de quasi tout si tu le spécifies explicitement).

L’ensemble du projet est géré à partir d’un seul fichier : le pom.xml

D'un ou plusieurs pom.xml.

Un développeur qui connaît Maven aura beaucoup plus de facilité à s’intégrer au contenu de votre projet.

Oui, c'est vrai mais pourquoi le mentionner comme ça sans aucun contexte dans une balise information ?

ces JAR sont appelés des « dépendances » car nous avons besoin de les inclure dans nos projets

Si on voulait être précis, nous avons besoin de les inclure dans le classpath de notre projet. Les inclure dans nos projets n'a pas vraiment de sens.

Maven va télécharger ces JAR à partir du repository Maven pour nous

Repository Maven = Maven Central ? Faudrait utiliser Maven Central alors parce que des dépôts Maven, il en existe des tas.

Maven va compiler le projet Java en se servant du compilateur officiel Java (javac) et lancer les tests pour vérifier la non-régression du projet, le tout sans qu’on ait à se casser la tête avec des commandes complexes ou des problèmes liés aux packages (sacré packages !).

Oui, c'est vrai mais pourquoi dire ça dans les avantages de Maven alors que tu ne parlais pas de ça avant ? Puis, tu dis qu'on se casse plus la tête avec des commandes complexes (c'était quoi ces commandes ?) mais tu ne donnes pas la commande Maven.

Pardonnez-moi frères Linuxiens, je tourne sous Windows en ce moment …

Tu peux généraliser Linuxiens à Unixiens.

-DgroupId=zestedesavoir.gokanekinci d'indiquer votre compagnie ou nom ou pseudo, et -DartifactId=identifiant-de-mon-projet l'identifiant de votre application

Ces dommages de limiter tes explications à seulement ça. Il y aurait un peu plus à dire quand même.

Le contenu de la balise secret ci-dessous présente des chemins pour que vous puissiez ajouter des fichiers statiques (.png, .pdf) dans un dossier resources, ou bien des fichiers web (.jsp, .html) dans un dossier webapp si le projet est de type Java EE

Tu ne parles jamais d'un type de projet avant.

Pour créer des JAR exécutable avec Maven, il faut ajouter le bloc XML suivant au pom.xml en précisant le nom de la classe contenant la méthode main() :

Même si c'est prématuré de rentrer dans les détails de ce qu'est un plugin, cela aurait été bien d'avoir 2-3 explications parce que là c'est léger, on ne peut que te croire sur parole.

Un nouveau dossier /target vient d'être créé à côté de /src.

J'aurais mentionné que tout ce qui se trouve dans le dossier target est temporaire et qu'un clean du projet supprime son contenu purement et simplement.

Le souci c'est que maintenant que notre projet doit gérer des dépendances, il faut mettre à jour le <build> de notre pom.xml, ne vous en faite pas, voici le pom.xml complet :

Encore une fois, aucune explication et en plus, tu places du contenu nécessaire dans une balise secret. Le lecteur pourrait louper l'information.

Pour le reste, hormis des soucis dans la ponctuation, c'est pas trop mal.

Si tu dis ça, il faudrait un peu étoffer. Là, tu le mentionnes mais tu n'expliques rien.

J'étoffe dans la partie "présentation des qualités de Maven". Le souci c'est que si je met à présenter cela dans l'intro, je devrais préciser ce qu'est une dépendance dès l'intro.

D'un ou plusieurs pom.xml.

Je l'ai toujours vu ainsi : 1 projet => 1 artifactId => 1 pom.xml. Si tu fais référence aux projets multi modules, là aussi tu as 1 pom.xml par projet même si tu fais référence à un projet parent.

Oui, c'est vrai mais pourquoi le mentionner comme ça sans aucun contexte dans une balise information ?

Pour inciter le lecteur à utiliser Maven. C'est comme dans les cours sur les frameworks.

Repository Maven = Maven Central ? Faudrait utiliser Maven Central alors parce que des dépôts Maven, il en existe des tas.

Par défaut oui. Des dépôts il peut y en avoir un tas, mais celui qui va intéresser les gens c'est celui de leur entreprise (ex: Nexus) et repository central. Si toi ou ArmauryPi me donnez un exemple de projet simple (comme jsoup) pour faire une démo de repository externe ce sera peut-être plus clair dans le tuto. Je parlerais aussi de <distributionManagement> pour la partie sur la phase deploy.

Tu ne parles jamais d'un type de projet avant.

C'est parce que je considère qu'un projet Java de base est Java SE. Je devrais peut-être ajouter une précision dans la colonne packaging pour war => Java EE.

Oui, c'est vrai mais pourquoi dire ça dans les avantages de Maven alors que tu ne parlais pas de ça avant ? Puis, tu dis qu'on se casse plus la tête avec des commandes complexes (c'était quoi ces commandes ?) mais tu ne donnes pas la commande Maven.

Je prend en note, je vais donner une première commande Maven dans cette partie pour expliquer l'avantage, d'ailleurs je vous met l'exemple tout de suite :

J'aurais mentionné que tout ce qui se trouve dans le dossier target est temporaire et qu'un clean du projet supprime son contenu purement et simplement.

Dans le tuto j'ai mis : "mvn clean package Cette commande aura pour effet de nettoyer votre projet […]". Je pensais que c'était clair, vous pensez que je devrais préciser que cette commande supprime physiquement le dossier /target ?

Encore une fois, aucune explication et en plus, tu places du contenu nécessaire dans une balise secret. Le lecteur pourrait louper l'information.

D'accord, je vais essayer de donner une explication concernant le fait que dans notre cas il faut inclure les dépendances dans le JAR exécutable pour que le programme fonctionne. Il y a des cas où on est obligé de mettre du code dans des balises secrètes car l'information devient trop redondante, dans mon cas j'utilise ces balises pour faciliter le lecteur à voir une vue d'ensemble et faire un copier/coller global. Pour ce qui est de "louper" la balise secrète je ne peux pas faire grand chose.

Merci pour vos retours, n'hésitez pas à préciser où sont les erreurs de ponctuation

EDIT:

Tu ne parles jamais d'un type de projet avant.

C'est parce que je considère qu'un projet Java de base est Java SE. Je devrais peut-être ajouter une précision dans la colonne packaging pour war => Java EE.

Je viens de remarquer que j'en parle déjà. Dans la partie Création d’un premier projet Maven la ligne du tableau avec <packaging> présente les types de projet. Dans la partie suivante Analyse d’une architecture Maven je précise bien :

webapp si le projet est de type Java EE (cf: packaging war)

Bonsoir,

J'ai pris en compte vos suggestions et j'ai amélioré le tutoriel existant en ajoutant bien sur une nouvelle partie "Build Lifecyle".

=> Lien du tutoriel en cours de validation

Cordialement,

Bonjour les agrumes !

La bêta de votre tutoriel « Maven » a été mise à jour et coule sa pulpe à l'adresse suivante :

Merci d'avance pour vos commentaires.

Ce n'est pas moi qui validerai ton tuto par manque de temps, mais tu pars sur une bonne base là

Bonjour les agrumes !

La bêta de votre tutoriel « Maven » a été mise à jour et coule sa pulpe à l'adresse suivante :

Merci d'avance pour vos commentaires.

UPDATE : Je vais peut-être demander à quelqu'un du forum pour la validation… SpaceFox peut-être ? C'est un expert Java.

Je peux faire une première relecture si tu veux. On s'en sert au boulot pour le build, le packaging et le déploiement de tout notre socle applicatif: WebApp, appli Java "standard" et même la base de données via flyway.

Certes, je ne pense pas être expert dessus mais je l'utilise assez pour avoir un premier avis.

PS: ça me changera des Fragment d'Andr0.

Je te remercie Fumble, ce serait vraiment très gentil de ta part

PS: J'ai envoyé un mail à SpaceFox pour la validation, il m'a dit qu'il le ferait s'il aurait le temps.