Universitélang scala tools
-
Upload
fabrice-sznajderman -
Category
Software
-
view
188 -
download
0
Transcript of Universitélang scala tools
Historique
ManuelScript Ant Maven
GradleSBT
Automatisation
Portabilité
Standardisation
Extensibilité
Interactivité
AutomatisationPortabilité
StandardisationExtensibilité
Fonctionnalités clefs
• Shell
• Continuous <Task>
• Exécution des tâches en parallèle
• Compilation incrémentale
• Exécution des tests intelligente
• Extension simplifiée
Concepts clefs
• Task[T] :
• Unité de traitement
• Les tasks sont exécutées à la demande
• Exécutées une fois par run
SBT se base sur 2 concepts simple : Tasks et SettingsOn va pouvoir créer des dépendances entre les tâches
• Setting[T] :
• Propriété de configuration
• Les settings sont évaluées uniquement au chargement du projet
Accès à la valeur d’une task ou setting
la méthode value() permet de lire le résultat (task) ou valeur (setting)
Dépendance entre tâches
Pour créer une dépendance entre 2 tâches, il faut que l’une accède au résultat de l’autre :
otherTask oneTask
Dépendance entre tâches
SBT est capable d’exécuter des tâches en parallèle quand cela est possible :
otherTask oneTask
thirdTask
Shell : Inspect
La commande inspect avec le paramètre tree permet de voir l’arbre de dépendances d’une tâche :
> inspect tree otherTask [info] sbtprojectdemo/*:otherTask = Task[Int] [info] +-sbtprojectdemo/*:oneTask = Task[Int]
Shell : Inspect
La commande inspect avec le paramètre uses permet de voir la liste des tâches utilisant cette tâches
> inspect uses oneTask[info] [info] sbtprojectdemo/*:otherTask
Shell : show
La commande show affiche la valeur d’un setting ou le résultat d’une task
> show baseDirectory [info] /Users/fsznajderman/Dev/projects/sbtDemo
> show oneTask [info] 2 [success] Total time: 0 s, completed 11 janv. 2016 13:02:00
Descripteur de build
• build.sbt (ou build.scala historique)
• Descripteur écrit avec [un DSL] Scala
• Principe de convention over configuration
• Projet mono module : descripteur non obligatoire
• projet multi module : Un seul fichier à la racine du projet
Définition des versions
Possibilité de définir la version
• du compilateur scala
• de SBT
directement dans le fichier build.sbt
sbt.version=0.13.7 scalaVersion := 2.11.7
Structure d’un projet multi-module
• Un seul descripteur build.sbt à la racine du projet
• Toute la configuration est contenue dedans
• Possibilité de factoriser les settings communs
Shell : interaction avec sous module en particulier
Il est possible d’interagir avec un sous module à partir du shell. Il faut utiliser la syntaxe suivante :
> repository/compile
> service/test
>show commons/ScalaVersion
Gestion des dépendances
• Gestion des dépendances avec Apache Ivy • Déclaration dans le fichier build.sbt • Format pour la déclaration d’une dépendance :
libraryDependencies += groupID % artifactID % revision
Gestion des dépendances
• Possibilité de gérer manuellement ses dépendances. • Ce sont des unmanaged dependencies. • Elles doivent être placées dans le répertoire lib (par
défaut)
Gestion des dépendances
• Il est possible de gérer plus finement les versions des
dépendances avec SBT. • SBT va rechercher la librairie adaptée à la version de
compilateur Scala définie dans le build.sbt • Cette fonctionnalité s'applique uniquement aux librairies
construite avec SBT
libraryDependencies += groupID %% artifactID % revision
Classes utilitaires
• IO : Manipulation du File System
• Process : Execution de process externe
• Stream : Accès sur le système de log
Plugins
• IDEs • Test • Code coverage • Static code analysis • packaging • Releases • Deployment integration • Android & iOs
• Monitoring integration • Web and front-end development • Documentation • Library dependency • Utility and system • Database • Code generator • Game development • OSGi
http://www.scala-sbt.org/0.13/docs/Community-Plugins.html
ScalaTest
• Approche similaire à celle de JUnit
• Utilisation principalement d'assertions
• Ouvert sur de nombreux outils du marché comme :
• Mockito,
• Junit,
• TestNG
ScalaTest
• Propose plusieurs styles pour rédiger les TUs. Chaque approche répond à un besoin particulier.
• FunSuite : Proche du style xUnit
• FlatSpec : Introduction à BDD
• FunSpec : Concept tiré de Ruby's RSpec tool
• http://www.scalatest.org/user_guide/selecting_a_style
Scala Spec2
• Basé sur l'approche Behavior Driven Development
• Les tests décrivent le fonctionnement attendu des composants testés littéralement
• Propose un DSL riche
ScalaCheck
• Basé sur l’approche Property Based Testing
• Inspirée de la librairie Haskell : QuickCheck
• Générateur de données aléatoire
• Pas de dépendance autre que le runtime Scala
• Utilisation standalone ou avec Spec2 ou ScalaTest