Ce diaporama a bien été signalé.
Le téléchargement de votre SlideShare est en cours. ×

De Maven à SBT ScalaIO 2013

Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Prochain SlideShare
Codons notre infrastructure
Codons notre infrastructure
Chargement dans…3
×

Consultez-les par la suite

1 sur 38 Publicité

Plus De Contenu Connexe

Diaporamas pour vous (20)

Publicité

Similaire à De Maven à SBT ScalaIO 2013 (20)

Plus récents (20)

Publicité

De Maven à SBT ScalaIO 2013

  1. 1. De Maven à SBT Stéphane Manciot
  2. 2. Memo • Introduction • De Maven à SBT o Architecture en plugin Maven versus tâches SBT o Maven phases versus tasks dependencies o Avantages SBT versus Maven
  3. 3. Un bon outil de build doit … • S’inscrire dans une démarche DevOps • Être indépendant de l’environnement sur lequel il s’exécute • S’intégrer dans l’éco-système de l’entreprise Mais aussi…
  4. 4. … Faciliter la vie des développeurs ;)
  5. 5. Architecture en plugin Maven versus tâches SBT
  6. 6. Architecture de Maven • Une architecture reposant essentiellement sur : o L’exécution de goals définis au sein de plugins o Le rattachement de ces goals à des phases de l’un des 3 cycles de vie prédéfinis de Maven o L’utilisation d’un fichier au format xml (Project Object Model) pour pouvoir configurer l’exécution des goals
  7. 7. Phases d’un Cycle de vie Maven Valider Valider Compiler Compiler Tester Tester Packager Packager Tests d’intégration Tests d’intégration Vérifier Vérifier Installer Installer Déployer Déployer
  8. 8. Goals mis en œuvre via des plugins Valider Valider compiler:compile compiler:compile Compiler Compiler Tester Tester Packager Packager surfire:test surfire:test jar:jar jar:jar Tests d’intégration Tests d’intégration Vérifier Vérifier Installer Installer Déployer Déployer
  9. 9. Définition du build au format XML
  10. 10. Limitations du format XML • Je ne puis exécuter que des goals qui ont été définis au sein de plugins existants • L’apparition de nouveaux besoins requièrent : o D’attendre la mise à disposition d’une nouvelle version du plugin o De définir soit même un nouveau goal
  11. 11. Ajout d’un goal avec Maven • Création du fichier pom du plugin
  12. 12. Ajout d’un goal avec Maven • Création d’un Mojo
  13. 13. Ajout d’un goal avec Maven • Intégration du goal dans le pom
  14. 14. Ajout d’une tâche avec SBT • Dans SBT il y a le S pour Simple 
  15. 15. Ajout d’une tâche avec SBT • Dans SBT il y a le S pour Simple 
  16. 16. L’architecture sbt repose sur • L’exécution de tâches ordonnancées de manière explicite • La configuration des tâches via des settings • L’utilisation de Scala pour la définition des builds
  17. 17. Phases Maven versus task dependencies
  18. 18. Ordonnancement des goals Maven • Exécution séquentielle des phases • Ordonnancement implicite des goals (FIFO)
  19. 19. L’exécution d’une tâche SBT • Est ordonnancée de manière explicite • Produit un résultat exploitable pour les autres tâches
  20. 20. L’exécution d’une tâche SBT • Est ordonnancée de manière explicite • Produit un résultat exploitable pour les autres tâches
  21. 21. Exemple d’exploitabilité du résultat
  22. 22. Avantages SBT versus Maven
  23. 23. Performances • Parallélisation de l’exécution des tâches • Environnement de développement interactif o Mode console SBT versus outil en ligne de commande Maven o Scala Read Evaluate Print Loop • Méthode ~ pour l’exécution de tâche en continu
  24. 24. Performances Scala REPL
  25. 25. Gestion multi-projets • Maven impose : o un lien d’héritage pour pouvoir partager des éléments communs o Une arborescence de fichiers dans le cadre de l’aggrégation de modules • SBT a supprimé ces 2 contraintes o Le principe d’Hollywood o Possibilité de créer des dépendances « distantes »
  26. 26. Incompatibilité versions scala • Cross Compilation SBT
  27. 27. Incompatibilité versions scala • … versus Maven injection
  28. 28. Gestion des dépendances (Aether versus Ivy) • Maven via Aether ne peut gérer qu’un nombre fini de scopes • SBT via Ivy s’appuie sur la notion de Configuration qui rend la gestion plus souple o Permet de définir plus finement les artefacts à récupérer en fonction de la configuration choisie
  29. 29. Gestion des dépendances
  30. 30. SBT en entreprise
  31. 31. Mise en place d’un référentiel d’entreprise mavenmavencentral central typesafe typesafe scalascalasbt sbt
  32. 32. Conf. du gestionnaire d’artefacts • Ajout des référentiels distants Ivy o sbt-plugin-releases o typesafe-ivy-releases o… • Ajout des référentiels distants Maven o maven repo1 o… • Ajout d’un référentiel virtuel Ivy • Ajout d’un référentiel virtuel Maven
  33. 33. Configuration de SBT • Ajout des nouveaux dépôts • Bloquer tous les autres dépôts définis au sein des builds SBT o sbt -Dsbt.override.build.repos=true o Variable SBT_OPTS
  34. 34. Récupération des artefacts
  35. 35. Publication des artefacts
  36. 36. Publication des métriques dans sonar
  37. 37. Sources - Follow us on GitHub • maven2sbt : https://github.com/ebiznext/maven2sbt • sbt-cxf-wsdl2java : https://github.com/ebiznext/sbt-cxf-wsdl2java • sbt-groovy : https://github.com/ebiznext/sbt-groovy • sbt-soapui: https://github.com/ebiznext/sbt-soapui
  38. 38. Questions ?

Notes de l'éditeur

  • Le build appliqué aux mêmes sources doit conduire aux même résultats eg à la création d’artefacts identiques
    Cadre de développement => proposer des valeurs par défaut -> pas de configuration + best practices
    Indépendant de l’environnement sur lequel le build est exécuté -> portabilité
  • Le build appliqué aux mêmes sources doit conduire aux même résultats eg à la création d’artefacts identiques
    Cadre de développement => proposer des valeurs par défaut -> pas de configuration + best practices
    Indépendant de l’environnement sur lequel le build est exécuté -> portabilité
  • Le build appliqué aux mêmes sources doit conduire aux même résultats eg à la création d’artefacts identiques
    Cadre de développement => proposer des valeurs par défaut -> pas de configuration + best practices
    Indépendant de l’environnement sur lequel le build est exécuté -> portabilité
  • Project Object Model
  • ----- Notes de la réunion (10/24/13 14:09) -----
    A maven lifecycle is a series of sequential phases. Each phase can contain a zero or more tasks (in Maven terms a goal). When you execute a phase in maven, it will execute all of the preceding phases before executing that phase.
  • ----- Notes de la réunion (10/24/13 14:09) -----
    The configuration is XML based, which is great, except if you want to do stuff which requires options that aren't available. If the standard plugin does what you want, great.
    For a project which requires non-standard things, things sometimes get awkward. If there is a standard plugin which does what you want it to do, great. If the required option exists for the plugin you're using great. If it doesn’t, then the fun starts.
  • ----- Notes de la réunion (10/24/13 14:09) -----
    The configuration is XML based, which is great, except if you want to do stuff which requires options that aren't available. If the standard plugin does what you want, great.
    For a project which requires non-standard things, things sometimes get awkward. If there is a standard plugin which does what you want it to do, great. If the required option exists for the plugin you're using great. If it doesn’t, then the fun starts.
  • ----- Notes de la réunion (10/24/13 14:36) -----
    sbt is built around tasks. Unlike maven, there are no phases or goals or executions: just tasks.
    You want to do something, execute a task.
  • ----- Notes de la réunion (10/24/13 14:36) -----
    You want to ensure that a task runs after another task, add an explicit dependency between the tasks. If you want to use the results of a task in another task, push the output from one task into another.
    Multiple tasks can depend upon the output of the same task. By default, sbt runs all of the tasks in parallel, but using the dependency tree it can work out what should be sequential and what can be parallel => show an exemple with dependency tree
  • ----- Notes de la réunion (10/24/13 14:36) -----
    You want to ensure that a task runs after another task, add an explicit dependency between the tasks. If you want to use the results of a task in another task, push the output from one task into another.
    Multiple tasks can depend upon the output of the same task. By default, sbt runs all of the tasks in parallel, but using the dependency tree it can work out what should be sequential and what can be parallel => show an exemple with dependency tree
  • Par exemple pour une librairie de gestion de données qui s’appuie sur la base NOSQL RIAK ou sur le système de fichiers avec une sérialisation binaire ou JSON, Ivy permet de définir les configurations NOSQL / FS / JSON / BIN et de permettre au client de télécharger uniquement les artefacts correspondants à son choix.
    En Maven il n’est pas possible de définir un scope NOSQL par exemple. Toutes les dépendances devront être rapatriées.

×