J’ai eu le plaisir de participer au BreizhCamp 2013, à la fois en tant que visiteur mais aussi en tant qu’orateur.
J’y ai présenté la conférence “Papy fait du Scala”, dont voici le support de présentation :
Et la vidéo :
J’ai eu le plaisir de participer au BreizhCamp 2013, à la fois en tant que visiteur mais aussi en tant qu’orateur.
J’y ai présenté la conférence “Papy fait du Scala”, dont voici le support de présentation :
Et la vidéo :
[Play Framework[(play2] utilise Scala SBT comme outil de build depuis la version 2.0. A la Maven, il télécharge les dépendances de votre projet Play Framework depuis des dépôts centralisés, comme Maven Central.
Cette technique est très intéressante, mais il faut bien tenir compte des inconvénients induits :
Pas de maîtrise des dépendances ou des dépôts configurés par les développeurs : on télécharge n’importe quoi depuis n’importe où
Gâchi de bande passante / latence : chaque développeur télécharge chaque dépendance depuis Internet, là où une mutualisation depuis un serveur localisé dans le réseau de l’entreprise ferait économiser de la bande passante et gagner en réactivité (latence réduite)
Vous ne pouvez pas dépendre d’artifacts uniquement internes à votre entreprise (sans les publier sur Internet)
En entreprise, 1/ est généralement résolu par “blocage naturel” : on ne peut pas télécharger depuis Internet. 2/ et 3/ peuvent se résoudre à l’aide d’un serveur proxy dédié à Maven, SBT, … comme Sonatype Nexus ou JFrog Artifactory.
Comment paramétrer Play Framework pour utiliser Artifactory ?
[J’ai déjà expliqué comment configurer SBT pour utiliser Artifactory][/configurer-scala-sbt-repository-artifactory/], mais, bien que Play Framework utilise SBT, ces explications ne s’y appliquent pas (pour le moment). SBT étant embarqué dans Play Framework, il ne lit pas les instructions de configuration fournies en ligne de commande.
Pas de différence du côté d’Artifactory en revanche.
Par la suite, je suppose que la variable PLAY_HOME
pointe vers votre installation de Play Framework 2.x.
Créez le fichier ~/sbt/.repositories
avec le contenu suivant :
1 2 3 4 5 |
|
Ce fichier indique à SBT l’ensemble des dépôts qu’il peut consulter pour résoudre les dépendances :
local
: dépôt Ivy local par défaut, localisé dans ~/.ivy2/
maven-local
: dépôt Maven local par défaut, localisé dans ~/.m2/repository/
ivy-proxy-releases
: suivi d’une URL et d’un pattern, on indique à SBT qu’il pourra trouver les artifacts qui respectent ce pattern dans ce dépôts (pattern Ivy)
maven-proxy-releases
: suivi d’une URL, le dépôt au format Maven pour les autres dépendances
~/sbt/.repositories
Éditez le fichier $PLAY_HOME/framework/sbt/sbt.boot.properties
et complétez le bloc suivant :
1 2 3 |
|
De cette manière :
1 2 3 4 5 |
|
Avec ces deux instructions, on force Play Framework à utiliser uniquement les dépôts configurés dans le fichier ~/sbt/.repositories
.
Commencez par nettoyer votre dépôt local de cache de Play Framework (par précaution, je vous propose de simplement le déplacer) :
1
|
|
Postionnez-vous dans un projet Play, et testez :
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 |
|
Les dépendances sont téléchargées depuis http://localhost:8180/...
, comme voulu.
Note : l’affichage obtenu peut varier selon vos dépendances paramétrées.
Scala SBT est à Scala ce que Maven est à Java : un outil de build dédié qui épouse la philosophie du langage.
Comme Gradle avec Groovy, SBT est beaucoup plus puissant que Maven, dans le sens où, par exemple, étendre le build est beaucoup plus simple que de construire systématiquement un plugin (qu’il faut versionner, déployer, …).
Cela dit, il ne faut pas occulter certains de ses inconvénients : incompatibilité des binaires de plugins entre versions de SBT, syntaxe complexe (en tout cas plus compliqué que du simple XML) …
Scala SBT se répand petit à petit, avec Play Framework 2 comme cheval de Troie. En effet, Play2 a fait le choix de Scala SBT comme système de build : - suite aux nombreuses critiques du système de build très fermé de Play 1 - car Play2 est écrit en Scala et se marrie donc naturellement avec SBT
Comme Maven, SBT se base sur le dépôt d’artifacts [Maven 2 Central]repo-maven2-central], mais aussi sur deux dépôts au format Ivy : celui de Typesafe et celui dédié à SBT.
Qui dit entreprise, dit “proxy”, “firewall”, “anti-virus”, … bref tout ce qui empêche des outils de build comme SBT ou Maven de fonctionner en standard. Vous avez alors deux possibilités : - soit paramétrer le proxy permettant à l’outil d’accéder à Internet - soit paramétrer des dépôts d’artifacts internes à l’entreprise (ce qui ne nécessite plus d’accéder à Internet)
C’est ce dernier paramétrage que je vous propose de décrire en détails.
Voici ce que nous allons configurer :
Il existe plusieurs outils qui peuvent permettre de gérer des artifacts, dans différents formats (Maven, RPM, Deb, P2, …), comme Sonatype Nexus ou JFrog Artifactory.
Ce qui compte pour SBT, c’est un gestionnaire d’artifacts qui supporte les formats Ivy et Maven. J’ai donc choisi Artifactory.
Je vous passe les détails d’installation de l’outil, ils sont très bien décrits dans sa documentation.
La configuration des dépôts d’Artifactory s’effectue de la manière suivante :
Ajouter les deux dépôts distants manquants, à savoir :
sbt-plugin-releases
=> http://repo.scala-sbt.org/scalasbt/sbt-plugin-releases/
typesafe-ivy-releases
=> http://repo.typesafe.com/typesafe/ivy-releases/
Ajouter un nouveau dépôt virtuel de type “Ivy” qui pointe sur sbt-plugin-releases
et typesafe-ivy-releases
. Je l’ai nommé ivy-remote-repos
.
Fusionner les dépôts Maven et Ivy en un seul est l’erreur à ne pas commettre (au format Maven par exemple). En effet, le format Ivy est plus riche que celui de Maven et des informations essentielles pour la résolution des plugins SBT seraient perdues.
(Optionnel) Si vous développez pour Play Framework, rajouter le dépôt Maven des releases Typesafe http://repo.typesafe.com/typesafe/maven-releases/
à votre dépôt virtuel Maven peut être une bonne idée.
A ce stade de la configuration d’Artifactory, ces trois paramètres sont disponibles :
http://localhost:8180/artifactory/
par exemplemaven-remote-repos
ivy-remote-repos
La configuration de SBT s’effectue en deux temps.
Pour cela, créez le fichier ~/sbt/.repositories
avec le contenu suivant :
1 2 3 4 5 |
|
Ce fichier indique à SBT l’ensemble des dépôts qu’il peut consulter pour résoudre les dépendances :
local
: dépôt Ivy local par défaut, localisé dans ~/.ivy2/
maven-local
: dépôt Maven local par défaut, localisé dans ~/.m2/repository/
ivy-proxy-releases
: suivi d’une URL et d’un pattern, on indique à SBT qu’il pourra trouver les artifacts qui respectent ce pattern dans ce dépôts (pattern Ivy)
maven-proxy-releases
: suivi d’une URL, le dépôt au format Maven pour les autres dépendances
La configuration précédente permet d’ajouter des dépôts à la configuration de SBT. Mais des dépôts peuvent être paramétrés dans chaque projet SBT, ce qui ne fonctionnera pas si vous n’avez pas accès à Internet. Si vous désirez que toutes les demandes de dépendances SBT passent par votre proxy Artifactory, il vous faut le paramétrage complémentaire suivant :
1
|
|
A passer directement en argument à la ligne de commande Java qui lance SBT ou bien à rajouter à la variable SBT_OPTS
par exemple.
Un simple sbt update
dans un projet SBT suffit à vérifier la bonne mise à jour des dépendances de SBT au travers d’Artifactory. Pour un projet Play2, la commande play update
aura le même effet.
Cette configuration ne fonctionnant pas pour Play Framework 2, [consultez cet article dédié][/configurer-play-framework-repository-artifactory/].