Le document traite de l'intégration continue avec Maven, en mettant en évidence son importance dans la réduction des coûts liés aux bugs et en optimisant le processus de développement. Il aborde les bonnes pratiques et les outils nécessaires pour implémenter efficacement cette méthodologie, ainsi que des rappels sur l'historique et les concepts fondamentaux de Maven. Enfin, il présente des stratégies et des recommandations pour mener à bien l'intégration continue dans un environnement de développement.

1. Soirée Technique : L’intégration continue avec Maven 2 Présentation So@t License Creative Commons 2.0 – Share Alike Retour d’expérience sur la mise en œuvre de Maven dans un processus d’intégration continue

2. Agenda Rappels sur l’intégration continue Enjeux de l’intégration continue Outils pour sa mise en œuvre Rappels sur Maven 2 Un peu d’histoire… Notions Dans la vrai vie… Exemple de mise en œuvre Bonnes pratiques Maven Présentation So@t License Creative Commons 2.0 – Share Alike

3. Présentation So@t License Creative Commons 2.0 – Share Alike Rappels sur l’intégration continue

4. Rappels sur l’intégration continue Présentation So@t License Creative Commons 2.0 – Share Alike Enjeux de l’intégration continue

5. Rappels sur l’intégration continue Enjeux de l’intégration continue Présentation So@t License Creative Commons 2.0 – Share Alike Source: http://www.agitar.com/solutions/why_unit_testing.html Les 5% de bugs découverts après la release représentent 95% des coûts de correction

6. Rappels sur l’intégration continue Enjeux de l’intégration continue Point cruciaux : Traçabilité de la vie du projet Reproductivité de l’environnement de compilation Reproductivité de l’environnement technique Présentation So@t License Creative Commons 2.0 – Share Alike Socle technique Environnement de build Intégration continue

7. Intégration continue ? Processus d'automatisation des tâches récurrentes (construction, déploiement, exécutions des tests unitaires et d'intégration, ...) Intérêt de l’intégration continue ? Sa fréquence d'exécution! Mise à disposition régulière de nouvelles versions d'une application => Meilleure visibilité! Rappels sur l’intégration continue Enjeux de l’intégration continue Présentation So@t License Creative Commons 2.0 – Share Alike

8. Rappels sur l’intégration continue Enjeux de l’intégration continue Présentation So@t License Creative Commons 2.0 – Share Alike Spécifications Développement, correction d’une fonctionnalité Implémentation de la fonctionnalité ou correction et des tests unitaires Compilation privée du module ou projet Enregistrement dans le SCM 1 Détection du besoin d’intégration Evènements envoyés par le SCM Scrutation du SCM Périodique, manuelle 2 Intégration Mise à jour depuis le SCM Compilation du projet Tests unitaires et d’intégration Analyses de la qualité de code 3 Historisation et publication des résultats Enregistrement des résultats Génération des rapports Notifications des résultats Publication de l’artéfact 4

9. Ne se résume pas seulement à la simple mise en œuvre d'un outil permettant d'automatiser la compilation! C’est un processus qui va orchestrer le quotidien des développeurs autours de : Un outil de construction automatisée (Ant, Maven, …), Un unique système de gestion de sources (SVN, CVS, GIT, …), Un serveur d'intégration continue (Hudson, Bamboo, Cruise Control, …) Rappels sur l’intégration continue Enjeux de l’intégration continue Présentation So@t License Creative Commons 2.0 – Share Alike

10. Rappels sur l’intégration continue Enjeux de l’intégration continue L’intégration est une activité complexe… L’effort augmente significativement avec : le nombre d’artéfacts, les tests d’intégration…et leurs définitions, le nombre d’erreurs, la qualité du code, … le temps écoulé depuis la dernière intégration. Présentation So@t License Creative Commons 2.0 – Share Alike

11. Rappels sur l’intégration continue Enjeux de l’intégration continue L’intégration continue est apparue avec les pratiques XP avec comme motivation de remplacer les grosses et longues phases d’intégration en fin de projet par des phases plus petites et plus fréquentes L’idée principale : Réduire au minimum l’effort d’intégration de l’application sans altérer le processus de développement logiciel Présentation So@t License Creative Commons 2.0 – Share Alike

12. Rappels sur l’intégration continue Enjeux de l’intégration continue Présentation So@t License Creative Commons 2.0 – Share Alike Les builds sur les postes p0, p1, pi, pic… doivent être identiques Ex : il faut pouvoir reproduire le build sur l’ensemble des postes de l’équipe mais aussi sur le serveur d’intégration continu Les builds aux temps t0, t1, ti, … doivent être identiques Ex : il faut pouvoir à tout moment reproduire le build d’une version taggée dans l’espace p0 p1 pj pic dans le temps t1 ti t0

13. Rappels sur l’intégration continue Enjeux de l’intégration continue Le build est une opération qui paraît simple, mais dans les faits c’est une problématique compliquée et nous ne disposons toujours pas de solution qui permette d’assurer cela… Présentation So@t License Creative Commons 2.0 – Share Alike

14. Rappels sur l’intégration continue Présentation So@t License Creative Commons 2.0 – Share Alike Et dans la pratique ?

15. Rappels sur l’intégration continue Et dans la pratique ? Utiliser un outils de build Utiliser un SCM Utiliser un framework de tests unitaires Utiliser un serveur d’intégration continue Utiliser un framework de tests fonctionnels Utiliser un outils de suivi de faits techniques (DM ou RA) … Connaître son processus (du développement à la phase de livraison…) … S’aider de l’existant et communiquer … Apporter la culture Présentation So@t License Creative Commons 2.0 – Share Alike

16. Rappels sur l’intégration continue Et dans la pratique ? - Outils (1/2) Outils de build Ant Maven SCM SVN CVS ClearCase GIT Serveur d’intégration continue Hudson Continuum Bamboo TeamCity CruiseControl Présentation So@t License Creative Commons 2.0 – Share Alike

17. Rappels sur l’intégration continue Et dans la pratique ? - Outils (2/2) Framework de tests unitaires Junit TestNG Mockito Framework de tests fonctionnels Fitness Selenium + Tellurium Outils de suivi de faits techniques Jira Communiquer… intelligemment… Wiki Présentation So@t License Creative Commons 2.0 – Share Alike

18. Rappels sur l’intégration continue Et dans la pratique ? – En quelques mots… Présentation So@t License Creative Commons 2.0 – Share Alike Accueil d’un nouveau développeur Enregistrement des modifications Compilation, tests Analyses de code Détection du besoin d’intégration Chargement de modifications Production de code Outil de compilation Intégration continue Gestion de configuration Gestion de dépendances Compilations privées pom.xml

19. Rappels sur l’intégration continue Et dans la pratique ? – Pratiques et anti-pattern (1/3) Détecter et résoudre les problèmes au plus tôt Commiter du code qui marche fréquemment Exécuter des builds privés Développer de petites tâches Commenter chaque commit Valider le build par des tests (unitaires et fonctionnels) qui passent à 100% Pas de test = pas d’erreur, les tests doivent être pertinents Prendre en compte la couverture de test Intégrer après chaque commit Temps de build < 10 min Distinguer les tests unitaires des tests d’intégration, fonctionnels, etc. Exécuter une intégration complète au moins une fois par jour Corriger les échecs de builds immédiatement ! Stopper les commits ! Adapter le système de notification à l’équipe Présentation So@t License Creative Commons 2.0 – Share Alike

20. Rappels sur l’intégration continue Et dans la pratique ? – Pratiques et anti-pattern (2/3) Reproduire le build dans le temps et l’espace Le build doit être automatisé au maximum L’environnement de build doit être propre Privilégier le checkout, au moins pour l’intégration complète quotidienne Nettoyer le dépôt local de Maven Selon les cas, intégrer sur différentes plateformes Dans certains l’utilisation d’un miroir du SCM peut-être utile Anti-patterns : Absence de référentiel de sources Intégration sur le poste de développement Utilisation de scripts de build différents entre le développement et l’intégration Présentation So@t License Creative Commons 2.0 – Share Alike

21. Rappels sur l’intégration continue Et dans la pratique ? – Pratiques et anti-pattern (3/3) L’amélioration de la qualité de code L’analyse de code est à mettre en place dès le début du projet Se fixer des objectifs raisonnables Automatiser les tâches de relecture Anti-patterns : Les objectifs trop ambitieux peuvent décourager Sélectionner les règles Prévoir du temps dédier à l’amélioration de la qualité de code Sentiment de flicage : les métriques ne sont pas une note En réfléchissant un peu, il est très simple de contourner les outils d’analyse… Excès de confiance De bonnes métriques n’impliquent pas que l’application ne comporte pas de bogues, ou que de mauvaises pratiques n’ont pas été implémentées Présentation So@t License Creative Commons 2.0 – Share Alike

22. Rappel sur l’intégration continue Et dans la pratique ? - Demo Demo : Serveur d’intégration continu (Hudson) Outil de qualité de code (Sonar) Présentation So@t License Creative Commons 2.0 – Share Alike

23. Présentation So@t License Creative Commons 2.0 – Share Alike Rappels sur Maven 2

24. Rappels sur Maven 2 Présentation So@t License Creative Commons 2.0 – Share Alike Un peu d’histoire…

25. Rappels sur Maven 2 Un peu d’histoire… Mot Yiddish signifiant accumulator of knowledge Né en aout 2001 avec le projet Alexandria puis utilisé pour simplifier le développement du projet Turbine (jakarta) – Framework de présentation de portail utilisé par Jetspeed 1 Constat : De nombreux projets hétérogènes (ant différents, structure fichiers, …) Une gestion des dépendances difficiles (librairies dans le SCM) Présentation So@t License Creative Commons 2.0 – Share Alike

26. Rappels sur Maven 2 Un peu d’histoire… Volontés : Avoir une manière standardisée de builder Avoir une description du projet Avoir une manière simple d’éditer les informations du projet Avoir une manière simple de partager les librairies entre les différents projets Ne plus stocker les librairies dans le SCM Présentation So@t License Creative Commons 2.0 – Share Alike

27. Rappels sur Maven 2 Un peu d’histoire… Maven est un Project Management Framework Il permet de : Rendre le processus de build simple Uniformiser le processus de build Fournir des informations de projet de qualité Fournir des directives pour les best practices development Migrer de manière transparente à de nouvelles fonctionnalités Présentation So@t License Creative Commons 2.0 – Share Alike

28. Rappel sur Maven 2 Présentation So@t License Creative Commons 2.0 – Share Alike Notions

29. Rappels sur Maven 2 Notions Utilise la notion de projet où existent : Un ensemble de fichiers contenant du code [Des fichiers de configuration] [Des licenses] Des développeurs impliqués associés à leurs rôles sur le projet Les dépendances Les ressources (images, …) Convention Over Configuration Présentation So@t License Creative Commons 2.0 – Share Alike

30. Rappel sur Maven 2 Notions - POM POM – Project Object Model = fichier descripteur décrivant le projet Hérite du super-pom Permet de normaliser Présentation So@t License Creative Commons 2.0 – Share Alike

31. Rappel sur Maven 2 Notions - POM Contient : groupId (ex : fr.soat.sample) artifactId (ex : mon-premier-module) packaging (ex : jar) version name url description dependency plugin build Présentation So@t License Creative Commons 2.0 – Share Alike

32. Rappel sur Maven 2 Notions – Structure d’un projet ex : Présentation So@t License Creative Commons 2.0 – Share Alike =>

33. Rappel sur Maven 2 Notions – Structure d’un projet ex 2 : Présentation So@t License Creative Commons 2.0 – Share Alike =>

34. Rappel sur Maven 2 Notions – Gestion des dépendances Gère les dépendances du projet Gère les dépendances transitives entre projet ex : A (sample-war.war) dépend de B (sample-jar.jar) B (sample-jar.jar) dépend de C (log4j.jar) Présentation So@t License Creative Commons 2.0 – Share Alike = + <groupId>fr.soat.sample.metier</groupId> <artifactId>jar-sample</artifactId> <version>0.0.1-SNAPSHOT</version> <name>jar-sample</name> <dependencies> <dependency> <groupId>log4j</groupId> <artifactId>log4j</artifactId> <version>1.2.14</version> </dependency> </dependencies> <groupId>fr.soat.sample</groupId> <artifactId>war-sample</artifactId> <version>0.0.1-SNAPSHOT</version> <packaging>war</packaging> <name>war-sample</name> <dependencies> <dependency> <groupId>fr.soat.sample.metier</groupId> <artifactId>jar-sample</artifactId> <version>0.0.1-SNAPSHOT</version> </dependency> </dependencies>

35. Rappel sur Maven 2 Notions – Gestion de la visibilité Existe 6 types de visibilité : Compile : (par défaut) disponible dans toutes les phases Runtime : les dépendances de portées runtime ne sont pas nécessaires pour la compilation, uniquement pour l'exécution (ex : drivers JDBC) Provided : utilisée pour compiler l'application, mais non déployée (ex : librairies présentes dans le classpath d’un serveur d’application) Test : uniquement nécessaires pour compiler et exécuter les tests (par exemple Junit) System : similaire au scope Provided mais où le jar est spécifié explicitement (ie. Son chemin dans le système de fichiers) Import : utilisé uniquement dans le cas d’une dépendance de type pom ans la section <dependencyManagement> Présentation So@t License Creative Commons 2.0 – Share Alike

36. Rappel sur Maven 2 Notions – Gestion de la visibilité ex : Présentation So@t License Creative Commons 2.0 – Share Alike <groupId>fr.soat.sample</groupId> <artifactId>war-sample</artifactId> <version>0.0.1-SNAPSHOT</version> <packaging>war</packaging> <name>war-sample</name> <dependencies> <dependency> <groupId>fr.soat.sample.metier</groupId> <artifactId>jar-sample</artifactId> <version>0.0.1-SNAPSHOT</version> </dependency> <dependency> <groupId>javax.servlet</groupId> <artifactId>servlet-api</artifactId> <version>2.5</version> <scope>provided</scope> </dependency> </dependencies>

37. Rappel sur Maven 2 Notions – Modules et Héritage Permet de gérer des modules (référence à un autre projet maven, c’est à dire une référence à un autre POM) Permet de gérer des héritages (référence à un projet père pour bénéficier des caractéristique de son POM) Présentation So@t License Creative Commons 2.0 – Share Alike <groupId>fr.soat.sample</groupId> <artifactId>project-sample</artifactId> <version>0.0.1-SNAPSHOT</version> <packaging>pom</packaging> … <modules> <module>jar-sample</module> <module>war-sample</module> </modules> <artifactId>war-sample</artifactId> <packaging>war</packaging> <name>war-sample</name> <parent> <groupId>fr.soat.sample</groupId> <artifactId>project-sample</artifactId> <version>0.0.1-SNAPSHOT</version> </parent> <artifactId>jar-sample</artifactId> <name>jar-sample</name> <parent> <groupId>fr.soat.sample</groupId> <artifactId>project-sample</artifactId> <version>0.0.1-SNAPSHOT</version> </parent>

38. Rappel sur Maven 2 Notions – Repository Repository global : Un/des repositories globaux (ex : http://repo1.maven.org/maven2/ ) contiennent les dépendances officielles et sont utilisés pour construire (par téléchargement) le repository local Repository local : (par défaut $HOME/.m2/repository) contient des dépendances officielles et courantes et est utilisé par les projets pour chercher les dépendances. Si elles ne sont pas trouvées dans le repository local, elles sont automatiquement téléchargées à partir du/des repositories globaux Présentation So@t License Creative Commons 2.0 – Share Alike

39. Rappel sur Maven 2 Notions – Repository Structure des repositories : Présentation So@t License Creative Commons 2.0 – Share Alike

40. Rappel sur Maven 2 Notions – Cycle de vie Consiste en une série de phases où chaque phase peut réaliser une ou plusieurs actions (ou goals) liée à la phase (ex : la phase de compilation invoque un ensemble de goal de compilation) Possibilité d’invoquer un goal directement ex : mvn release:prepare Présentation So@t License Creative Commons 2.0 – Share Alike <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-antrun-plugin</artifactId> <executions> <execution> <id>stop-tomcat</id> <phase>generate-test-sources</phase> <goals> <goal>run</goal> </goals> <configuration> <tasks> <exec dir= &quot;/home/dev/sps-tomcat/bin&quot; executable=&quot;sh&quot;> <arg line= &quot;shutdown.sh&quot; /> </exec> </tasks> </configuration> </execution> </executions> </plugin>

41. Rappel sur Maven 2 Notions – Profils Possibilité de définir ses profils (ex : dev, initdb, dev-bdd) : Permet de se dé-corréler d’une couche non utile aux développements courants (allégement de la compilation, tests propres au développement courant, ...) Permet de tester par rapport à son environnement ex : mvn install -Pdev Présentation So@t License Creative Commons 2.0 – Share Alike

42. Rappel sur Maven 2 Notions – Configuration ${MAVEN_HOME}/conf settings.xml Proxy internet, Path du repository local, Mirroirs, Profils, … ${HOME}/.m2 settings.xml Mirroirs, Profils, Droits Présentation So@t License Creative Commons 2.0 – Share Alike

43. Rappel sur Maven 2 Présentation So@t License Creative Commons 2.0 – Share Alike Dans la vraie vie…

44. Rappel sur Maven 2 Dans la vraie vie… Demo : Repo proxy (Nexus) Plugins maven Intégration eclipse (m2eclipse) Présentation So@t License Creative Commons 2.0 – Share Alike

45. Présentation So@t License Creative Commons 2.0 – Share Alike Exemple de mise en œuvre

46. Exemple de mise en œuvre Contexte (1/2) But : mise en place d’outils pour automatiser l’exécution de tests fonctionnels Etat des lieux : Contient : 4 webapps Jetspeed 2 portlets Webservices 1 bdd postgreSQL SCM = SVN Procédure de livrable : L’équipe de production récupérait les sources sur le serveur cible et exécutait les commandes : mvn jetspeed:mvn –Pdeploy Copiait le war des webservices 17 TUs… Présentation So@t License Creative Commons 2.0 – Share Alike

47. Exemple de mise en œuvre Contexte (2/2) Outils : IntelliJ, Eclipse, Netbeans TeamCity : mvn clean install Artifactory SVN Maven 2 mais peu de connaissances (2-3 personnes sur 10) Procédure de déploiement sur le poste du développeur mvn jetspeed:mvn –Pdeploy (bdd, déploiement, …) Présentation So@t License Creative Commons 2.0 – Share Alike

48. Exemple de mise en œuvre Plan d’action – Maitriser le build Maitriser le build Générer des wars déployables via un mvn install (ie. s’abstraire du processus Jetspeed (au moins en parti) Générer un livrable : utilisation du plugin Assembly et externalisation des fichiers de configuration hors des war/jar Mettre en place les bonnes pratiques Maven SNAPSHOT Profile Scope/classifier Alléger les POM des informations inutiles Définir un projet parent contenant toutes les informations Présentation So@t License Creative Commons 2.0 – Share Alike

49. Exemple de mise en œuvre Plan d’action – Accélérer le développement Utilisation de JRebel sur le poste des développeurs Présentation So@t License Creative Commons 2.0 – Share Alike

50. Exemple de mise en œuvre Plan d’action – le processus de développement Mettre en place un environnement dont les données sont maitrisées sur lesquels un déploiement est fait quotidiennement et automatiquement via l’utilisation du plugin Cargo Dev-Int Mettre en place un environnement dont les données sont maitrisées sur lesquels un déploiement est fait quotidiennement et automatiquement via l’utilisation du plugin Cargo et sur lequel un ensemble de test fonctionnellement est effectué via le framework de test Selenium TU-Dev-Int Présentation So@t License Creative Commons 2.0 – Share Alike

51. Exemple de mise en œuvre Plan d’action – le processus de développement Présentation So@t License Creative Commons 2.0 – Share Alike Processus de développement développement TU NOK commit TU OK Compilation + TU Compilation ou TU NOK Compilation + TU + Déploiement Auto Dev-integ Compilation + TU + TF + Déploiement Auto TU-Dev-integ Compilation ou TU ou TF NOK Compilation ou TU ou TF NOK TU = tests unitaires TF = tests fonctionnels Poste développeur SVN TeamCity

52. Exemple de mise en œuvre Plan d’action – Le processus de livraison Mettre en place un environnement le plus proche possible de l’environnement cible permettant de tester le livrable via les scripts utilisés par la production Définir le rôle de l’environnement sur lequel les tests de QA sont effectués Présentation So@t License Creative Commons 2.0 – Share Alike

53. Exemple de mise en œuvre Plan d’action – Le processus de livraison Présentation So@t License Creative Commons 2.0 – Share Alike Processus de livraison Production Livrable Environnement installé Déploiement Correction TF NOK Livraison Environnement Installé TF = tests fonctionnels Déploiement si TF OK sur env. dev-intégration Tests MOA NOK Poste Livreur (job Serveur CI) Pré-Intégration Intégration Développeurs

54. Exemple de mise en œuvre Plan d’action – Les tests fonctionnels Utilisation de Selenium Développement d’un framework s’appuyant sur Selenium pour rendre indépendant les scénarii de test de l’interface web (API offerte sous forme de DSL) Présentation So@t License Creative Commons 2.0 – Share Alike

55. Exemple de mise en œuvre Plan d’action – Les pratiques de codage Mise en place de Sonar Mais… Mal configuré Mal utilisé par le management Mal compris par le management Cette culture doit être partagée! Présentation So@t License Creative Commons 2.0 – Share Alike

56. Exemple de mise en œuvre Plan d’action – Le livrable Utilisation du plugin Release pour gérer le processus de livraison (création tags, déploiement sur le Remote Proxy, …) Présentation So@t License Creative Commons 2.0 – Share Alike

57. Exemple de mise en œuvre Focus – Retour sur les fichiers de configuration Ici, tous les fichiers de configuration se trouvent dans le classpath serveur au runtime : Permet : Gestion de la configuration par la production Ne pas avoir à « dé-warer » ou « dé-jarer » Problématique : Ne pas avoir de doublons Solution appliquée : 1 module pour la configuration Utilisation du resource/filter de Maven Utilisation du classifier test Présentation So@t License Creative Commons 2.0 – Share Alike

58. Exemple de mise en œuvre Focus – Retour sur le jeux de données Ici, jeux de données dépendant de la base de données Problématique : Séparation entre le schéma et les données de tests Solution retenue : Dump bdd? Fichier sql à maintenir? Injecteur Java? Doit être pensé dès le départ et la problématique doit être partagée! Présentation So@t License Creative Commons 2.0 – Share Alike

59. Exemple de mise en œuvre Focus – Retour sur le livrable Utilisation du plugin assembly Utilisation d’1 module Utilisation de la gestion de la transitivité de Maven pour gérer le livrable Présentation So@t License Creative Commons 2.0 – Share Alike

60. Présentation So@t License Creative Commons 2.0 – Share Alike Bonnes pratiques Maven

61. Bonnes pratiques Maven En vrac… SNAPSHOT Utiliser dependencyManagement Utiliser les plugins et déclarer leur version Utiliser pluginManagement Utiliser les modules et les héritages Utiliser le même numéro de version dans tout le projet Ne pas utiliser Maven pour ce qu’il n’est pas prévu Utiliser un repository manager (Nexus, Archiva, Artifactory, …) Ne pas skipper les tests unitaires Comprendre son fonctionnement Présentation So@t License Creative Commons 2.0 – Share Alike

62. Bonnes pratiques Maven En général… Utiliser un SCM (SVN, CVS, Git, …) Utiliser des outils de qualité de code (Sonar, Findbugs, Pmd, Checkstyle, Cobertura, …), les configurer, regarder l’évolution et améliorer son code Utiliser le plugin Release quand cela est possible Utiliser un serveur d’intégration continue (Hudson, Jenkins, Continuum, Bamboo, CruiseControl, …) Faire prendre conscience à chacun de l’importance des processus Présentation So@t License Creative Commons 2.0 – Share Alike

63. Bonnes pratiques Maven Focus Plugin Release Phase prepare : Vérification du code présent Vérification des SNAPSHOTS Prompt de l’utilisateur sur les versions Vérifie la validité du projet Tags le projet sur le SCM à la version indiquée Itère le numéro de version Phase perform : Checkout du code source Génération du livrable, de la documentation et du code source et upload sur le remote proxy maven Présentation So@t License Creative Commons 2.0 – Share Alike

64. Bonnes pratiques Maven Focus Commandes -pl -amd -am -N -T Présentation So@t License Creative Commons 2.0 – Share Alike

65. Bonnes pratiques Maven Focus Plugin Versions mvn versions:set –DnewVersion=xxx mvn versions:commit mvn versions:rollback Présentation So@t License Creative Commons 2.0 – Share Alike

66. Présentation So@t License Creative Commons 2.0 – Share Alike Pour aller plus loin…

67. Pour aller plus loin… [Web] Site officiel de maven http://maven.apache.org/ [Livre] Apache Maven – N. De loof, A. Héritier [Pearson] [Web] BetterBuildsWithMaven – V. Massol, J. Van Zyl, B. Porter, J. Casey, C. Sanchez http://repo.exist.com/dist/maestro/1.7.0/BetterBuildsWithMaven.pdf [Web] Maven the complete reference - T. O'Brien, J. Casey, B. Fox, J. Van Zyl, M. Moser, E. Redmond, L. Shatzer http://www.sonatype.com/books/mvnref-book/reference/public-book.html [Web] Maven : The definive guide - T. O'Brien, J. Casey, B. Fox, J. Van Zyl, E. Redmond, L. Shatzer, B. Snyder, E. Hugonnet, E. Alliaume http://www.maven-definitive-guide.fr/ [Vidéo] Vers des exigences exécutables – O. Billard, A. Bonnefoy http://www.beta.parleys.com/#id=1880&sl=1&st=5 [Vidéo] Intégration Continue – enjeux, outils et bénéfices – P. Ensarguet, T. Carré http://www.beta.parleys.com/#id=1863&sl=1&st=5 [Vidéo] Sonar – O. Gaudin http://www.beta.parleys.com/#id=678&sl=1&st=5 [Vidéo] Les frameworks open source – R. Pelisse, F. Le Droff http://www.beta.parleys.com/#id=625&sl=1&st=5 Présentation So@t License Creative Commons 2.0 – Share Alike

68. Présentation So@t License Creative Commons 2.0 – Share Alike Question ?