https://air.imag.fr/api.php?action=feedcontributions&feedformat=atom&user=Calmantair - User contributions [en]2026-06-01T01:52:30ZUser contributionsMediaWiki 1.39.17https://air.imag.fr/index.php?title=Services_%C3%A9tendus_pour_le_mod%C3%A8le_de_composants_iPOPO_pour_Python&diff=25597Services étendus pour le modèle de composants iPOPO pour Python2016-01-05T10:21:59Z<p>Calmant: </p>
<hr />
<div>Tuteurs : Didier Donsez & Thomas Calmant<br />
<br />
Étudiants: 2 RICM4<br />
<br />
L'objectif de ce projet est de développer une suite de services utilitaires pour la plateforme open-source [[iPOPO]].<br />
<br />
=Contexte=<br />
<br />
[[iPOPO]] est un modèle de composants logiciels pour le langage Python. iPOPO s'inspire des principes de la spécification [[OSGi]] pour Java. Les composants iPOPO peuvent être ajoutés, retirés et mis à jour dynamiquement (i.e. sans redémarrer le programme Python).<br />
<br />
=Cahier des charges=<br />
<br />
iPOPO implémente quelques services définis dans la spécification OSGi:<br />
* [https://osgi.org/javadoc/r4v42/org/osgi/service/cm/ConfigurationAdmin.html Configuration Admin]<br />
* [https://osgi.org/javadoc/r4v42/org/osgi/service/event/EventAdmin.html Event Admin]<br />
* [https://osgi.org/javadoc/r4v42/org/osgi/service/http/HttpService.html HTTP Service]<br />
<br />
D'autres services pourraient être implémentés, tels que:<br />
* [https://osgi.org/javadoc/r4v42/org/osgi/service/wireadmin/package-summary.html Wire Admin]<br />
* [https://osgi.org/javadoc/r4v42/org/osgi/service/log/LogService.html Log Service]<br />
* [https://osgi.org/javadoc/r4v42/org/osgi/service/prefs/Preferences.html Preferences Service]<br />
* [https://osgi.org/javadoc/r4v42/org/osgi/service/useradmin/UserAdmin.html User Admin]<br />
* ...<br />
<br />
Il serait également possible de travailler sur le shell iPOPO:<br />
* en ajoutant la notion d'utilisateurs et de droit d'exécution des commandes<br />
* en chiffrant la liaison distante au shell<br />
* en ajoutant la notion de pipe pour utiliser le résultat d'une commande comme entrée d'une seconde.<br />
<br />
=Liens=<br />
* [https://ipopo.coderxpress.net/ iPOPO]<br />
* [https://www.osgi.org/developer/specifications/ Spécification OSGi]</div>Calmanthttps://air.imag.fr/index.php?title=TAGL/TP&diff=22583TAGL/TP2015-03-27T07:40:28Z<p>Calmant: /* Rappels de Python */</p>
<hr />
<div>Travaux pratiques de l'UE [[TAGL]].<br />
<br />
Anciennes versions : [[TAGL/TP 2014]]<br />
<br />
=Séance 1 : Gestion de versions=<br />
==Git==<br />
<br />
Création d'un dépôt Git local<br />
<br />
===Méthode simple: init first===<br />
<br />
Via cette méthode, on crée un dépôt local, avec un répertoire de travail, puis on pousse ses modifications vers un dépôt "bare".<br />
Cette méthode est la plus simple, car on dispose immédiatement d'un répertoire de travail.<br />
<br />
<syntaxhighlight lang="bash"><br />
# Création d'un dépôt Git dans le dossier simple-repo<br />
git init simple-repo<br />
<br />
# Création d'un README<br />
cd simple-repo<br />
echo "Hello, World" > README<br />
<br />
# Ajout du versionnement du fichier README<br />
git add README<br />
<br />
# Commit<br />
git commit<br />
</syntaxhighlight><br />
<br />
À ce niveau, on a un dépôt Git complètement fonctionnel.<br />
Cependant, il est intéressant de pousser ses modifications vers un autre dépôt, sur une autre machine.<br />
On va donc créer un dépôt bare sur une autre machine (ou autre dossier pour l'exemple)<br />
<br />
<syntaxhighlight lang="bash"><br />
git init --bare server-repo<br />
</syntaxhighlight><br />
<br />
On considère que l'URL pour accéder à ce dépôt est URL_REPO.<br />
On va d'abord ajouter ce dépôt serveur à la liste des dépôts connu-repos de votre dépôt local.<br />
Étant donné qu'il s'agit du dépôt "principal" à utiliser, on l'appellera //origin//, par convention.<br />
<br />
<syntaxhighlight lang="bash"><br />
git remote add origin URL_REPO<br />
# Récupération de ses informations<br />
git fetch origin<br />
</syntaxhighlight><br />
<br />
Ce serveur distant est "vide": il n'a aucune branche. On va donc enregistrer notre branche sur le serveur<br />
<br />
<syntaxhighlight lang="bash"><br />
git push origin master<br />
</syntaxhighlight><br />
<br />
À partir de cette commande, la branche locale //master// sera liée à la branche distante //origin/master//.<br />
Lors des prochaines commandes ''git push'', grâce à cette liaison, tous les commits sur la branche locale //master// seront poussées sur le serveur distant.<br />
<br />
===Méthode moins simple: bare first===<br />
<br />
Si on commence dans par le serveur "vide", il faudra le cloner au lieu de le définir comme un dépôt distant.<br />
<br />
<syntaxhighlight lang="bash"><br />
# Création du dépôt vide<br />
git init --bare server-repo<br />
</syntaxhighlight><br />
<br />
On considère que ce dépôt est accessible à l'URL URL_REPO<br />
<br />
<syntaxhighlight lang="bash"><br />
# Clonage du dépôt<br />
git clone URL_REPO clone-repo<br />
</syntaxhighlight><br />
<br />
Un avertissement indique que l'on clone un dépôt vide: le dépôt local à donc une branche master, mais elle n'est pas liée au dépôt distant, car celui-ci n'a aucune branche.<br />
Le dépôt distant est automatiquement appelé //origin//.<br />
<br />
<syntaxhighlight lang="bash"><br />
# Commit dans le dépôt local<br />
cd clone-repo<br />
echo hello > readme.rst<br />
git add readme.rst<br />
git commit et ses dépendances<br />
</syntaxhighlight><br />
<br />
Comme dans la méthode simple, il faut pousser la branche master vers le dépôt distant:<br />
<br />
<syntaxhighlight lang="bash"><br />
git push origin master<br />
</syntaxhighlight><br />
<br />
===De l'importance des README===<br />
<br />
Il est très important d'avoir au moins 2 fichiers dans votre dépôt Git:<br />
<br />
* LICENSE: contenant le texte **complet** de la licence de votre projet<br />
* README: décrivant votre projet et comment l'utiliser. Ce fichier doit rappeler le nom de la licence de votre projet<br />
<br />
Il est aussi recommandé d'avoir les fichiers suivants:<br />
<br />
* AUTHORS: contenant la liste des noms/pseudos et e-mails des auteurs de commits ou de code inclus dans ce projet<br />
* INSTALL: contenant la liste des dépendances de ce projet et des commandes à utiliser pour le compiler et l'installer<br />
<br />
Les fichiers LICENSE sont des fichiers textes bruts.<br />
Les autres fichiers sont généralement dans un format offrant un peu plus de lisibilté, par exemple dans les formats [http://daringfireball.net/projects/markdown/ Markdown] (.md) ou [http://docutils.sourceforge.net/rst.html reStructuredText] (.rst)<br />
<br />
Un plug-in existe pour éditer des fichier reStructuredText dans Eclipse: ReST Editor, disponible sur le [https://marketplace.eclipse.org/content/rest-editor Marketplace Eclipse]<br />
<br />
=Séance 2a: Intégration en continue=<br />
<br />
===GitHub & [[Travis-CI]]===<br />
<br />
Travis-CI est un service permettant d'exécuter un script dans une machine virtuelle Ubuntu dès que vous effectuez un push sur un de vos dépôts GitHub.<br />
L'intérêt est de savoir si la version d'un projet que vous avez rendu publique peut être compilée et si ses tests passent.<br />
<br />
La machine virtuelle "offerte" par Travis est préconfigurée pour le language indiqué dans son fichier de configuration ('''.travis.yml'''), mais il est possible d'utiliser la commande '''sudo apt-get install ...''' pour ajouter vos dépendances.<br />
<br />
<br />
<br />
Pour utiliser [[Travis-CI]]:<br />
<br />
# Créez compte individuel sur GitHub https://github.com<br />
# ''Fork''ez le dépôt https://github.com/heroku/node-js-getting-started<br />
# Ajoutez un collaborateur (i.e. votre binôme) au projet ''forké'', via les paramètres (''settings'') de ce projet<br />
# Pour l'exemple, activez le service (ou hook) ''Email'' depuis les paramètres du dépôt: à chaque fois que vous ou un de vos collaborateurs ferra un '''git push''', vous recevrez une notification par mail.<br />
# Activez le service Travis-CI: identifiez-vous (''sign in'') sur https://travis-ci.org/ avec votre compte GitHub<br />
# Activez le service pour les projets sur lesquels vous souhaitez appliquer les principes d'intégration continue<br />
<br />
[[Travis-CI]] utilise un fichier nommé '''.travis.yml''' (attention: fichier caché sous Unix) pour se configurer et choisir les opérations à effectuer.<br />
Ce fichier doit se trouver à la racine de votre dépôt Git.<br />
<br />
Faites un '''Commit''' puis un '''Push''' du fichier '''.travis.yml''' ci-dessous.<br />
<br />
<pre><br />
language: node_js<br />
node_js:<br />
- "0.11"<br />
- "0.10"<br />
- "0.8"<br />
- "0.6"<br />
- iojs<br />
- iojs-v1.0.2<br />
<br />
</pre><br />
<br />
<br />
Ce fichier '''.travis.yml''' indique à [[Travis-CI]] que les scripts de ce projet dans ce dépôt seront exécutés avec plusieurs versions de [[Node.js]].<br />
<br />
Ajoutez dans le fichier '''package.json''' la section suivante:<br />
<pre><br />
"devDependencies": {<br />
"jshint": "^2.6.0"<br />
},<br />
"scripts": {<br />
"test": "./node_modules/jshint/bin/jshint index.js"<br />
}<br />
</pre><br />
et incrémentez le numéro de version.<br />
<br />
Faites un '''Commit''' puis un '''Push''' des fichiers touchés.<br />
<br />
<br />
'''Remarque:'''<br />
'''jshint''' peut être lancé localement avec les commandes suivantes:<br />
<pre><br />
sudo npm install jshint<br />
jshint index.js<br />
</pre><br />
<br />
A lire<br />
* http://docs.travis-ci.com/user/languages/javascript-with-nodejs/<br />
* https://github.com/docdis/learn-travis/blob/master/README.md<br />
<br />
=Séance 2b: Livraison en continue=<br />
<br />
==[[Heroku]]==<br />
[https://www.heroku.com/ Heroku] est une plateforme cloud de type PaaS permettant l'exécution d'applications et de services en ligne écrits dans les langages et plateformes suivantes : Ruby, [[Node.js]], [[Python]], Java, et PHP.<br />
<br />
# Créez un compte gratuit sur [https://signup.heroku.com Heroku]<br />
# Forkez le dépôt https://github.com/heroku/node-js-getting-started<br />
# Dans Heroku, créez une nouvelle app Node.js, et liez-la au repository Github créé à l'étape précédente<br />
# Choisissez l'option "Déploiement automatique" depuis la branche **master**<br />
# Modifiez le fichier index.js pour afficher la version de service dans la page HTML<br />
<pre><br />
var fs = require('fs');<br />
var package = JSON.parse(fs.readFileSync('./package.json', 'utf8'));<br />
var version=package.version;<br />
...<br />
response.send('Hello World! (current version: '+version+')');<br />
...<br />
</pre><br />
<br />
Incrémentez le numéro de version dans le fichier ''package.json''<br />
<br />
Faites un '''Commit''' puis un '''Push''' des fichiers touchés.<br />
<br />
Naviguez l'application sur Heroku<br />
<br />
# Modifiez le fichier index.js pour franciser le message dans la page HTML<br />
<pre><br />
...<br />
response.send('Bonjour Tout Le Monde! (version courante: '+version+')');<br />
...<br />
</pre><br />
<br />
Incrémentez le numéro de version dans le fichier '''package.json''<br />
<br />
Faites un '''Commit''' puis un '''Push''' des fichiers touchés.<br />
<br />
Naviguez l'application sur Heroku<br />
<br />
=Séance 3: Builders=<br />
Les builders permettent d'automatiser l'exécution en chaine des outils pour la production et la livraison en production des produits logiciels.<br />
<br />
==[[Make]]==<br />
<br />
==[[Ant]]==<br />
<br />
Faire les exercices 0, 1, 3 de ./tpant.htm dans http://lig-membres.imag.fr/donsez/cours/tpant.zip<br />
<br />
==[[Maven]]==<br />
<br />
[http://maven.apache.org/download.cgi Charger et installer Maven 3].<br />
<br />
Debian/Ubuntu & friends:<br />
<pre><br />
sudo apt-get update && sudo apt-get install maven<br />
</pre><br />
<br />
<pre><br />
mvn -version<br />
</pre><br />
<br />
Faites une copie du projet, basée sur Maven:<br />
<br />
# Dans votre dépôt Git, créez un dossier '''cron4j-mvn''': il contiendra le projet Cron4J avec la structure Maven<br />
# Dans ce dossier, utilisez l'[https://maven.apache.org/guides/introduction/introduction-to-archetypes.html archetype] Maven [http://maven.apache.org/archetype/maven-archetype-bundles/maven-archetype-quickstart/ maven-archetype-quickstart] (la version des sources de cron4j utilisés est la 2.5.5) (groupId: it.sauronsoftware.cron4j, artifactId: cron4j):<br />
#:<pre>mvn archetype:generate -DarchetypeGroupId=org.apache.maven.archetypes -DarchetypeArtifactId=maven-archetype-quickstart</pre><br />
# Cette commande crée un projet avec un fichier ''pom.xml'', et une classe et un test modèles: supprimez ces modèles<br />
# Copiez les sources de Cron4J depuis le dossier '''cron4j-original''' ([https://github.com/donsez/tagl https://github.com/donsez/tagl]) dans le dossier '''src/main/java''' de votre projet Maven<br />
# Faites un essai de compilation:<br />
#:<pre>mvn clean verify</pre><br />
# Lancez un des exemples avec mvn exec:java -Dexec.mainClass="com.example.Main" [-Dexec.args="argument1"] ... ([http://mojo.codehaus.org/exec-maven-plugin/usage.html doc. exec plugin], [http://mojo.codehaus.org/exec-maven-plugin/java-mojo.html doc. Exec:java goal])<br />
# Enfin modifiez le fichier '''.travis.yml''' à la racine de votre dépôt Git afin que Travis exécute la commande '''mvn clean verify''' à chaque mise à jour du dépôt GitHub.<br />
<br />
==Tests Unitaires avec JUnit 4==<br />
Survoller le tutoriel [http://www.vogella.com/tutorials/JUnit/article.html Unit Testing with JUnit]<br />
<br />
# Veillez à bien utiliser la dépendance JUnit 4.8.2 dans pom.xml<br />
# Ajouter le test unitaire suivant au projet, dans le fichier '''src/test/it/sauronsoftware/SchedulingPatternTest.java<br />
<pre><br />
package it.sauronsoftware;<br />
<br />
import it.sauronsoftware.cron4j.SchedulingPattern;<br />
import it.sauronsoftware.cron4j.InvalidPatternException;<br />
<br />
import static org.junit.Assert.assertEquals;<br />
import static org.junit.Assert.assertTrue;<br />
<br />
import org.junit.AfterClass;<br />
import org.junit.BeforeClass;<br />
import org.junit.Test;<br />
<br />
public class SchedulingPatternTest {<br />
<br />
@BeforeClass<br />
public static void testSetup() {<br />
}<br />
<br />
@AfterClass<br />
public static void testCleanup() {<br />
// Teardown for data used by the unit tests<br />
}<br />
<br />
@Test(expected = InvalidPatternException.class)<br />
public void testExceptionIsThrown() {<br />
SchedulingPattern sp = new SchedulingPattern("0 5 * *");<br />
}<br />
<br />
@Test<br />
public void testPattern() {<br />
String pattern;<br />
pattern="0 5 * * *|8 10 * * *|22 17 * * *";<br />
assertTrue(pattern + "is correct", SchedulingPattern.validate(pattern));<br />
pattern="0 5 * *";<br />
assertTrue(pattern + "is correct", SchedulingPattern.validate(pattern));<br />
}<br />
}<br />
</pre><br />
<br />
# Committez et Pushez ce nouveau fichier, pour que Travis lance les tests dès que possible<br />
# Lancez les tests unitaires avec <pre>mvn test</pre> Ce test va '''échouer''': corrigez le.<br />
# Committez et Pushez la version corrigée des tests: Travis enverra un mail pour indiquer si les tests échouent ou non<br />
#: '''Attention:''' Travis va exécuter les tests ''dès que possible''. Il est possible de recevoir un mail indiquant que les tests du premier ''push'' échouent alors que l'on a déjà ''pushé'' la correction.<br />
# Naviguez sur http://travis-ci.org pour vérifier les builds effectués.<br />
# Créez des tests unitaires supplémentaire du i.s.c.CronParser<br />
<br />
===[[Maven]] avec [[Travis-CI]]===<br />
<br />
===Git (suite)===<br />
<br />
# Forkez le projet '''tagl''' d'un autre binome (i.e. autre que ''donsez/tagl'')<br />
#: '''Attention:''' donnez lui un nom différent (e.g. ''tagl-licensing'')<br />
# Clonez ce nouveau dépôt<br />
# Lancez une compilation pour valider l'état du projet (bonne pratique)<br />
#:<pre>mvn clean verify</pre><br />
# Situez vous dans une nouvelle branch git:<br />
#:<pre>git checkout -b add-license</pre><br />
# Ajoutez une bannière de licence dans le fichier '''cron4j-mvn/pom.xml'''<br />
# Lancez une nouvelle compilation pour valider vos modifications<br />
# Commitez et pushez (vers votre fork de ce dépôt, i.e. ''tagl-licensing'') (pour pusher une branche nouvellement créée: git push origin add-license)<br />
# Via le site de GitHub, proposez un "Pull Request" au projet initial<br />
<br />
Vous pouvez ensuite supprimer le clone de ce fork.<br />
Lorsque le ''pull request'' aura été accepté, vous pourrez supprimer votre fork (''tagl-licensing'') de votre compte GitHub.<br />
<br />
===Contrôle Continu===<br />
<br />
Dans votre dépôt ''tagl''.<br />
<br />
# Ajoutez le plugin [http://mojo.codehaus.org/cobertura-maven-plugin/usage.html Cobertura] à votre projet Maven.<br />
## Configurez le plugin pour [http://mojo.codehaus.org/cobertura-maven-plugin/examples/report-formats.html générer un rapport] HTML. Le résultat se trouvera dans ''target/site/cobertura''<br />
## Le plugin ne s'exécute automatiquement pas durant la compilation, il faut utiliser la commande : <pre>mvn cobertura:cobertura</pre><br />
## '''Bonus:''' Modifiez le fichier ''pom.xml'' pour que le ''goal'' '''cobertura''' soit exécuté pendant la ''phase'' '''package'''.<br />
# Répondez aux questions : ''Mais qu'est ce que la couverture de code ? En quoi c'est utile ?''<br />
# Ajoutez au projet Maven les plugins pour la génération d'un site et de rapports (Javadoc, tests unitaires, tags list (FIXME, TODO, ...), ...): voir http://maven.apache.org/plugins/maven-site-plugin/ et d'autres.<br />
# Regardez les exemples d'utilisation de cron4j dans cron4j-original/examples<br />
# À rendre : pom.xml<br />
<br />
===Bonus Track===<br />
<br />
====Clone SVN -> Git====<br />
<br />
Source: http://www.yterium.net/Migrer-un-projet-SVN-vers-GIT<br />
<br />
<syntaxhighlight lang="bash"><br />
# Cloner le dépôt SVN en dépôt Git (conservation historique)<br />
$ git svn clone svn://svn.code.sf.net/p/cron4j/code/trunk cron4j-original<br />
$ cd cron4j-original<br />
# Test compilation<br />
$ ant jar<br />
$ cd ..<br />
</syntaxhighlight><br />
<br />
====Préparation TAGL====<br />
<br />
<syntaxhighlight lang="bash"><br />
# Clone du dépôt TAGL<br />
$ git clone git@github.com:donsez/tagl.git<br />
$ cd tagl<br />
# "Fetch" du dépôt local cloné précédemment<br />
$ git fetch file://$(pwd)/../cron4j-original<br />
# Fusion de ce qui vient d'être fetché<br />
$ git merge FETCH_HEAD<br />
# Envoi sur le serveur<br />
$ git push<br />
</syntaxhighlight><br />
<br />
<br />
====Cherry-picking: reprise des modifications d'un collègue====<br />
<br />
On considère que:<br />
<br />
* votre dépôt Git distant est à l'adresse URL_DEPOT<br />
* votre collègue a un dépôt Git à l'adresse URL_COLLEGUE<br />
<br />
<br />
<syntaxhighlight lang="bash"><br />
# Dossier temporaire<br />
cd /tmp<br />
<br />
# Clone de votre dépôt<br />
git clone URL_DEPOT mon_depot<br />
<br />
# Déplacement dans votre dépôt<br />
cd mon_depot<br />
<br />
# Définition du dépôt distant<br />
git remote add collegue URL_COLLEGUE<br />
<br />
# Récupération des infos du dépôt du collègue<br />
git fetch collegue<br />
<br />
# Maintenant, on peut voir les branches du collègue<br />
git branch -a<br />
<br />
# On peut fusionner avec une branche<br />
git merge collegue/master<br />
<br />
# Si vous avez des conflits, éditez les fichiers concernés,<br />
# et committez avec git commit<br />
<br />
# Push vers votre dépôt distant<br />
git push origin<br />
<br />
# Optionnel: supprimez la référence vers le dépôt du collègue<br />
git remote rm collegue<br />
</syntaxhighlight><br />
<br />
<br />
====Archetype webapp====<br />
L'archetype webapp (http://maven.apache.org/archetype/maven-archetype-bundles/maven-archetype-webapp/) permet de créer le squelette d'une webapp. Créez un simple webapp monsite en version 0.1.0. (add/commit/push). Vous pourrez tester cette webapp en ajoutant au pom.xml le [https://wiki.eclipse.org/Jetty/Feature/Jetty_Maven_Plugin plugin maven Jetty].<br />
<br />
<syntaxhighlight lang="bash"><br />
mvn -Djetty.port=9999 jetty:run<br />
</syntaxhighlight><br />
<br />
Naviguez sur http://localhost:9999/monsite<br />
<br />
====Scrum tools====<br />
Ces 3 services peuvent être couplé à votre dépôt GitHub pour votre gestion de projet agile avec [[Scrum]] :<br />
* http://www.acunote.com/<br />
* http://backlogtool.com/<br />
* http://www.scrumdo.com/<br />
<br />
L'activation se fait via ''Settings > Webhooks & Services > Configure services''.<br />
<br />
=Séance 4: AOP & AspectJ=<br />
<br />
Dans votre dépôt Git, projet ''cron4j-mvn''.<br />
<br />
# Ajoutez le [http://mojo.codehaus.org/aspectj-maven-plugin/ plugin Maven pour AspectJ] au pom.xml<br />
# Ajoutez un aspect de trace à l'invocation des méthodes '''run()''' de l'interface java.lang.Runnable (uniquement pour les objets ''schedulé''s)<br />
#: Affichez une trace avant et après l'exécution de la tâche<br />
# Préparez un nouveau test (nouvelle classe) démarrant un Scheduler Cron4j et validant l'exécution d'une tâche au bout d'une minute (pattern "* * * * *")<br />
#: Lors de l'exécution de '''mvn test''', vous devez voir apparaître les traces préparées dans votre aspect.<br />
<br />
Liens utiles:<br />
* [http://ridgetopsolutions.com/blog/2013/02/12/getting-started-with-aspectj-and-maven/ Getting started with AspectJ and Maven]<br />
<br />
===Contrôle continu===<br />
<br />
# Complétez l'aspect de trace avec le positionnement du [http://docs.oracle.com/javase/7/docs/api/java/lang/ThreadLocal.html java.lang.ThreadLocal] pour passer 1) l'identifiant du job et 2) le compteur des appels de la méthode de l'objet.<br />
<br />
=Séance 5: Pelix & iPOPO=<br />
<br />
Pelix est une plate-forme d'application à services (SOA).<br />
iPOPO est un modèle de composants orientés services (SOCM).<br />
<br />
La documentation de Pelix et iPOPO est disponible sur https://ipopo.coderxpress.net/<br />
<br />
===Installation de iPOPO===<br />
<br />
* Pour installer iPOPO, lancer la commande :<br />
<br />
pip install --user iPOPO<br />
<br />
* ou par les sources:<br />
** Cloner le dépôt Git depuis https://github.com/tcalmant/ipopo<br />
** Se placer dans la branche ''dev''<br />
** Lancer la commande:<br />
<br />
sudo python setup.py install<br />
<br />
===Shell Pelix===<br />
<br />
Pour lancer un shell Pelix, utilisez la commande:<br />
<br />
python -m pelix.shell.console<br />
<br />
Les commandes disponibles sont décrites ici: [https://ipopo.coderxpress.net/wiki/doku.php?id=ipopo:refcards:shell Shell Commands]<br />
<br />
===Rappels de Python===<br />
<br />
* Pas de déclaration du type d'une variable<br />
* Les méthodes d'une classe ont toute comme premier paramètre ''self'', équivalent du ''this'' en Java.<br />
* Blocs définis par indentation (4 espaces ou 1 tab)<br />
* Une ligne finissant par ':' démarre toujours un bloc<br />
<br />
<syntaxhighlight lang="python"><br />
#!/usr/bin/python<br />
# -- Content-Encoding: UTF-8 --<br />
# Import d'un module<br />
import pelix<br />
<br />
# Définition d'une classe<br />
class MaClasse:<br />
# Constructeur<br />
def __init__(self):<br />
self.default = "stanger"<br />
print("Classe construite")<br />
<br />
# Méthode, avec un argument<br />
def sayHello(self, name):<br />
if not name:<br />
# Nom vide ou nul<br />
return "Hello, " + str(self.default)<br />
else:<br />
# Nom valide<br />
return "Hello, " + str(name)<br />
<br />
objet = MaClasse()<br />
print(objet.sayHello(""))<br />
print(objet.sayHello("World"))<br />
</syntaxhighlight><br />
<br />
===Service Ping-Pong===<br />
<br />
1. Écrire un fichier ''pong.py'', définissant une classe ''Pong'' ayant une méthode ''pong'' prenant en paramètre un message et retournant le message préfixé par "PONG:".<br />
<br />
Exemple: <br />
<br />
pong = Pong()<br />
pong.pong("Hello") # <-- Retourne "PONG:Hello"<br />
<br />
2. Écrire un fichier ''ping.py'', définissant une classe ''Ping'' ayant une méthode ''ping'' prenant en paramètre un message, créant un objet Pong et retournant le résultat de Pong.pong(message) préfixé par "PING:"<br />
<br />
Exemple:<br />
<br />
ping = Ping()<br />
ping.ping("Hello") # <-- Retourne "PING:PONG:Hello"<br />
<br />
3. Transformer le fichier ''pong.py'' pour qu'il devienne un bundle Pelix enregistrant un objet Pong comme étant un service ayant pour spécification "tagl.pong"<br />
* Définir une classe ''Activator'', décorée avec ''@BundleActivator''<br />
* Enregistrer le service dans la méthode ''Activator.start'' et le désenregistrer dans ''Activator.stop''<br />
* S'inspirer du fichier "ipopo/samples/remote/provider.py"<br />
<br />
Dans un shell Pelix, installer et démarrer le bundle 'pong' et vérifier que le service est bien inscrit avec la commande ''sl''<br />
<br />
4.Transformer la classe ''Ping'' dans ''ping.py'' en un composant iPOPO<br />
* L'objet Pong utilisé dans ''ping()'' doit être un service injecté par iPOPO (''@Requires'')<br />
* Appeler la méthode ''ping()'' dès que le service Pong est injecté (''@BindField'') ou disparait (''@UnbindField'')<br />
* S'inspirer du fichier "ipopo/samples/remote/consumer.py"<br />
<br />
Dans un shell Pelix, installer et démarrer le bundle 'ping' et vérifier son comportement si le bundle ''pong'' ou le bundle ''ping'' est arrêté et redémarré.<br />
<br />
5. Mettre à jour le bundle ''pong''<br />
* Remplacer le préfixe "PONG" par "NI"<br />
* Dans le shell Pelix, mettre à jour le bundle ''pong'' sans redémarrer la plate-forme (commande ''udpate'').<br />
* Vérifier les traces dans le shell pour valider la mise à jour du service.<br />
<br />
===Remote Services===<br />
<br />
* Ajouter les propriétés permettant l'export du service Pong dans ''pong.py'' (s'inspirer de ''provider.py'')<br />
<br />
* Lancer deux shells iPOPO (dans deux terminaux)<br />
* Dans chaque shell iPOPO, installer les bundles:<br />
** ''pelix.remote.dispatcher'': Exportateur de services<br />
** ''pelix.remote.registry''; Importateur de services<br />
** ''pelix.remote.discovery.multicast'': Découverte de services via Multicast<br />
** ''pelix.remote.xml_rpc'': Transport XML-RPC<br />
** ''pelix.http.basic'': Serveur HTTP<br />
<br />
Attention: il peut être nécessaire de désactiver votre pare-feu pour que les Remote Services fonctionnent<br />
<br />
* Instancier les composants depuis le shell iPOPO, dans chaque framework:<br />
** Serveur HTTP sur le port 8080: ''instantiate pelix.http.service.basic.factory http-server pelix.http.port=8080'' (penser à changer de port dans chaque framework)<br />
** Multicast Discovery: ''instantiate pelix-remote-discovery-multicast-factory multicast-discovery''<br />
** XML-RPC Exporter: ''instantiate pelix-xmlrpc-exporter-factory xml-rpc-exporter''<br />
** XML-RPC Importer: ''instantiate pelix-xmlrpc-exporter-factory xml-rpc-importer''<br />
<br />
* Installer le bundle ''ping'' dans un des frameworks et le bundle ''pong'' dans l'autre.<br />
* Le composant ping peut appeler le service pong, qui est dans l'autre framework.<br />
<br />
<br />
* Voir le code de ''run_remote.py'' pour voir comment démarrer un framework Pelix et installer des bundles depuis Python.<br />
* Jouer un peu avec ''run_remote.py'' (voir ''run_remote.py --help'')<br />
<br />
=Séance 6=<br />
[[Tutorial OSGi avec Apache Felix]]<br />
<br />
=Séance 7=<br />
Faire un projet PDE pour un bundle cron4j.gogo (indépendant de cron4j.bundle)<br />
<br />
Utilisation de https://eclipse.org/tycho/</div>Calmanthttps://air.imag.fr/index.php?title=TAGL/TP&diff=22582TAGL/TP2015-03-27T07:22:28Z<p>Calmant: /* Séance 5: Pelix & iPOPO */</p>
<hr />
<div>Travaux pratiques de l'UE [[TAGL]].<br />
<br />
Anciennes versions : [[TAGL/TP 2014]]<br />
<br />
=Séance 1 : Gestion de versions=<br />
==Git==<br />
<br />
Création d'un dépôt Git local<br />
<br />
===Méthode simple: init first===<br />
<br />
Via cette méthode, on crée un dépôt local, avec un répertoire de travail, puis on pousse ses modifications vers un dépôt "bare".<br />
Cette méthode est la plus simple, car on dispose immédiatement d'un répertoire de travail.<br />
<br />
<syntaxhighlight lang="bash"><br />
# Création d'un dépôt Git dans le dossier simple-repo<br />
git init simple-repo<br />
<br />
# Création d'un README<br />
cd simple-repo<br />
echo "Hello, World" > README<br />
<br />
# Ajout du versionnement du fichier README<br />
git add README<br />
<br />
# Commit<br />
git commit<br />
</syntaxhighlight><br />
<br />
À ce niveau, on a un dépôt Git complètement fonctionnel.<br />
Cependant, il est intéressant de pousser ses modifications vers un autre dépôt, sur une autre machine.<br />
On va donc créer un dépôt bare sur une autre machine (ou autre dossier pour l'exemple)<br />
<br />
<syntaxhighlight lang="bash"><br />
git init --bare server-repo<br />
</syntaxhighlight><br />
<br />
On considère que l'URL pour accéder à ce dépôt est URL_REPO.<br />
On va d'abord ajouter ce dépôt serveur à la liste des dépôts connu-repos de votre dépôt local.<br />
Étant donné qu'il s'agit du dépôt "principal" à utiliser, on l'appellera //origin//, par convention.<br />
<br />
<syntaxhighlight lang="bash"><br />
git remote add origin URL_REPO<br />
# Récupération de ses informations<br />
git fetch origin<br />
</syntaxhighlight><br />
<br />
Ce serveur distant est "vide": il n'a aucune branche. On va donc enregistrer notre branche sur le serveur<br />
<br />
<syntaxhighlight lang="bash"><br />
git push origin master<br />
</syntaxhighlight><br />
<br />
À partir de cette commande, la branche locale //master// sera liée à la branche distante //origin/master//.<br />
Lors des prochaines commandes ''git push'', grâce à cette liaison, tous les commits sur la branche locale //master// seront poussées sur le serveur distant.<br />
<br />
===Méthode moins simple: bare first===<br />
<br />
Si on commence dans par le serveur "vide", il faudra le cloner au lieu de le définir comme un dépôt distant.<br />
<br />
<syntaxhighlight lang="bash"><br />
# Création du dépôt vide<br />
git init --bare server-repo<br />
</syntaxhighlight><br />
<br />
On considère que ce dépôt est accessible à l'URL URL_REPO<br />
<br />
<syntaxhighlight lang="bash"><br />
# Clonage du dépôt<br />
git clone URL_REPO clone-repo<br />
</syntaxhighlight><br />
<br />
Un avertissement indique que l'on clone un dépôt vide: le dépôt local à donc une branche master, mais elle n'est pas liée au dépôt distant, car celui-ci n'a aucune branche.<br />
Le dépôt distant est automatiquement appelé //origin//.<br />
<br />
<syntaxhighlight lang="bash"><br />
# Commit dans le dépôt local<br />
cd clone-repo<br />
echo hello > readme.rst<br />
git add readme.rst<br />
git commit et ses dépendances<br />
</syntaxhighlight><br />
<br />
Comme dans la méthode simple, il faut pousser la branche master vers le dépôt distant:<br />
<br />
<syntaxhighlight lang="bash"><br />
git push origin master<br />
</syntaxhighlight><br />
<br />
===De l'importance des README===<br />
<br />
Il est très important d'avoir au moins 2 fichiers dans votre dépôt Git:<br />
<br />
* LICENSE: contenant le texte **complet** de la licence de votre projet<br />
* README: décrivant votre projet et comment l'utiliser. Ce fichier doit rappeler le nom de la licence de votre projet<br />
<br />
Il est aussi recommandé d'avoir les fichiers suivants:<br />
<br />
* AUTHORS: contenant la liste des noms/pseudos et e-mails des auteurs de commits ou de code inclus dans ce projet<br />
* INSTALL: contenant la liste des dépendances de ce projet et des commandes à utiliser pour le compiler et l'installer<br />
<br />
Les fichiers LICENSE sont des fichiers textes bruts.<br />
Les autres fichiers sont généralement dans un format offrant un peu plus de lisibilté, par exemple dans les formats [http://daringfireball.net/projects/markdown/ Markdown] (.md) ou [http://docutils.sourceforge.net/rst.html reStructuredText] (.rst)<br />
<br />
Un plug-in existe pour éditer des fichier reStructuredText dans Eclipse: ReST Editor, disponible sur le [https://marketplace.eclipse.org/content/rest-editor Marketplace Eclipse]<br />
<br />
=Séance 2a: Intégration en continue=<br />
<br />
===GitHub & [[Travis-CI]]===<br />
<br />
Travis-CI est un service permettant d'exécuter un script dans une machine virtuelle Ubuntu dès que vous effectuez un push sur un de vos dépôts GitHub.<br />
L'intérêt est de savoir si la version d'un projet que vous avez rendu publique peut être compilée et si ses tests passent.<br />
<br />
La machine virtuelle "offerte" par Travis est préconfigurée pour le language indiqué dans son fichier de configuration ('''.travis.yml'''), mais il est possible d'utiliser la commande '''sudo apt-get install ...''' pour ajouter vos dépendances.<br />
<br />
<br />
<br />
Pour utiliser [[Travis-CI]]:<br />
<br />
# Créez compte individuel sur GitHub https://github.com<br />
# ''Fork''ez le dépôt https://github.com/heroku/node-js-getting-started<br />
# Ajoutez un collaborateur (i.e. votre binôme) au projet ''forké'', via les paramètres (''settings'') de ce projet<br />
# Pour l'exemple, activez le service (ou hook) ''Email'' depuis les paramètres du dépôt: à chaque fois que vous ou un de vos collaborateurs ferra un '''git push''', vous recevrez une notification par mail.<br />
# Activez le service Travis-CI: identifiez-vous (''sign in'') sur https://travis-ci.org/ avec votre compte GitHub<br />
# Activez le service pour les projets sur lesquels vous souhaitez appliquer les principes d'intégration continue<br />
<br />
[[Travis-CI]] utilise un fichier nommé '''.travis.yml''' (attention: fichier caché sous Unix) pour se configurer et choisir les opérations à effectuer.<br />
Ce fichier doit se trouver à la racine de votre dépôt Git.<br />
<br />
Faites un '''Commit''' puis un '''Push''' du fichier '''.travis.yml''' ci-dessous.<br />
<br />
<pre><br />
language: node_js<br />
node_js:<br />
- "0.11"<br />
- "0.10"<br />
- "0.8"<br />
- "0.6"<br />
- iojs<br />
- iojs-v1.0.2<br />
<br />
</pre><br />
<br />
<br />
Ce fichier '''.travis.yml''' indique à [[Travis-CI]] que les scripts de ce projet dans ce dépôt seront exécutés avec plusieurs versions de [[Node.js]].<br />
<br />
Ajoutez dans le fichier '''package.json''' la section suivante:<br />
<pre><br />
"devDependencies": {<br />
"jshint": "^2.6.0"<br />
},<br />
"scripts": {<br />
"test": "./node_modules/jshint/bin/jshint index.js"<br />
}<br />
</pre><br />
et incrémentez le numéro de version.<br />
<br />
Faites un '''Commit''' puis un '''Push''' des fichiers touchés.<br />
<br />
<br />
'''Remarque:'''<br />
'''jshint''' peut être lancé localement avec les commandes suivantes:<br />
<pre><br />
sudo npm install jshint<br />
jshint index.js<br />
</pre><br />
<br />
A lire<br />
* http://docs.travis-ci.com/user/languages/javascript-with-nodejs/<br />
* https://github.com/docdis/learn-travis/blob/master/README.md<br />
<br />
=Séance 2b: Livraison en continue=<br />
<br />
==[[Heroku]]==<br />
[https://www.heroku.com/ Heroku] est une plateforme cloud de type PaaS permettant l'exécution d'applications et de services en ligne écrits dans les langages et plateformes suivantes : Ruby, [[Node.js]], [[Python]], Java, et PHP.<br />
<br />
# Créez un compte gratuit sur [https://signup.heroku.com Heroku]<br />
# Forkez le dépôt https://github.com/heroku/node-js-getting-started<br />
# Dans Heroku, créez une nouvelle app Node.js, et liez-la au repository Github créé à l'étape précédente<br />
# Choisissez l'option "Déploiement automatique" depuis la branche **master**<br />
# Modifiez le fichier index.js pour afficher la version de service dans la page HTML<br />
<pre><br />
var fs = require('fs');<br />
var package = JSON.parse(fs.readFileSync('./package.json', 'utf8'));<br />
var version=package.version;<br />
...<br />
response.send('Hello World! (current version: '+version+')');<br />
...<br />
</pre><br />
<br />
Incrémentez le numéro de version dans le fichier ''package.json''<br />
<br />
Faites un '''Commit''' puis un '''Push''' des fichiers touchés.<br />
<br />
Naviguez l'application sur Heroku<br />
<br />
# Modifiez le fichier index.js pour franciser le message dans la page HTML<br />
<pre><br />
...<br />
response.send('Bonjour Tout Le Monde! (version courante: '+version+')');<br />
...<br />
</pre><br />
<br />
Incrémentez le numéro de version dans le fichier '''package.json''<br />
<br />
Faites un '''Commit''' puis un '''Push''' des fichiers touchés.<br />
<br />
Naviguez l'application sur Heroku<br />
<br />
=Séance 3: Builders=<br />
Les builders permettent d'automatiser l'exécution en chaine des outils pour la production et la livraison en production des produits logiciels.<br />
<br />
==[[Make]]==<br />
<br />
==[[Ant]]==<br />
<br />
Faire les exercices 0, 1, 3 de ./tpant.htm dans http://lig-membres.imag.fr/donsez/cours/tpant.zip<br />
<br />
==[[Maven]]==<br />
<br />
[http://maven.apache.org/download.cgi Charger et installer Maven 3].<br />
<br />
Debian/Ubuntu & friends:<br />
<pre><br />
sudo apt-get update && sudo apt-get install maven<br />
</pre><br />
<br />
<pre><br />
mvn -version<br />
</pre><br />
<br />
Faites une copie du projet, basée sur Maven:<br />
<br />
# Dans votre dépôt Git, créez un dossier '''cron4j-mvn''': il contiendra le projet Cron4J avec la structure Maven<br />
# Dans ce dossier, utilisez l'[https://maven.apache.org/guides/introduction/introduction-to-archetypes.html archetype] Maven [http://maven.apache.org/archetype/maven-archetype-bundles/maven-archetype-quickstart/ maven-archetype-quickstart] (la version des sources de cron4j utilisés est la 2.5.5) (groupId: it.sauronsoftware.cron4j, artifactId: cron4j):<br />
#:<pre>mvn archetype:generate -DarchetypeGroupId=org.apache.maven.archetypes -DarchetypeArtifactId=maven-archetype-quickstart</pre><br />
# Cette commande crée un projet avec un fichier ''pom.xml'', et une classe et un test modèles: supprimez ces modèles<br />
# Copiez les sources de Cron4J depuis le dossier '''cron4j-original''' ([https://github.com/donsez/tagl https://github.com/donsez/tagl]) dans le dossier '''src/main/java''' de votre projet Maven<br />
# Faites un essai de compilation:<br />
#:<pre>mvn clean verify</pre><br />
# Lancez un des exemples avec mvn exec:java -Dexec.mainClass="com.example.Main" [-Dexec.args="argument1"] ... ([http://mojo.codehaus.org/exec-maven-plugin/usage.html doc. exec plugin], [http://mojo.codehaus.org/exec-maven-plugin/java-mojo.html doc. Exec:java goal])<br />
# Enfin modifiez le fichier '''.travis.yml''' à la racine de votre dépôt Git afin que Travis exécute la commande '''mvn clean verify''' à chaque mise à jour du dépôt GitHub.<br />
<br />
==Tests Unitaires avec JUnit 4==<br />
Survoller le tutoriel [http://www.vogella.com/tutorials/JUnit/article.html Unit Testing with JUnit]<br />
<br />
# Veillez à bien utiliser la dépendance JUnit 4.8.2 dans pom.xml<br />
# Ajouter le test unitaire suivant au projet, dans le fichier '''src/test/it/sauronsoftware/SchedulingPatternTest.java<br />
<pre><br />
package it.sauronsoftware;<br />
<br />
import it.sauronsoftware.cron4j.SchedulingPattern;<br />
import it.sauronsoftware.cron4j.InvalidPatternException;<br />
<br />
import static org.junit.Assert.assertEquals;<br />
import static org.junit.Assert.assertTrue;<br />
<br />
import org.junit.AfterClass;<br />
import org.junit.BeforeClass;<br />
import org.junit.Test;<br />
<br />
public class SchedulingPatternTest {<br />
<br />
@BeforeClass<br />
public static void testSetup() {<br />
}<br />
<br />
@AfterClass<br />
public static void testCleanup() {<br />
// Teardown for data used by the unit tests<br />
}<br />
<br />
@Test(expected = InvalidPatternException.class)<br />
public void testExceptionIsThrown() {<br />
SchedulingPattern sp = new SchedulingPattern("0 5 * *");<br />
}<br />
<br />
@Test<br />
public void testPattern() {<br />
String pattern;<br />
pattern="0 5 * * *|8 10 * * *|22 17 * * *";<br />
assertTrue(pattern + "is correct", SchedulingPattern.validate(pattern));<br />
pattern="0 5 * *";<br />
assertTrue(pattern + "is correct", SchedulingPattern.validate(pattern));<br />
}<br />
}<br />
</pre><br />
<br />
# Committez et Pushez ce nouveau fichier, pour que Travis lance les tests dès que possible<br />
# Lancez les tests unitaires avec <pre>mvn test</pre> Ce test va '''échouer''': corrigez le.<br />
# Committez et Pushez la version corrigée des tests: Travis enverra un mail pour indiquer si les tests échouent ou non<br />
#: '''Attention:''' Travis va exécuter les tests ''dès que possible''. Il est possible de recevoir un mail indiquant que les tests du premier ''push'' échouent alors que l'on a déjà ''pushé'' la correction.<br />
# Naviguez sur http://travis-ci.org pour vérifier les builds effectués.<br />
# Créez des tests unitaires supplémentaire du i.s.c.CronParser<br />
<br />
===[[Maven]] avec [[Travis-CI]]===<br />
<br />
===Git (suite)===<br />
<br />
# Forkez le projet '''tagl''' d'un autre binome (i.e. autre que ''donsez/tagl'')<br />
#: '''Attention:''' donnez lui un nom différent (e.g. ''tagl-licensing'')<br />
# Clonez ce nouveau dépôt<br />
# Lancez une compilation pour valider l'état du projet (bonne pratique)<br />
#:<pre>mvn clean verify</pre><br />
# Situez vous dans une nouvelle branch git:<br />
#:<pre>git checkout -b add-license</pre><br />
# Ajoutez une bannière de licence dans le fichier '''cron4j-mvn/pom.xml'''<br />
# Lancez une nouvelle compilation pour valider vos modifications<br />
# Commitez et pushez (vers votre fork de ce dépôt, i.e. ''tagl-licensing'') (pour pusher une branche nouvellement créée: git push origin add-license)<br />
# Via le site de GitHub, proposez un "Pull Request" au projet initial<br />
<br />
Vous pouvez ensuite supprimer le clone de ce fork.<br />
Lorsque le ''pull request'' aura été accepté, vous pourrez supprimer votre fork (''tagl-licensing'') de votre compte GitHub.<br />
<br />
===Contrôle Continu===<br />
<br />
Dans votre dépôt ''tagl''.<br />
<br />
# Ajoutez le plugin [http://mojo.codehaus.org/cobertura-maven-plugin/usage.html Cobertura] à votre projet Maven.<br />
## Configurez le plugin pour [http://mojo.codehaus.org/cobertura-maven-plugin/examples/report-formats.html générer un rapport] HTML. Le résultat se trouvera dans ''target/site/cobertura''<br />
## Le plugin ne s'exécute automatiquement pas durant la compilation, il faut utiliser la commande : <pre>mvn cobertura:cobertura</pre><br />
## '''Bonus:''' Modifiez le fichier ''pom.xml'' pour que le ''goal'' '''cobertura''' soit exécuté pendant la ''phase'' '''package'''.<br />
# Répondez aux questions : ''Mais qu'est ce que la couverture de code ? En quoi c'est utile ?''<br />
# Ajoutez au projet Maven les plugins pour la génération d'un site et de rapports (Javadoc, tests unitaires, tags list (FIXME, TODO, ...), ...): voir http://maven.apache.org/plugins/maven-site-plugin/ et d'autres.<br />
# Regardez les exemples d'utilisation de cron4j dans cron4j-original/examples<br />
# À rendre : pom.xml<br />
<br />
===Bonus Track===<br />
<br />
====Clone SVN -> Git====<br />
<br />
Source: http://www.yterium.net/Migrer-un-projet-SVN-vers-GIT<br />
<br />
<syntaxhighlight lang="bash"><br />
# Cloner le dépôt SVN en dépôt Git (conservation historique)<br />
$ git svn clone svn://svn.code.sf.net/p/cron4j/code/trunk cron4j-original<br />
$ cd cron4j-original<br />
# Test compilation<br />
$ ant jar<br />
$ cd ..<br />
</syntaxhighlight><br />
<br />
====Préparation TAGL====<br />
<br />
<syntaxhighlight lang="bash"><br />
# Clone du dépôt TAGL<br />
$ git clone git@github.com:donsez/tagl.git<br />
$ cd tagl<br />
# "Fetch" du dépôt local cloné précédemment<br />
$ git fetch file://$(pwd)/../cron4j-original<br />
# Fusion de ce qui vient d'être fetché<br />
$ git merge FETCH_HEAD<br />
# Envoi sur le serveur<br />
$ git push<br />
</syntaxhighlight><br />
<br />
<br />
====Cherry-picking: reprise des modifications d'un collègue====<br />
<br />
On considère que:<br />
<br />
* votre dépôt Git distant est à l'adresse URL_DEPOT<br />
* votre collègue a un dépôt Git à l'adresse URL_COLLEGUE<br />
<br />
<br />
<syntaxhighlight lang="bash"><br />
# Dossier temporaire<br />
cd /tmp<br />
<br />
# Clone de votre dépôt<br />
git clone URL_DEPOT mon_depot<br />
<br />
# Déplacement dans votre dépôt<br />
cd mon_depot<br />
<br />
# Définition du dépôt distant<br />
git remote add collegue URL_COLLEGUE<br />
<br />
# Récupération des infos du dépôt du collègue<br />
git fetch collegue<br />
<br />
# Maintenant, on peut voir les branches du collègue<br />
git branch -a<br />
<br />
# On peut fusionner avec une branche<br />
git merge collegue/master<br />
<br />
# Si vous avez des conflits, éditez les fichiers concernés,<br />
# et committez avec git commit<br />
<br />
# Push vers votre dépôt distant<br />
git push origin<br />
<br />
# Optionnel: supprimez la référence vers le dépôt du collègue<br />
git remote rm collegue<br />
</syntaxhighlight><br />
<br />
<br />
====Archetype webapp====<br />
L'archetype webapp (http://maven.apache.org/archetype/maven-archetype-bundles/maven-archetype-webapp/) permet de créer le squelette d'une webapp. Créez un simple webapp monsite en version 0.1.0. (add/commit/push). Vous pourrez tester cette webapp en ajoutant au pom.xml le [https://wiki.eclipse.org/Jetty/Feature/Jetty_Maven_Plugin plugin maven Jetty].<br />
<br />
<syntaxhighlight lang="bash"><br />
mvn -Djetty.port=9999 jetty:run<br />
</syntaxhighlight><br />
<br />
Naviguez sur http://localhost:9999/monsite<br />
<br />
====Scrum tools====<br />
Ces 3 services peuvent être couplé à votre dépôt GitHub pour votre gestion de projet agile avec [[Scrum]] :<br />
* http://www.acunote.com/<br />
* http://backlogtool.com/<br />
* http://www.scrumdo.com/<br />
<br />
L'activation se fait via ''Settings > Webhooks & Services > Configure services''.<br />
<br />
=Séance 4: AOP & AspectJ=<br />
<br />
Dans votre dépôt Git, projet ''cron4j-mvn''.<br />
<br />
# Ajoutez le [http://mojo.codehaus.org/aspectj-maven-plugin/ plugin Maven pour AspectJ] au pom.xml<br />
# Ajoutez un aspect de trace à l'invocation des méthodes '''run()''' de l'interface java.lang.Runnable (uniquement pour les objets ''schedulé''s)<br />
#: Affichez une trace avant et après l'exécution de la tâche<br />
# Préparez un nouveau test (nouvelle classe) démarrant un Scheduler Cron4j et validant l'exécution d'une tâche au bout d'une minute (pattern "* * * * *")<br />
#: Lors de l'exécution de '''mvn test''', vous devez voir apparaître les traces préparées dans votre aspect.<br />
<br />
Liens utiles:<br />
* [http://ridgetopsolutions.com/blog/2013/02/12/getting-started-with-aspectj-and-maven/ Getting started with AspectJ and Maven]<br />
<br />
===Contrôle continu===<br />
<br />
# Complétez l'aspect de trace avec le positionnement du [http://docs.oracle.com/javase/7/docs/api/java/lang/ThreadLocal.html java.lang.ThreadLocal] pour passer 1) l'identifiant du job et 2) le compteur des appels de la méthode de l'objet.<br />
<br />
=Séance 5: Pelix & iPOPO=<br />
<br />
Pelix est une plate-forme d'application à services (SOA).<br />
iPOPO est un modèle de composants orientés services (SOCM).<br />
<br />
La documentation de Pelix et iPOPO est disponible sur https://ipopo.coderxpress.net/<br />
<br />
===Installation de iPOPO===<br />
<br />
* Pour installer iPOPO, lancer la commande :<br />
<br />
pip install --user iPOPO<br />
<br />
* ou par les sources:<br />
** Cloner le dépôt Git depuis https://github.com/tcalmant/ipopo<br />
** Se placer dans la branche ''dev''<br />
** Lancer la commande:<br />
<br />
sudo python setup.py install<br />
<br />
===Shell Pelix===<br />
<br />
Pour lancer un shell Pelix, utilisez la commande:<br />
<br />
python -m pelix.shell.console<br />
<br />
Les commandes disponibles sont décrites ici: [https://ipopo.coderxpress.net/wiki/doku.php?id=ipopo:refcards:shell Shell Commands]<br />
<br />
===Rappels de Python===<br />
<br />
* Pas de déclaration du type d'une variable<br />
* Les méthodes d'une classe ont toute comme premier paramètre ''self'', équivalent du ''this'' en Java.<br />
* Blocs définis par indentation (4 espaces ou 1 tab)<br />
* Une ligne finissant par ':' démarre toujours un bloc<br />
<br />
<syntaxhighlight lang="python"><br />
# Import d'un module<br />
import pelix<br />
<br />
# Définition d'une classe<br />
class MaClasse:<br />
# Constructeur<br />
def __init__(self):<br />
self.default = "stanger"<br />
print("Classe construite")<br />
<br />
# Méthode, avec un argument<br />
def sayHello(self, name):<br />
if not name:<br />
# Nom vide ou nul<br />
return "Hello, " + str(self.default)<br />
else:<br />
# Nom valide<br />
return "Hello, " + str(name)<br />
<br />
objet = MaClasse()<br />
print(objet.sayHello(""))<br />
print(objet.sayHello("World"))<br />
</syntaxhighlight><br />
<br />
===Service Ping-Pong===<br />
<br />
1. Écrire un fichier ''pong.py'', définissant une classe ''Pong'' ayant une méthode ''pong'' prenant en paramètre un message et retournant le message préfixé par "PONG:".<br />
<br />
Exemple: <br />
<br />
pong = Pong()<br />
pong.pong("Hello") # <-- Retourne "PONG:Hello"<br />
<br />
2. Écrire un fichier ''ping.py'', définissant une classe ''Ping'' ayant une méthode ''ping'' prenant en paramètre un message, créant un objet Pong et retournant le résultat de Pong.pong(message) préfixé par "PING:"<br />
<br />
Exemple:<br />
<br />
ping = Ping()<br />
ping.ping("Hello") # <-- Retourne "PING:PONG:Hello"<br />
<br />
3. Transformer le fichier ''pong.py'' pour qu'il devienne un bundle Pelix enregistrant un objet Pong comme étant un service ayant pour spécification "tagl.pong"<br />
* Définir une classe ''Activator'', décorée avec ''@BundleActivator''<br />
* Enregistrer le service dans la méthode ''Activator.start'' et le désenregistrer dans ''Activator.stop''<br />
* S'inspirer du fichier "ipopo/samples/remote/provider.py"<br />
<br />
Dans un shell Pelix, installer et démarrer le bundle 'pong' et vérifier que le service est bien inscrit avec la commande ''sl''<br />
<br />
4.Transformer la classe ''Ping'' dans ''ping.py'' en un composant iPOPO<br />
* L'objet Pong utilisé dans ''ping()'' doit être un service injecté par iPOPO (''@Requires'')<br />
* Appeler la méthode ''ping()'' dès que le service Pong est injecté (''@BindField'') ou disparait (''@UnbindField'')<br />
* S'inspirer du fichier "ipopo/samples/remote/consumer.py"<br />
<br />
Dans un shell Pelix, installer et démarrer le bundle 'ping' et vérifier son comportement si le bundle ''pong'' ou le bundle ''ping'' est arrêté et redémarré.<br />
<br />
5. Mettre à jour le bundle ''pong''<br />
* Remplacer le préfixe "PONG" par "NI"<br />
* Dans le shell Pelix, mettre à jour le bundle ''pong'' sans redémarrer la plate-forme (commande ''udpate'').<br />
* Vérifier les traces dans le shell pour valider la mise à jour du service.<br />
<br />
===Remote Services===<br />
<br />
* Ajouter les propriétés permettant l'export du service Pong dans ''pong.py'' (s'inspirer de ''provider.py'')<br />
<br />
* Lancer deux shells iPOPO (dans deux terminaux)<br />
* Dans chaque shell iPOPO, installer les bundles:<br />
** ''pelix.remote.dispatcher'': Exportateur de services<br />
** ''pelix.remote.registry''; Importateur de services<br />
** ''pelix.remote.discovery.multicast'': Découverte de services via Multicast<br />
** ''pelix.remote.xml_rpc'': Transport XML-RPC<br />
** ''pelix.http.basic'': Serveur HTTP<br />
<br />
Attention: il peut être nécessaire de désactiver votre pare-feu pour que les Remote Services fonctionnent<br />
<br />
* Instancier les composants depuis le shell iPOPO, dans chaque framework:<br />
** Serveur HTTP sur le port 8080: ''instantiate pelix.http.service.basic.factory http-server pelix.http.port=8080'' (penser à changer de port dans chaque framework)<br />
** Multicast Discovery: ''instantiate pelix-remote-discovery-multicast-factory multicast-discovery''<br />
** XML-RPC Exporter: ''instantiate pelix-xmlrpc-exporter-factory xml-rpc-exporter''<br />
** XML-RPC Importer: ''instantiate pelix-xmlrpc-exporter-factory xml-rpc-importer''<br />
<br />
* Installer le bundle ''ping'' dans un des frameworks et le bundle ''pong'' dans l'autre.<br />
* Le composant ping peut appeler le service pong, qui est dans l'autre framework.<br />
<br />
<br />
* Voir le code de ''run_remote.py'' pour voir comment démarrer un framework Pelix et installer des bundles depuis Python.<br />
* Jouer un peu avec ''run_remote.py'' (voir ''run_remote.py --help'')<br />
<br />
=Séance 6=<br />
[[Tutorial OSGi avec Apache Felix]]<br />
<br />
=Séance 7=<br />
Faire un projet PDE pour un bundle cron4j.gogo (indépendant de cron4j.bundle)<br />
<br />
Utilisation de https://eclipse.org/tycho/</div>Calmanthttps://air.imag.fr/index.php?title=TAGL/TP&diff=16646TAGL/TP2014-04-04T14:59:51Z<p>Calmant: /* Remote Services */</p>
<hr />
<div>Travaux pratiques de l'UE [[TAGL]].<br />
<br />
==Séance 1==<br />
===Git===<br />
<br />
Création d'un dépôt Git local<br />
<br />
====Méthode simple: init first====<br />
<br />
Via cette méthode, on crée un dépôt local, avec un répertoire de travail, puis on pousse ses modifications vers un dépôt "bare".<br />
Cette méthode est la plus simple, car on dispose immédiatement d'un répertoire de travail.<br />
<br />
<syntaxhighlight lang="bash"><br />
# Création d'un dépôt Git dans le dossier simple-repo<br />
git init simple-repo<br />
<br />
# Création d'un README<br />
cd simple-repo<br />
echo "Hello, World" > README<br />
<br />
# Ajout du versionnement du fichier README<br />
git add README<br />
<br />
# Commit<br />
git commit<br />
</syntaxhighlight><br />
<br />
À ce niveau, on a un dépôt Git complètement fonctionnel.<br />
Cependant, il est intéressant de pousser ses modifications vers un autre dépôt, sur une autre machine.<br />
On va donc créer un dépôt bare sur une autre machine (ou autre dossier pour l'exemple)<br />
<br />
<syntaxhighlight lang="bash"><br />
git init --bare server-repo<br />
</syntaxhighlight><br />
<br />
On considère que l'URL pour accéder à ce dépôt est URL_REPO.<br />
On va d'abord ajouter ce dépôt serveur à la liste des dépôts connu-repos de votre dépôt local.<br />
Étant donné qu'il s'agit du dépôt "principal" à utiliser, on l'appellera //origin//, par convention.<br />
<br />
<syntaxhighlight lang="bash"><br />
git remote add origin URL_REPO<br />
# Récupération de ses informations<br />
git fetch origin<br />
</syntaxhighlight><br />
<br />
Ce serveur distant est "vide": il n'a aucune branche. On va donc enregistrer notre branche sur le serveur<br />
<br />
<syntaxhighlight lang="bash"><br />
git push origin master<br />
</syntaxhighlight><br />
<br />
À partir de cette commande, la branche locale //master// sera liée à la branche distante //origin/master//.<br />
Lors des prochaines commandes ''git push'', grâce à cette liaison, tous les commits sur la branche locale //master// seront poussées sur le serveur distant.<br />
<br />
====Méthode moins simple: bare first====<br />
<br />
Si on commence dans par le serveur "vide", il faudra le cloner au lieu de le définir comme un dépôt distant.<br />
<br />
<syntaxhighlight lang="bash"><br />
# Création du dépôt vide<br />
git init --bare server-repo<br />
</syntaxhighlight><br />
<br />
On considère que ce dépôt est accessible à l'URL URL_REPO<br />
<br />
<syntaxhighlight lang="bash"><br />
# Clonage du dépôt<br />
git clone URL_REPO clone-repo<br />
</syntaxhighlight><br />
<br />
Un avertissement indique que l'on clone un dépôt vide: le dépôt local à donc une branche master, mais elle n'est pas liée au dépôt distant, car celui-ci n'a aucune branche.<br />
Le dépôt distant est automatiquement appelé //origin//.<br />
<br />
<syntaxhighlight lang="bash"><br />
# Commit dans le dépôt local<br />
cd clone-repo<br />
echo hello > readme.rst<br />
git add readme.rst<br />
git commit et ses dépendances<br />
</syntaxhighlight><br />
<br />
Comme dans la méthode simple, il faut pousser la branche master vers le dépôt distant:<br />
<br />
<syntaxhighlight lang="bash"><br />
git push origin master<br />
</syntaxhighlight><br />
<br />
===De l'importance des README===<br />
<br />
Il est très important d'avoir au moins 2 fichiers dans votre dépôt Git:<br />
<br />
* LICENSE: contenant le texte **complet** de la licence de votre projet<br />
* README: décrivant votre projet et comment l'utiliser. Ce fichier doit rappeler le nom de la licence de votre projet<br />
<br />
Il est aussi recommandé d'avoir les fichiers suivants:<br />
<br />
* AUTHORS: contenant la liste des noms/pseudos et e-mails des auteurs de commits ou de code inclus dans ce projet<br />
* INSTALL: contenant la liste des dépendances de ce projet et des commandes à utiliser pour le compiler et l'installer<br />
<br />
Les fichiers LICENSE sont des fichiers textes bruts.<br />
Les autres fichiers sont généralement dans un format offrant un peu plus de lisibilté, par exemple dans les formats [http://daringfireball.net/projects/markdown/ Markdown] (.md) ou [http://docutils.sourceforge.net/rst.html reStructuredText] (.rst)<br />
<br />
Un plug-in existe pour éditer des fichier reStructuredText dans Eclipse: ReST Editor, disponible sur le [https://marketplace.eclipse.org/content/rest-editor Marketplace Eclipse]<br />
<br />
===GitHub & Travis-CI===<br />
<br />
Travis-CI est un service permettant d'exécuter un script dans une machine virtuelle Ubuntu dès que vous effectuez un push sur un de vos dépôts GitHub.<br />
L'intérêt est de savoir si la version d'un projet que vous avez rendu publique peut être compilée et si ses tests passent.<br />
<br />
La machine virtuelle "offerte" par Travis est préconfigurée pour le language indiqué dans son fichier de configuration ('''.travis.yml'''), mais il est possible d'utiliser la commande '''sudo apt-get install ...''' pour ajouter vos dépendances.<br />
<br />
Pour utiliser Travis:<br />
<br />
# Créez compte individuel sur GitHub https://github.com<br />
# ''Fork''ez le projet TAGL '''cron4j''' depuis https://github.com/donsez/tagl<br />
# Ajoutez un collaborateur (i.e. votre binôme) au projet ''forké'', via les paramètres (''settings'') de ce projet<br />
# Pour l'exemple, activez le service (ou hook) ''Email'' depuis les paramètres du dépôt: à chaque fois que vous ou un de vos collaborateurs ferra un '''git push''', vous recevrez une notification par mail.<br />
# Activez le service Travis-CI: identifiez-vous (''sign in'') sur https://travis-ci.org/ avec votre compte GitHub<br />
# Activez le service pour les projets sur lesquels vous souhaitez appliquer les principes d'intégration continue<br />
<br />
Travis-CI utilise un fichier nommé '''.travis.yml''' (attention: fichier caché sous Unix) pour se configurer et choisir les opérations à effectuer.<br />
Ce fichier doit se trouver à la racine de votre dépôt Git.<br />
<br />
Faites un '''Commit''' puis un '''Push''' du fichier '''.travis.yml''' ci-dessous.<br />
<br />
<pre><br />
language: java<br />
<br />
jdk:<br />
- oraclejdk7<br />
- openjdk6<br />
- openjdk7<br />
<br />
script:<br />
- pushd cron4j-original && ant rel && popd<br />
</pre><br />
<br />
Ce fichier indique que le projet dans ce dépôt doit être testé sur 3 versions de Java (Oracle Java 7, Open JDK 6 et Open JDK 7), et que le script à exécuter pour lancer les tests est '''pushd cron4j-original && ant rel && popd'''.<br />
Travis-CI peut exécuter plusieurs commandes dans script, chacune d'entre elles devant démarrer par un '-' (élément dans une liste de 'scripts').<br />
<br />
Attention: il n'est pas possible d'utiliser '''cd''' pour changer de répertoire, il faut utiliser '''pushd''' (déplacement dans un dossier) et '''popd''' (retour au dossier précédent) à la place.<br />
<br />
Une fois ce fichier de configuration '''pushé''', Travis-CI se mettra en route dès le prochain '''push'''.<br />
<br />
===Maven===<br />
<br />
[http://maven.apache.org/download.cgi Charger et installer Maven 3].<br />
<br />
<pre><br />
mvn -version<br />
</pre><br />
<br />
Faites une copie du projet, basée sur Maven:<br />
<br />
# Dans votre dépôt Git, créez un dossier '''cron4j-mvn''': il contiendra le projet Cron4J avec la structure Maven<br />
# Dans ce dossier, utilisez l'[https://maven.apache.org/guides/introduction/introduction-to-archetypes.html archetype] Maven [http://maven.apache.org/archetype/maven-archetype-bundles/maven-archetype-quickstart/ maven-archetype-quickstart] (la version des sources de cron4j utilisés est la 2.5.5):<br />
#:<pre>mvn archetype:generate -DarchetypeGroupId=org.apache.maven.archetypes -DarchetypeArtifactId=maven-archetype-quickstart</pre><br />
# Cette commande crée un projet avec un fichier ''pom.xml'', et une classe et un test modèles: supprimez ces modèles<br />
# Copiez les sources de Cron4J depuis le dossier '''cron4j-original''' dans le dossier '''src/main/java''' de votre projet Maven<br />
# Faites un essai de compilation:<br />
#:<pre>mvn clean verify</pre><br />
# Enfin modifiez le fichier '''.travis.yml''' à la racine de votre dépôt Git afin que Travis exécute la commande '''mvn clean verify''' à chaque mise à jour du dépôt GitHub.<br />
<br />
===Tests Unitaires avec JUnit 4===<br />
Survoller le tutoriel [http://www.vogella.com/tutorials/JUnit/article.html Unit Testing with JUnit]<br />
<br />
# Ajouter le test unitaire suivant au projet, dans le fichier '''src/test/it/sauronsoftware/SchedulingPatternTest.java<br />
<pre><br />
package it.sauronsoftware;<br />
<br />
import it.sauronsoftware.cron4j.SchedulingPattern;<br />
import it.sauronsoftware.cron4j.InvalidPatternException;<br />
<br />
import static org.junit.Assert.assertEquals;<br />
import static org.junit.Assert.assertTrue;<br />
<br />
import org.junit.AfterClass;<br />
import org.junit.BeforeClass;<br />
import org.junit.Test;<br />
<br />
public class SchedulingPatternTest {<br />
<br />
@BeforeClass<br />
public static void testSetup() {<br />
}<br />
<br />
@AfterClass<br />
public static void testCleanup() {<br />
// Teardown for data used by the unit tests<br />
}<br />
<br />
@Test(expected = InvalidPatternException.class)<br />
public void testExceptionIsThrown() {<br />
SchedulingPattern sp = new SchedulingPattern("0 5 * *");<br />
}<br />
<br />
@Test<br />
public void testPattern() {<br />
String pattern;<br />
pattern="0 5 * * *|8 10 * * *|22 17 * * *";<br />
assertTrue(pattern + "is correct", SchedulingPattern.validate(pattern));<br />
pattern="0 5 * *";<br />
assertTrue(pattern + "is correct", SchedulingPattern.validate(pattern));<br />
}<br />
}<br />
</pre><br />
<br />
# Committez et Pushez ce nouveau fichier, pour que Travis lance les tests dès que possible<br />
# Lancez les tests unitaires avec <pre>mvn test</pre> Ce test va '''échouer''': corrigez le.<br />
# Committez et Pushez la version corrigée des tests: Travis enverra un mail pour indiquer si les tests échouent ou non<br />
#: '''Attention:''' Travis va exécuter les tests ''dès que possible''. Il est possible de recevoir un mail indiquant que les tests du premier ''push'' échouent alors que l'on a déjà ''pushé'' la correction.<br />
# Naviguez sur http://travis-ci.org pour vérifier les builds effectués.<br />
# Créez des tests unitaires supplémentaire du i.s.c.CronParser<br />
<br />
===Git (suite)===<br />
<br />
# Forkez le projet '''tagl''' d'un autre binome (i.e. autre que ''donsez/tagl'')<br />
#: '''Attention:''' donnez lui un nom différent (e.g. ''tagl-licensing'')<br />
# Clonez ce nouveau dépôt<br />
# Lancez une compilation pour valider l'état du projet (bonne pratique)<br />
#:<pre>mvn clean verify</pre><br />
# Ajoutez une bannière de licence dans le fichier '''cron4j-mvn/pom.xml'''<br />
# Lancez une nouvelle compilation pour valider vos modifications<br />
# Commitez et pushez (vers votre fork de ce dépôt, i.e. ''tagl-licensing'')<br />
# Via le site de GitHub, proposez un "Pull Request" au projet initial<br />
<br />
Vous pouvez ensuite supprimer le clone de ce fork.<br />
Lorsque le ''pull request'' aura été accepté, vous pourrez supprimer votre fork (''tagl-licensing'') de votre compte GitHub.<br />
<br />
===Contrôle Continu===<br />
<br />
Dans votre dépôt ''tagl''.<br />
<br />
# Ajoutez le plugin [http://mojo.codehaus.org/cobertura-maven-plugin/usage.html Cobertura] à votre projet Maven.<br />
## Configurez le plugin pour [http://mojo.codehaus.org/cobertura-maven-plugin/examples/report-formats.html générer un rapport] HTML. Le résultat se trouvera dans ''target/site/cobertura''<br />
## Le plugin ne s'exécute automatiquement pas durant la compilation, il faut utiliser la commande : <pre>mvn cobertura:cobertura</pre><br />
## '''Bonus:''' Modifiez le fichier ''pom.xml'' pour que le ''goal'' '''cobertura''' soit exécuté pendant la ''phase'' '''package'''.<br />
# Répondez aux questions : ''Mais qu'est ce que la couverture de code ? En quoi c'est utile ?''<br />
# Ajoutez au projet Maven les plugins pour la génération d'un site et de rapports (Javadoc, tests unitaires, tags list (FIXME, TODO, ...), ...): voir http://maven.apache.org/plugins/maven-site-plugin/ et d'autres.<br />
# Regardez les exemples d'utilisation de cron4j dans cron4j-original/examples<br />
<br />
===Bonus Track===<br />
<br />
====Clone SVN -> Git====<br />
<br />
Source: http://www.yterium.net/Migrer-un-projet-SVN-vers-GIT<br />
<br />
<syntaxhighlight lang="bash"><br />
# Cloner le dépôt SVN en dépôt Git (conservation historique)<br />
$ git svn clone svn://svn.code.sf.net/p/cron4j/code/trunk cron4j-original<br />
$ cd cron4j-original<br />
# Test compilation<br />
$ ant jar<br />
$ cd ..<br />
</syntaxhighlight><br />
<br />
====Préparation TAGL====<br />
<br />
<syntaxhighlight lang="bash"><br />
# Clone du dépôt TAGL<br />
$ git clone git@github.com:donsez/tagl.git<br />
$ cd tagl<br />
# "Fetch" du dépôt local cloné précédemment<br />
$ git fetch file://$(pwd)/../cron4j-original<br />
# Fusion de ce qui vient d'être fetché<br />
$ git merge FETCH_HEAD<br />
# Envoi sur le serveur<br />
$ git push<br />
</syntaxhighlight><br />
<br />
<br />
====Cherry-picking: reprise des modifications d'un collègue====<br />
<br />
On considère que:<br />
<br />
* votre dépôt Git distant est à l'adresse URL_DEPOT<br />
* votre collègue a un dépôt Git à l'adresse URL_COLLEGUE<br />
<br />
<br />
<syntaxhighlight lang="bash"><br />
# Dossier temporaire<br />
cd /tmp<br />
<br />
# Clone de votre dépôt<br />
git clone URL_DEPOT mon_depot<br />
<br />
# Déplacement dans votre dépôt<br />
cd mon_depot<br />
<br />
# Définition du dépôt distant<br />
git remote add collegue URL_COLLEGUE<br />
<br />
# Récupération des infos du dépôt du collègue<br />
git fetch collegue<br />
<br />
# Maintenant, on peut voir les branches du collègue<br />
git branch -a<br />
<br />
# On peut fusionner avec une branche<br />
git merge collegue/master<br />
<br />
# Si vous avez des conflits, éditez les fichiers concernés,<br />
# et committez avec git commit<br />
<br />
# Push vers votre dépôt distant<br />
git push origin<br />
<br />
# Optionnel: supprimez la référence vers le dépôt du collègue<br />
git remote rm collegue<br />
</syntaxhighlight><br />
<br />
<br />
====Archetype webapp====<br />
L'archetype webapp (http://maven.apache.org/archetype/maven-archetype-bundles/maven-archetype-webapp/) permet de créer le squelette d'une webapp. Créez un simple webapp monsite en version 0.1.0. (add/commit/push). Vous pourrez tester cette webapp en ajoutant au pom.xml le [https://wiki.eclipse.org/Jetty/Feature/Jetty_Maven_Plugin plugin maven Jetty].<br />
<br />
<syntaxhighlight lang="bash"><br />
mvn -Djetty.port=9999 jetty:run<br />
</syntaxhighlight><br />
<br />
Naviguez sur http://localhost:9999/monsite<br />
<br />
====Scrum tools====<br />
Ces 3 services peuvent être couplé à votre dépôt GitHub pour votre gestion de projet agile avec [[Scrum]] :<br />
* http://www.acunote.com/<br />
* http://backlogtool.com/<br />
* http://www.scrumdo.com/<br />
<br />
L'activation se fait via ''Settings > Webhooks & Services > Configure services''.<br />
<br />
==Séance 2: AOP & AspectJ==<br />
<br />
Dans votre dépôt Git, projet ''cron4j-mvn''.<br />
<br />
# Ajoutez le [http://mojo.codehaus.org/aspectj-maven-plugin/ plugin Maven pour AspectJ] au pom.xml<br />
# Ajoutez un aspect de trace à l'invocation des méthodes '''run()''' de l'interface java.lang.Runnable (uniquement pour les objets ''schedulé''s)<br />
#: Affichez une trace avant et après l'exécution de la tâche<br />
# Préparez un nouveau test (nouvelle classe) démarrant un Scheduler Cron4j et validant l'exécution d'une tâche au bout d'une minute (pattern "* * * * *")<br />
#: Lors de l'exécution de '''mvn test''', vous devez voir apparaître les traces préparées dans votre aspect.<br />
<br />
Liens utiles:<br />
* [http://ridgetopsolutions.com/blog/2013/02/12/getting-started-with-aspectj-and-maven/ Getting started with AspectJ and Maven]<br />
<br />
===Contrôle continu===<br />
<br />
# Complétez l'aspect de trace avec le positionnement du [http://docs.oracle.com/javase/7/docs/api/java/lang/ThreadLocal.html java.lang.ThreadLocal] pour passer 1) l'identifiant du job et 2) le compteur des appels de la méthode de l'objet.<br />
<br />
==Séance 3: Pelix & iPOPO==<br />
<br />
Pelix est une plate-forme d'application à services (SOA).<br />
iPOPO est un modèle de composants orientés services (SOCM).<br />
<br />
La documentation de Pelix et iPOPO est disponible sur https://ipopo.coderxpress.net/<br />
<br />
===Installation de iPOPO===<br />
<br />
* Cloner le dépôt Git depuis https://github.com/tcalmant/ipopo<br />
* Se placer dans la branche ''dev''<br />
* Pour installer iPOPO, lancer la commande :<br />
<br />
sudo python setup.py install<br />
<br />
===Shell Pelix===<br />
<br />
Pour lancer un shell Pelix, utilisez la commande:<br />
<br />
python -m pelix.shell.console<br />
<br />
Les commandes disponibles sont décrites ici: [https://ipopo.coderxpress.net/wiki/doku.php?id=ipopo:refcards:shell Shell Commands]<br />
<br />
===Rappels de Python===<br />
<br />
* Pas de déclaration du type d'une variable<br />
* Les méthodes d'une classe ont toute comme premier paramètre ''self'', équivalent du ''this'' en Java.<br />
* Blocs définis par indentation (4 espaces ou 1 tab)<br />
* Une ligne finissant par ':' démarre toujours un bloc<br />
<br />
<syntaxhighlight lang="python"><br />
# Import d'un module<br />
import pelix<br />
<br />
# Définition d'une classe<br />
class MaClasse:<br />
# Constructeur<br />
def __init__(self):<br />
self.default = "stanger"<br />
print("Classe construite")<br />
<br />
# Méthode, avec un argument<br />
def sayHello(self, name):<br />
if not name:<br />
# Nom vide ou nul<br />
return "Hello, " + str(self.default)<br />
else:<br />
# Nom valide<br />
return "Hello, " + str(name)<br />
<br />
objet = MaClasse()<br />
print(objet.sayHello(""))<br />
print(objet.sayHello("World"))<br />
</syntaxhighlight><br />
<br />
===Service Ping-Pong===<br />
<br />
1. Écrire un fichier ''pong.py'', définissant une classe ''Pong'' ayant une méthode ''pong'' prenant en paramètre un message et retournant le message préfixé par "PONG:".<br />
<br />
Exemple: <br />
<br />
pong = Pong()<br />
pong.pong("Hello") # <-- Retourne "PONG:Hello"<br />
<br />
2. Écrire un fichier ''ping.py'', définissant une classe ''Ping'' ayant une méthode ''ping'' prenant en paramètre un message, créant un objet Pong et retournant le résultat de Pong.pong(message) préfixé par "PING:"<br />
<br />
Exemple:<br />
<br />
ping = Ping()<br />
ping.ping("Hello") # <-- Retourne "PING:PONG:Hello"<br />
<br />
3. Transformer le fichier ''pong.py'' pour qu'il devienne un bundle Pelix enregistrant un objet Pong comme étant un service ayant pour spécification "tagl.pong"<br />
* Définir une classe ''Activator'', décorée avec ''@BundleActivator''<br />
* Enregistrer le service dans la méthode ''Activator.start'' et le désenregistrer dans ''Activator.stop''<br />
* S'inspirer du fichier "ipopo/samples/remote/provider.py"<br />
<br />
Dans un shell Pelix, installer et démarrer le bundle 'pong' et vérifier que le service est bien inscrit avec la commande ''sl''<br />
<br />
4.Transformer la classe ''Ping'' dans ''ping.py'' en un composant iPOPO<br />
* L'objet Pong utilisé dans ''ping()'' doit être un service injecté par iPOPO (''@Requires'')<br />
* Appeler la méthode ''ping()'' dès que le service Pong est injecté (''@BindField'') ou disparait (''@UnbindField'')<br />
* S'inspirer du fichier "ipopo/samples/remote/consumer.py"<br />
<br />
Dans un shell Pelix, installer et démarrer le bundle 'ping' et vérifier son comportement si le bundle ''pong'' ou le bundle ''ping'' est arrêté et redémarré.<br />
<br />
5. Mettre à jour le bundle ''pong''<br />
* Remplacer le préfixe "PONG" par "NI"<br />
* Dans le shell Pelix, mettre à jour le bundle ''pong'' sans redémarrer la plate-forme (commande ''udpate'').<br />
* Vérifier les traces dans le shell pour valider la mise à jour du service.<br />
<br />
===Remote Services===<br />
<br />
* Ajouter les propriétés permettant l'export du service Pong dans ''pong.py'' (s'inspirer de ''provider.py'')<br />
<br />
* Lancer deux shells iPOPO (dans deux terminaux)<br />
* Dans chaque shell iPOPO, installer les bundles:<br />
** ''pelix.remote.dispatcher'': Exportateur de services<br />
** ''pelix.remote.registry''; Importateur de services<br />
** ''pelix.remote.discovery.multicast'': Découverte de services via Multicast<br />
** ''pelix.remote.xml_rpc'': Transport XML-RPC<br />
** ''pelix.http.basic'': Serveur HTTP<br />
<br />
Attention: il peut être nécessaire de désactiver votre pare-feu pour que les Remote Services fonctionnent<br />
<br />
* Instancier les composants depuis le shell iPOPO, dans chaque framework:<br />
** Serveur HTTP sur le port 8080: ''instantiate pelix.http.service.basic.factory http-server pelix.http.port=8080'' (penser à changer de port dans chaque framework)<br />
** Multicast Discovery: ''instantiate pelix-remote-discovery-multicast-factory multicast-discovery''<br />
** XML-RPC Exporter: ''instantiate pelix-xmlrpc-exporter-factory xml-rpc-exporter''<br />
** XML-RPC Importer: ''instantiate pelix-xmlrpc-exporter-factory xml-rpc-importer''<br />
<br />
* Installer le bundle ''ping'' dans un des frameworks et le bundle ''pong'' dans l'autre.<br />
* Le composant ping peut appeler le service pong, qui est dans l'autre framework.<br />
<br />
<br />
* Voir le code de ''run_remote.py'' pour voir comment démarrer un framework Pelix et installer des bundles depuis Python.<br />
* Jouer un peu avec ''run_remote.py'' (voir ''run_remote.py --help'')<br />
<br />
==Séance 4==<br />
[[Tutorial OSGi avec Apache Felix]]<br />
<br />
<br />
<br />
==Séance 5==<br />
Faire un projet PDE pour un bundle cron4j.gogo (indépendant de cron4j.bundle)<br />
<br />
Utilisation de https://eclipse.org/tycho/</div>Calmanthttps://air.imag.fr/index.php?title=TAGL/TP&diff=16645TAGL/TP2014-04-04T14:49:35Z<p>Calmant: /* Service Ping-Pong */</p>
<hr />
<div>Travaux pratiques de l'UE [[TAGL]].<br />
<br />
==Séance 1==<br />
===Git===<br />
<br />
Création d'un dépôt Git local<br />
<br />
====Méthode simple: init first====<br />
<br />
Via cette méthode, on crée un dépôt local, avec un répertoire de travail, puis on pousse ses modifications vers un dépôt "bare".<br />
Cette méthode est la plus simple, car on dispose immédiatement d'un répertoire de travail.<br />
<br />
<syntaxhighlight lang="bash"><br />
# Création d'un dépôt Git dans le dossier simple-repo<br />
git init simple-repo<br />
<br />
# Création d'un README<br />
cd simple-repo<br />
echo "Hello, World" > README<br />
<br />
# Ajout du versionnement du fichier README<br />
git add README<br />
<br />
# Commit<br />
git commit<br />
</syntaxhighlight><br />
<br />
À ce niveau, on a un dépôt Git complètement fonctionnel.<br />
Cependant, il est intéressant de pousser ses modifications vers un autre dépôt, sur une autre machine.<br />
On va donc créer un dépôt bare sur une autre machine (ou autre dossier pour l'exemple)<br />
<br />
<syntaxhighlight lang="bash"><br />
git init --bare server-repo<br />
</syntaxhighlight><br />
<br />
On considère que l'URL pour accéder à ce dépôt est URL_REPO.<br />
On va d'abord ajouter ce dépôt serveur à la liste des dépôts connu-repos de votre dépôt local.<br />
Étant donné qu'il s'agit du dépôt "principal" à utiliser, on l'appellera //origin//, par convention.<br />
<br />
<syntaxhighlight lang="bash"><br />
git remote add origin URL_REPO<br />
# Récupération de ses informations<br />
git fetch origin<br />
</syntaxhighlight><br />
<br />
Ce serveur distant est "vide": il n'a aucune branche. On va donc enregistrer notre branche sur le serveur<br />
<br />
<syntaxhighlight lang="bash"><br />
git push origin master<br />
</syntaxhighlight><br />
<br />
À partir de cette commande, la branche locale //master// sera liée à la branche distante //origin/master//.<br />
Lors des prochaines commandes ''git push'', grâce à cette liaison, tous les commits sur la branche locale //master// seront poussées sur le serveur distant.<br />
<br />
====Méthode moins simple: bare first====<br />
<br />
Si on commence dans par le serveur "vide", il faudra le cloner au lieu de le définir comme un dépôt distant.<br />
<br />
<syntaxhighlight lang="bash"><br />
# Création du dépôt vide<br />
git init --bare server-repo<br />
</syntaxhighlight><br />
<br />
On considère que ce dépôt est accessible à l'URL URL_REPO<br />
<br />
<syntaxhighlight lang="bash"><br />
# Clonage du dépôt<br />
git clone URL_REPO clone-repo<br />
</syntaxhighlight><br />
<br />
Un avertissement indique que l'on clone un dépôt vide: le dépôt local à donc une branche master, mais elle n'est pas liée au dépôt distant, car celui-ci n'a aucune branche.<br />
Le dépôt distant est automatiquement appelé //origin//.<br />
<br />
<syntaxhighlight lang="bash"><br />
# Commit dans le dépôt local<br />
cd clone-repo<br />
echo hello > readme.rst<br />
git add readme.rst<br />
git commit et ses dépendances<br />
</syntaxhighlight><br />
<br />
Comme dans la méthode simple, il faut pousser la branche master vers le dépôt distant:<br />
<br />
<syntaxhighlight lang="bash"><br />
git push origin master<br />
</syntaxhighlight><br />
<br />
===De l'importance des README===<br />
<br />
Il est très important d'avoir au moins 2 fichiers dans votre dépôt Git:<br />
<br />
* LICENSE: contenant le texte **complet** de la licence de votre projet<br />
* README: décrivant votre projet et comment l'utiliser. Ce fichier doit rappeler le nom de la licence de votre projet<br />
<br />
Il est aussi recommandé d'avoir les fichiers suivants:<br />
<br />
* AUTHORS: contenant la liste des noms/pseudos et e-mails des auteurs de commits ou de code inclus dans ce projet<br />
* INSTALL: contenant la liste des dépendances de ce projet et des commandes à utiliser pour le compiler et l'installer<br />
<br />
Les fichiers LICENSE sont des fichiers textes bruts.<br />
Les autres fichiers sont généralement dans un format offrant un peu plus de lisibilté, par exemple dans les formats [http://daringfireball.net/projects/markdown/ Markdown] (.md) ou [http://docutils.sourceforge.net/rst.html reStructuredText] (.rst)<br />
<br />
Un plug-in existe pour éditer des fichier reStructuredText dans Eclipse: ReST Editor, disponible sur le [https://marketplace.eclipse.org/content/rest-editor Marketplace Eclipse]<br />
<br />
===GitHub & Travis-CI===<br />
<br />
Travis-CI est un service permettant d'exécuter un script dans une machine virtuelle Ubuntu dès que vous effectuez un push sur un de vos dépôts GitHub.<br />
L'intérêt est de savoir si la version d'un projet que vous avez rendu publique peut être compilée et si ses tests passent.<br />
<br />
La machine virtuelle "offerte" par Travis est préconfigurée pour le language indiqué dans son fichier de configuration ('''.travis.yml'''), mais il est possible d'utiliser la commande '''sudo apt-get install ...''' pour ajouter vos dépendances.<br />
<br />
Pour utiliser Travis:<br />
<br />
# Créez compte individuel sur GitHub https://github.com<br />
# ''Fork''ez le projet TAGL '''cron4j''' depuis https://github.com/donsez/tagl<br />
# Ajoutez un collaborateur (i.e. votre binôme) au projet ''forké'', via les paramètres (''settings'') de ce projet<br />
# Pour l'exemple, activez le service (ou hook) ''Email'' depuis les paramètres du dépôt: à chaque fois que vous ou un de vos collaborateurs ferra un '''git push''', vous recevrez une notification par mail.<br />
# Activez le service Travis-CI: identifiez-vous (''sign in'') sur https://travis-ci.org/ avec votre compte GitHub<br />
# Activez le service pour les projets sur lesquels vous souhaitez appliquer les principes d'intégration continue<br />
<br />
Travis-CI utilise un fichier nommé '''.travis.yml''' (attention: fichier caché sous Unix) pour se configurer et choisir les opérations à effectuer.<br />
Ce fichier doit se trouver à la racine de votre dépôt Git.<br />
<br />
Faites un '''Commit''' puis un '''Push''' du fichier '''.travis.yml''' ci-dessous.<br />
<br />
<pre><br />
language: java<br />
<br />
jdk:<br />
- oraclejdk7<br />
- openjdk6<br />
- openjdk7<br />
<br />
script:<br />
- pushd cron4j-original && ant rel && popd<br />
</pre><br />
<br />
Ce fichier indique que le projet dans ce dépôt doit être testé sur 3 versions de Java (Oracle Java 7, Open JDK 6 et Open JDK 7), et que le script à exécuter pour lancer les tests est '''pushd cron4j-original && ant rel && popd'''.<br />
Travis-CI peut exécuter plusieurs commandes dans script, chacune d'entre elles devant démarrer par un '-' (élément dans une liste de 'scripts').<br />
<br />
Attention: il n'est pas possible d'utiliser '''cd''' pour changer de répertoire, il faut utiliser '''pushd''' (déplacement dans un dossier) et '''popd''' (retour au dossier précédent) à la place.<br />
<br />
Une fois ce fichier de configuration '''pushé''', Travis-CI se mettra en route dès le prochain '''push'''.<br />
<br />
===Maven===<br />
<br />
[http://maven.apache.org/download.cgi Charger et installer Maven 3].<br />
<br />
<pre><br />
mvn -version<br />
</pre><br />
<br />
Faites une copie du projet, basée sur Maven:<br />
<br />
# Dans votre dépôt Git, créez un dossier '''cron4j-mvn''': il contiendra le projet Cron4J avec la structure Maven<br />
# Dans ce dossier, utilisez l'[https://maven.apache.org/guides/introduction/introduction-to-archetypes.html archetype] Maven [http://maven.apache.org/archetype/maven-archetype-bundles/maven-archetype-quickstart/ maven-archetype-quickstart] (la version des sources de cron4j utilisés est la 2.5.5):<br />
#:<pre>mvn archetype:generate -DarchetypeGroupId=org.apache.maven.archetypes -DarchetypeArtifactId=maven-archetype-quickstart</pre><br />
# Cette commande crée un projet avec un fichier ''pom.xml'', et une classe et un test modèles: supprimez ces modèles<br />
# Copiez les sources de Cron4J depuis le dossier '''cron4j-original''' dans le dossier '''src/main/java''' de votre projet Maven<br />
# Faites un essai de compilation:<br />
#:<pre>mvn clean verify</pre><br />
# Enfin modifiez le fichier '''.travis.yml''' à la racine de votre dépôt Git afin que Travis exécute la commande '''mvn clean verify''' à chaque mise à jour du dépôt GitHub.<br />
<br />
===Tests Unitaires avec JUnit 4===<br />
Survoller le tutoriel [http://www.vogella.com/tutorials/JUnit/article.html Unit Testing with JUnit]<br />
<br />
# Ajouter le test unitaire suivant au projet, dans le fichier '''src/test/it/sauronsoftware/SchedulingPatternTest.java<br />
<pre><br />
package it.sauronsoftware;<br />
<br />
import it.sauronsoftware.cron4j.SchedulingPattern;<br />
import it.sauronsoftware.cron4j.InvalidPatternException;<br />
<br />
import static org.junit.Assert.assertEquals;<br />
import static org.junit.Assert.assertTrue;<br />
<br />
import org.junit.AfterClass;<br />
import org.junit.BeforeClass;<br />
import org.junit.Test;<br />
<br />
public class SchedulingPatternTest {<br />
<br />
@BeforeClass<br />
public static void testSetup() {<br />
}<br />
<br />
@AfterClass<br />
public static void testCleanup() {<br />
// Teardown for data used by the unit tests<br />
}<br />
<br />
@Test(expected = InvalidPatternException.class)<br />
public void testExceptionIsThrown() {<br />
SchedulingPattern sp = new SchedulingPattern("0 5 * *");<br />
}<br />
<br />
@Test<br />
public void testPattern() {<br />
String pattern;<br />
pattern="0 5 * * *|8 10 * * *|22 17 * * *";<br />
assertTrue(pattern + "is correct", SchedulingPattern.validate(pattern));<br />
pattern="0 5 * *";<br />
assertTrue(pattern + "is correct", SchedulingPattern.validate(pattern));<br />
}<br />
}<br />
</pre><br />
<br />
# Committez et Pushez ce nouveau fichier, pour que Travis lance les tests dès que possible<br />
# Lancez les tests unitaires avec <pre>mvn test</pre> Ce test va '''échouer''': corrigez le.<br />
# Committez et Pushez la version corrigée des tests: Travis enverra un mail pour indiquer si les tests échouent ou non<br />
#: '''Attention:''' Travis va exécuter les tests ''dès que possible''. Il est possible de recevoir un mail indiquant que les tests du premier ''push'' échouent alors que l'on a déjà ''pushé'' la correction.<br />
# Naviguez sur http://travis-ci.org pour vérifier les builds effectués.<br />
# Créez des tests unitaires supplémentaire du i.s.c.CronParser<br />
<br />
===Git (suite)===<br />
<br />
# Forkez le projet '''tagl''' d'un autre binome (i.e. autre que ''donsez/tagl'')<br />
#: '''Attention:''' donnez lui un nom différent (e.g. ''tagl-licensing'')<br />
# Clonez ce nouveau dépôt<br />
# Lancez une compilation pour valider l'état du projet (bonne pratique)<br />
#:<pre>mvn clean verify</pre><br />
# Ajoutez une bannière de licence dans le fichier '''cron4j-mvn/pom.xml'''<br />
# Lancez une nouvelle compilation pour valider vos modifications<br />
# Commitez et pushez (vers votre fork de ce dépôt, i.e. ''tagl-licensing'')<br />
# Via le site de GitHub, proposez un "Pull Request" au projet initial<br />
<br />
Vous pouvez ensuite supprimer le clone de ce fork.<br />
Lorsque le ''pull request'' aura été accepté, vous pourrez supprimer votre fork (''tagl-licensing'') de votre compte GitHub.<br />
<br />
===Contrôle Continu===<br />
<br />
Dans votre dépôt ''tagl''.<br />
<br />
# Ajoutez le plugin [http://mojo.codehaus.org/cobertura-maven-plugin/usage.html Cobertura] à votre projet Maven.<br />
## Configurez le plugin pour [http://mojo.codehaus.org/cobertura-maven-plugin/examples/report-formats.html générer un rapport] HTML. Le résultat se trouvera dans ''target/site/cobertura''<br />
## Le plugin ne s'exécute automatiquement pas durant la compilation, il faut utiliser la commande : <pre>mvn cobertura:cobertura</pre><br />
## '''Bonus:''' Modifiez le fichier ''pom.xml'' pour que le ''goal'' '''cobertura''' soit exécuté pendant la ''phase'' '''package'''.<br />
# Répondez aux questions : ''Mais qu'est ce que la couverture de code ? En quoi c'est utile ?''<br />
# Ajoutez au projet Maven les plugins pour la génération d'un site et de rapports (Javadoc, tests unitaires, tags list (FIXME, TODO, ...), ...): voir http://maven.apache.org/plugins/maven-site-plugin/ et d'autres.<br />
# Regardez les exemples d'utilisation de cron4j dans cron4j-original/examples<br />
<br />
===Bonus Track===<br />
<br />
====Clone SVN -> Git====<br />
<br />
Source: http://www.yterium.net/Migrer-un-projet-SVN-vers-GIT<br />
<br />
<syntaxhighlight lang="bash"><br />
# Cloner le dépôt SVN en dépôt Git (conservation historique)<br />
$ git svn clone svn://svn.code.sf.net/p/cron4j/code/trunk cron4j-original<br />
$ cd cron4j-original<br />
# Test compilation<br />
$ ant jar<br />
$ cd ..<br />
</syntaxhighlight><br />
<br />
====Préparation TAGL====<br />
<br />
<syntaxhighlight lang="bash"><br />
# Clone du dépôt TAGL<br />
$ git clone git@github.com:donsez/tagl.git<br />
$ cd tagl<br />
# "Fetch" du dépôt local cloné précédemment<br />
$ git fetch file://$(pwd)/../cron4j-original<br />
# Fusion de ce qui vient d'être fetché<br />
$ git merge FETCH_HEAD<br />
# Envoi sur le serveur<br />
$ git push<br />
</syntaxhighlight><br />
<br />
<br />
====Cherry-picking: reprise des modifications d'un collègue====<br />
<br />
On considère que:<br />
<br />
* votre dépôt Git distant est à l'adresse URL_DEPOT<br />
* votre collègue a un dépôt Git à l'adresse URL_COLLEGUE<br />
<br />
<br />
<syntaxhighlight lang="bash"><br />
# Dossier temporaire<br />
cd /tmp<br />
<br />
# Clone de votre dépôt<br />
git clone URL_DEPOT mon_depot<br />
<br />
# Déplacement dans votre dépôt<br />
cd mon_depot<br />
<br />
# Définition du dépôt distant<br />
git remote add collegue URL_COLLEGUE<br />
<br />
# Récupération des infos du dépôt du collègue<br />
git fetch collegue<br />
<br />
# Maintenant, on peut voir les branches du collègue<br />
git branch -a<br />
<br />
# On peut fusionner avec une branche<br />
git merge collegue/master<br />
<br />
# Si vous avez des conflits, éditez les fichiers concernés,<br />
# et committez avec git commit<br />
<br />
# Push vers votre dépôt distant<br />
git push origin<br />
<br />
# Optionnel: supprimez la référence vers le dépôt du collègue<br />
git remote rm collegue<br />
</syntaxhighlight><br />
<br />
<br />
====Archetype webapp====<br />
L'archetype webapp (http://maven.apache.org/archetype/maven-archetype-bundles/maven-archetype-webapp/) permet de créer le squelette d'une webapp. Créez un simple webapp monsite en version 0.1.0. (add/commit/push). Vous pourrez tester cette webapp en ajoutant au pom.xml le [https://wiki.eclipse.org/Jetty/Feature/Jetty_Maven_Plugin plugin maven Jetty].<br />
<br />
<syntaxhighlight lang="bash"><br />
mvn -Djetty.port=9999 jetty:run<br />
</syntaxhighlight><br />
<br />
Naviguez sur http://localhost:9999/monsite<br />
<br />
====Scrum tools====<br />
Ces 3 services peuvent être couplé à votre dépôt GitHub pour votre gestion de projet agile avec [[Scrum]] :<br />
* http://www.acunote.com/<br />
* http://backlogtool.com/<br />
* http://www.scrumdo.com/<br />
<br />
L'activation se fait via ''Settings > Webhooks & Services > Configure services''.<br />
<br />
==Séance 2: AOP & AspectJ==<br />
<br />
Dans votre dépôt Git, projet ''cron4j-mvn''.<br />
<br />
# Ajoutez le [http://mojo.codehaus.org/aspectj-maven-plugin/ plugin Maven pour AspectJ] au pom.xml<br />
# Ajoutez un aspect de trace à l'invocation des méthodes '''run()''' de l'interface java.lang.Runnable (uniquement pour les objets ''schedulé''s)<br />
#: Affichez une trace avant et après l'exécution de la tâche<br />
# Préparez un nouveau test (nouvelle classe) démarrant un Scheduler Cron4j et validant l'exécution d'une tâche au bout d'une minute (pattern "* * * * *")<br />
#: Lors de l'exécution de '''mvn test''', vous devez voir apparaître les traces préparées dans votre aspect.<br />
<br />
Liens utiles:<br />
* [http://ridgetopsolutions.com/blog/2013/02/12/getting-started-with-aspectj-and-maven/ Getting started with AspectJ and Maven]<br />
<br />
===Contrôle continu===<br />
<br />
# Complétez l'aspect de trace avec le positionnement du [http://docs.oracle.com/javase/7/docs/api/java/lang/ThreadLocal.html java.lang.ThreadLocal] pour passer 1) l'identifiant du job et 2) le compteur des appels de la méthode de l'objet.<br />
<br />
==Séance 3: Pelix & iPOPO==<br />
<br />
Pelix est une plate-forme d'application à services (SOA).<br />
iPOPO est un modèle de composants orientés services (SOCM).<br />
<br />
La documentation de Pelix et iPOPO est disponible sur https://ipopo.coderxpress.net/<br />
<br />
===Installation de iPOPO===<br />
<br />
* Cloner le dépôt Git depuis https://github.com/tcalmant/ipopo<br />
* Se placer dans la branche ''dev''<br />
* Pour installer iPOPO, lancer la commande :<br />
<br />
sudo python setup.py install<br />
<br />
===Shell Pelix===<br />
<br />
Pour lancer un shell Pelix, utilisez la commande:<br />
<br />
python -m pelix.shell.console<br />
<br />
Les commandes disponibles sont décrites ici: [https://ipopo.coderxpress.net/wiki/doku.php?id=ipopo:refcards:shell Shell Commands]<br />
<br />
===Rappels de Python===<br />
<br />
* Pas de déclaration du type d'une variable<br />
* Les méthodes d'une classe ont toute comme premier paramètre ''self'', équivalent du ''this'' en Java.<br />
* Blocs définis par indentation (4 espaces ou 1 tab)<br />
* Une ligne finissant par ':' démarre toujours un bloc<br />
<br />
<syntaxhighlight lang="python"><br />
# Import d'un module<br />
import pelix<br />
<br />
# Définition d'une classe<br />
class MaClasse:<br />
# Constructeur<br />
def __init__(self):<br />
self.default = "stanger"<br />
print("Classe construite")<br />
<br />
# Méthode, avec un argument<br />
def sayHello(self, name):<br />
if not name:<br />
# Nom vide ou nul<br />
return "Hello, " + str(self.default)<br />
else:<br />
# Nom valide<br />
return "Hello, " + str(name)<br />
<br />
objet = MaClasse()<br />
print(objet.sayHello(""))<br />
print(objet.sayHello("World"))<br />
</syntaxhighlight><br />
<br />
===Service Ping-Pong===<br />
<br />
1. Écrire un fichier ''pong.py'', définissant une classe ''Pong'' ayant une méthode ''pong'' prenant en paramètre un message et retournant le message préfixé par "PONG:".<br />
<br />
Exemple: <br />
<br />
pong = Pong()<br />
pong.pong("Hello") # <-- Retourne "PONG:Hello"<br />
<br />
2. Écrire un fichier ''ping.py'', définissant une classe ''Ping'' ayant une méthode ''ping'' prenant en paramètre un message, créant un objet Pong et retournant le résultat de Pong.pong(message) préfixé par "PING:"<br />
<br />
Exemple:<br />
<br />
ping = Ping()<br />
ping.ping("Hello") # <-- Retourne "PING:PONG:Hello"<br />
<br />
3. Transformer le fichier ''pong.py'' pour qu'il devienne un bundle Pelix enregistrant un objet Pong comme étant un service ayant pour spécification "tagl.pong"<br />
* Définir une classe ''Activator'', décorée avec ''@BundleActivator''<br />
* Enregistrer le service dans la méthode ''Activator.start'' et le désenregistrer dans ''Activator.stop''<br />
* S'inspirer du fichier "ipopo/samples/remote/provider.py"<br />
<br />
Dans un shell Pelix, installer et démarrer le bundle 'pong' et vérifier que le service est bien inscrit avec la commande ''sl''<br />
<br />
4.Transformer la classe ''Ping'' dans ''ping.py'' en un composant iPOPO<br />
* L'objet Pong utilisé dans ''ping()'' doit être un service injecté par iPOPO (''@Requires'')<br />
* Appeler la méthode ''ping()'' dès que le service Pong est injecté (''@BindField'') ou disparait (''@UnbindField'')<br />
* S'inspirer du fichier "ipopo/samples/remote/consumer.py"<br />
<br />
Dans un shell Pelix, installer et démarrer le bundle 'ping' et vérifier son comportement si le bundle ''pong'' ou le bundle ''ping'' est arrêté et redémarré.<br />
<br />
5. Mettre à jour le bundle ''pong''<br />
* Remplacer le préfixe "PONG" par "NI"<br />
* Dans le shell Pelix, mettre à jour le bundle ''pong'' sans redémarrer la plate-forme (commande ''udpate'').<br />
* Vérifier les traces dans le shell pour valider la mise à jour du service.<br />
<br />
===Remote Services===<br />
<br />
==Séance 4==<br />
[[Tutorial OSGi avec Apache Felix]]<br />
<br />
<br />
<br />
==Séance 5==<br />
Faire un projet PDE pour un bundle cron4j.gogo (indépendant de cron4j.bundle)<br />
<br />
Utilisation de https://eclipse.org/tycho/</div>Calmanthttps://air.imag.fr/index.php?title=TAGL/TP&diff=16634TAGL/TP2014-04-04T14:10:05Z<p>Calmant: /* Rappels de Python */</p>
<hr />
<div>Travaux pratiques de l'UE [[TAGL]].<br />
<br />
==Séance 1==<br />
===Git===<br />
<br />
Création d'un dépôt Git local<br />
<br />
====Méthode simple: init first====<br />
<br />
Via cette méthode, on crée un dépôt local, avec un répertoire de travail, puis on pousse ses modifications vers un dépôt "bare".<br />
Cette méthode est la plus simple, car on dispose immédiatement d'un répertoire de travail.<br />
<br />
<syntaxhighlight lang="bash"><br />
# Création d'un dépôt Git dans le dossier simple-repo<br />
git init simple-repo<br />
<br />
# Création d'un README<br />
cd simple-repo<br />
echo "Hello, World" > README<br />
<br />
# Ajout du versionnement du fichier README<br />
git add README<br />
<br />
# Commit<br />
git commit<br />
</syntaxhighlight><br />
<br />
À ce niveau, on a un dépôt Git complètement fonctionnel.<br />
Cependant, il est intéressant de pousser ses modifications vers un autre dépôt, sur une autre machine.<br />
On va donc créer un dépôt bare sur une autre machine (ou autre dossier pour l'exemple)<br />
<br />
<syntaxhighlight lang="bash"><br />
git init --bare server-repo<br />
</syntaxhighlight><br />
<br />
On considère que l'URL pour accéder à ce dépôt est URL_REPO.<br />
On va d'abord ajouter ce dépôt serveur à la liste des dépôts connu-repos de votre dépôt local.<br />
Étant donné qu'il s'agit du dépôt "principal" à utiliser, on l'appellera //origin//, par convention.<br />
<br />
<syntaxhighlight lang="bash"><br />
git remote add origin URL_REPO<br />
# Récupération de ses informations<br />
git fetch origin<br />
</syntaxhighlight><br />
<br />
Ce serveur distant est "vide": il n'a aucune branche. On va donc enregistrer notre branche sur le serveur<br />
<br />
<syntaxhighlight lang="bash"><br />
git push origin master<br />
</syntaxhighlight><br />
<br />
À partir de cette commande, la branche locale //master// sera liée à la branche distante //origin/master//.<br />
Lors des prochaines commandes ''git push'', grâce à cette liaison, tous les commits sur la branche locale //master// seront poussées sur le serveur distant.<br />
<br />
====Méthode moins simple: bare first====<br />
<br />
Si on commence dans par le serveur "vide", il faudra le cloner au lieu de le définir comme un dépôt distant.<br />
<br />
<syntaxhighlight lang="bash"><br />
# Création du dépôt vide<br />
git init --bare server-repo<br />
</syntaxhighlight><br />
<br />
On considère que ce dépôt est accessible à l'URL URL_REPO<br />
<br />
<syntaxhighlight lang="bash"><br />
# Clonage du dépôt<br />
git clone URL_REPO clone-repo<br />
</syntaxhighlight><br />
<br />
Un avertissement indique que l'on clone un dépôt vide: le dépôt local à donc une branche master, mais elle n'est pas liée au dépôt distant, car celui-ci n'a aucune branche.<br />
Le dépôt distant est automatiquement appelé //origin//.<br />
<br />
<syntaxhighlight lang="bash"><br />
# Commit dans le dépôt local<br />
cd clone-repo<br />
echo hello > readme.rst<br />
git add readme.rst<br />
git commit et ses dépendances<br />
</syntaxhighlight><br />
<br />
Comme dans la méthode simple, il faut pousser la branche master vers le dépôt distant:<br />
<br />
<syntaxhighlight lang="bash"><br />
git push origin master<br />
</syntaxhighlight><br />
<br />
===De l'importance des README===<br />
<br />
Il est très important d'avoir au moins 2 fichiers dans votre dépôt Git:<br />
<br />
* LICENSE: contenant le texte **complet** de la licence de votre projet<br />
* README: décrivant votre projet et comment l'utiliser. Ce fichier doit rappeler le nom de la licence de votre projet<br />
<br />
Il est aussi recommandé d'avoir les fichiers suivants:<br />
<br />
* AUTHORS: contenant la liste des noms/pseudos et e-mails des auteurs de commits ou de code inclus dans ce projet<br />
* INSTALL: contenant la liste des dépendances de ce projet et des commandes à utiliser pour le compiler et l'installer<br />
<br />
Les fichiers LICENSE sont des fichiers textes bruts.<br />
Les autres fichiers sont généralement dans un format offrant un peu plus de lisibilté, par exemple dans les formats [http://daringfireball.net/projects/markdown/ Markdown] (.md) ou [http://docutils.sourceforge.net/rst.html reStructuredText] (.rst)<br />
<br />
Un plug-in existe pour éditer des fichier reStructuredText dans Eclipse: ReST Editor, disponible sur le [https://marketplace.eclipse.org/content/rest-editor Marketplace Eclipse]<br />
<br />
===GitHub & Travis-CI===<br />
<br />
Travis-CI est un service permettant d'exécuter un script dans une machine virtuelle Ubuntu dès que vous effectuez un push sur un de vos dépôts GitHub.<br />
L'intérêt est de savoir si la version d'un projet que vous avez rendu publique peut être compilée et si ses tests passent.<br />
<br />
La machine virtuelle "offerte" par Travis est préconfigurée pour le language indiqué dans son fichier de configuration ('''.travis.yml'''), mais il est possible d'utiliser la commande '''sudo apt-get install ...''' pour ajouter vos dépendances.<br />
<br />
Pour utiliser Travis:<br />
<br />
# Créez compte individuel sur GitHub https://github.com<br />
# ''Fork''ez le projet TAGL '''cron4j''' depuis https://github.com/donsez/tagl<br />
# Ajoutez un collaborateur (i.e. votre binôme) au projet ''forké'', via les paramètres (''settings'') de ce projet<br />
# Pour l'exemple, activez le service (ou hook) ''Email'' depuis les paramètres du dépôt: à chaque fois que vous ou un de vos collaborateurs ferra un '''git push''', vous recevrez une notification par mail.<br />
# Activez le service Travis-CI: identifiez-vous (''sign in'') sur https://travis-ci.org/ avec votre compte GitHub<br />
# Activez le service pour les projets sur lesquels vous souhaitez appliquer les principes d'intégration continue<br />
<br />
Travis-CI utilise un fichier nommé '''.travis.yml''' (attention: fichier caché sous Unix) pour se configurer et choisir les opérations à effectuer.<br />
Ce fichier doit se trouver à la racine de votre dépôt Git.<br />
<br />
Faites un '''Commit''' puis un '''Push''' du fichier '''.travis.yml''' ci-dessous.<br />
<br />
<pre><br />
language: java<br />
<br />
jdk:<br />
- oraclejdk7<br />
- openjdk6<br />
- openjdk7<br />
<br />
script:<br />
- pushd cron4j-original && ant rel && popd<br />
</pre><br />
<br />
Ce fichier indique que le projet dans ce dépôt doit être testé sur 3 versions de Java (Oracle Java 7, Open JDK 6 et Open JDK 7), et que le script à exécuter pour lancer les tests est '''pushd cron4j-original && ant rel && popd'''.<br />
Travis-CI peut exécuter plusieurs commandes dans script, chacune d'entre elles devant démarrer par un '-' (élément dans une liste de 'scripts').<br />
<br />
Attention: il n'est pas possible d'utiliser '''cd''' pour changer de répertoire, il faut utiliser '''pushd''' (déplacement dans un dossier) et '''popd''' (retour au dossier précédent) à la place.<br />
<br />
Une fois ce fichier de configuration '''pushé''', Travis-CI se mettra en route dès le prochain '''push'''.<br />
<br />
===Maven===<br />
<br />
[http://maven.apache.org/download.cgi Charger et installer Maven 3].<br />
<br />
<pre><br />
mvn -version<br />
</pre><br />
<br />
Faites une copie du projet, basée sur Maven:<br />
<br />
# Dans votre dépôt Git, créez un dossier '''cron4j-mvn''': il contiendra le projet Cron4J avec la structure Maven<br />
# Dans ce dossier, utilisez l'[https://maven.apache.org/guides/introduction/introduction-to-archetypes.html archetype] Maven [http://maven.apache.org/archetype/maven-archetype-bundles/maven-archetype-quickstart/ maven-archetype-quickstart] (la version des sources de cron4j utilisés est la 2.5.5):<br />
#:<pre>mvn archetype:generate -DarchetypeGroupId=org.apache.maven.archetypes -DarchetypeArtifactId=maven-archetype-quickstart</pre><br />
# Cette commande crée un projet avec un fichier ''pom.xml'', et une classe et un test modèles: supprimez ces modèles<br />
# Copiez les sources de Cron4J depuis le dossier '''cron4j-original''' dans le dossier '''src/main/java''' de votre projet Maven<br />
# Faites un essai de compilation:<br />
#:<pre>mvn clean verify</pre><br />
# Enfin modifiez le fichier '''.travis.yml''' à la racine de votre dépôt Git afin que Travis exécute la commande '''mvn clean verify''' à chaque mise à jour du dépôt GitHub.<br />
<br />
===Tests Unitaires avec JUnit 4===<br />
Survoller le tutoriel [http://www.vogella.com/tutorials/JUnit/article.html Unit Testing with JUnit]<br />
<br />
# Ajouter le test unitaire suivant au projet, dans le fichier '''src/test/it/sauronsoftware/SchedulingPatternTest.java<br />
<pre><br />
package it.sauronsoftware;<br />
<br />
import it.sauronsoftware.cron4j.SchedulingPattern;<br />
import it.sauronsoftware.cron4j.InvalidPatternException;<br />
<br />
import static org.junit.Assert.assertEquals;<br />
import static org.junit.Assert.assertTrue;<br />
<br />
import org.junit.AfterClass;<br />
import org.junit.BeforeClass;<br />
import org.junit.Test;<br />
<br />
public class SchedulingPatternTest {<br />
<br />
@BeforeClass<br />
public static void testSetup() {<br />
}<br />
<br />
@AfterClass<br />
public static void testCleanup() {<br />
// Teardown for data used by the unit tests<br />
}<br />
<br />
@Test(expected = InvalidPatternException.class)<br />
public void testExceptionIsThrown() {<br />
SchedulingPattern sp = new SchedulingPattern("0 5 * *");<br />
}<br />
<br />
@Test<br />
public void testPattern() {<br />
String pattern;<br />
pattern="0 5 * * *|8 10 * * *|22 17 * * *";<br />
assertTrue(pattern + "is correct", SchedulingPattern.validate(pattern));<br />
pattern="0 5 * *";<br />
assertTrue(pattern + "is correct", SchedulingPattern.validate(pattern));<br />
}<br />
}<br />
</pre><br />
<br />
# Committez et Pushez ce nouveau fichier, pour que Travis lance les tests dès que possible<br />
# Lancez les tests unitaires avec <pre>mvn test</pre> Ce test va '''échouer''': corrigez le.<br />
# Committez et Pushez la version corrigée des tests: Travis enverra un mail pour indiquer si les tests échouent ou non<br />
#: '''Attention:''' Travis va exécuter les tests ''dès que possible''. Il est possible de recevoir un mail indiquant que les tests du premier ''push'' échouent alors que l'on a déjà ''pushé'' la correction.<br />
# Naviguez sur http://travis-ci.org pour vérifier les builds effectués.<br />
# Créez des tests unitaires supplémentaire du i.s.c.CronParser<br />
<br />
===Git (suite)===<br />
<br />
# Forkez le projet '''tagl''' d'un autre binome (i.e. autre que ''donsez/tagl'')<br />
#: '''Attention:''' donnez lui un nom différent (e.g. ''tagl-licensing'')<br />
# Clonez ce nouveau dépôt<br />
# Lancez une compilation pour valider l'état du projet (bonne pratique)<br />
#:<pre>mvn clean verify</pre><br />
# Ajoutez une bannière de licence dans le fichier '''cron4j-mvn/pom.xml'''<br />
# Lancez une nouvelle compilation pour valider vos modifications<br />
# Commitez et pushez (vers votre fork de ce dépôt, i.e. ''tagl-licensing'')<br />
# Via le site de GitHub, proposez un "Pull Request" au projet initial<br />
<br />
Vous pouvez ensuite supprimer le clone de ce fork.<br />
Lorsque le ''pull request'' aura été accepté, vous pourrez supprimer votre fork (''tagl-licensing'') de votre compte GitHub.<br />
<br />
===Contrôle Continu===<br />
<br />
Dans votre dépôt ''tagl''.<br />
<br />
# Ajoutez le plugin [http://mojo.codehaus.org/cobertura-maven-plugin/usage.html Cobertura] à votre projet Maven.<br />
## Configurez le plugin pour [http://mojo.codehaus.org/cobertura-maven-plugin/examples/report-formats.html générer un rapport] HTML. Le résultat se trouvera dans ''target/site/cobertura''<br />
## Le plugin ne s'exécute automatiquement pas durant la compilation, il faut utiliser la commande : <pre>mvn cobertura:cobertura</pre><br />
## '''Bonus:''' Modifiez le fichier ''pom.xml'' pour que le ''goal'' '''cobertura''' soit exécuté pendant la ''phase'' '''package'''.<br />
# Répondez aux questions : ''Mais qu'est ce que la couverture de code ? En quoi c'est utile ?''<br />
# Ajoutez au projet Maven les plugins pour la génération d'un site et de rapports (Javadoc, tests unitaires, tags list (FIXME, TODO, ...), ...): voir http://maven.apache.org/plugins/maven-site-plugin/ et d'autres.<br />
# Regardez les exemples d'utilisation de cron4j dans cron4j-original/examples<br />
<br />
===Bonus Track===<br />
<br />
====Clone SVN -> Git====<br />
<br />
Source: http://www.yterium.net/Migrer-un-projet-SVN-vers-GIT<br />
<br />
<syntaxhighlight lang="bash"><br />
# Cloner le dépôt SVN en dépôt Git (conservation historique)<br />
$ git svn clone svn://svn.code.sf.net/p/cron4j/code/trunk cron4j-original<br />
$ cd cron4j-original<br />
# Test compilation<br />
$ ant jar<br />
$ cd ..<br />
</syntaxhighlight><br />
<br />
====Préparation TAGL====<br />
<br />
<syntaxhighlight lang="bash"><br />
# Clone du dépôt TAGL<br />
$ git clone git@github.com:donsez/tagl.git<br />
$ cd tagl<br />
# "Fetch" du dépôt local cloné précédemment<br />
$ git fetch file://$(pwd)/../cron4j-original<br />
# Fusion de ce qui vient d'être fetché<br />
$ git merge FETCH_HEAD<br />
# Envoi sur le serveur<br />
$ git push<br />
</syntaxhighlight><br />
<br />
<br />
====Cherry-picking: reprise des modifications d'un collègue====<br />
<br />
On considère que:<br />
<br />
* votre dépôt Git distant est à l'adresse URL_DEPOT<br />
* votre collègue a un dépôt Git à l'adresse URL_COLLEGUE<br />
<br />
<br />
<syntaxhighlight lang="bash"><br />
# Dossier temporaire<br />
cd /tmp<br />
<br />
# Clone de votre dépôt<br />
git clone URL_DEPOT mon_depot<br />
<br />
# Déplacement dans votre dépôt<br />
cd mon_depot<br />
<br />
# Définition du dépôt distant<br />
git remote add collegue URL_COLLEGUE<br />
<br />
# Récupération des infos du dépôt du collègue<br />
git fetch collegue<br />
<br />
# Maintenant, on peut voir les branches du collègue<br />
git branch -a<br />
<br />
# On peut fusionner avec une branche<br />
git merge collegue/master<br />
<br />
# Si vous avez des conflits, éditez les fichiers concernés,<br />
# et committez avec git commit<br />
<br />
# Push vers votre dépôt distant<br />
git push origin<br />
<br />
# Optionnel: supprimez la référence vers le dépôt du collègue<br />
git remote rm collegue<br />
</syntaxhighlight><br />
<br />
<br />
====Archetype webapp====<br />
L'archetype webapp (http://maven.apache.org/archetype/maven-archetype-bundles/maven-archetype-webapp/) permet de créer le squelette d'une webapp. Créez un simple webapp monsite en version 0.1.0. (add/commit/push). Vous pourrez tester cette webapp en ajoutant au pom.xml le [https://wiki.eclipse.org/Jetty/Feature/Jetty_Maven_Plugin plugin maven Jetty].<br />
<br />
<syntaxhighlight lang="bash"><br />
mvn -Djetty.port=9999 jetty:run<br />
</syntaxhighlight><br />
<br />
Naviguez sur http://localhost:9999/monsite<br />
<br />
====Scrum tools====<br />
Ces 3 services peuvent être couplé à votre dépôt GitHub pour votre gestion de projet agile avec [[Scrum]] :<br />
* http://www.acunote.com/<br />
* http://backlogtool.com/<br />
* http://www.scrumdo.com/<br />
<br />
L'activation se fait via ''Settings > Webhooks & Services > Configure services''.<br />
<br />
==Séance 2: AOP & AspectJ==<br />
<br />
Dans votre dépôt Git, projet ''cron4j-mvn''.<br />
<br />
# Ajoutez le [http://mojo.codehaus.org/aspectj-maven-plugin/ plugin Maven pour AspectJ] au pom.xml<br />
# Ajoutez un aspect de trace à l'invocation des méthodes '''run()''' de l'interface java.lang.Runnable (uniquement pour les objets ''schedulé''s)<br />
#: Affichez une trace avant et après l'exécution de la tâche<br />
# Préparez un nouveau test (nouvelle classe) démarrant un Scheduler Cron4j et validant l'exécution d'une tâche au bout d'une minute (pattern "* * * * *")<br />
#: Lors de l'exécution de '''mvn test''', vous devez voir apparaître les traces préparées dans votre aspect.<br />
<br />
Liens utiles:<br />
* [http://ridgetopsolutions.com/blog/2013/02/12/getting-started-with-aspectj-and-maven/ Getting started with AspectJ and Maven]<br />
<br />
===Contrôle continu===<br />
<br />
# Complétez l'aspect de trace avec le positionnement du [http://docs.oracle.com/javase/7/docs/api/java/lang/ThreadLocal.html java.lang.ThreadLocal] pour passer 1) l'identifiant du job et 2) le compteur des appels de la méthode de l'objet.<br />
<br />
==Séance 3: Pelix & iPOPO==<br />
<br />
Pelix est une plate-forme d'application à services (SOA).<br />
iPOPO est un modèle de composants orientés services (SOCM).<br />
<br />
La documentation de Pelix et iPOPO est disponible sur https://ipopo.coderxpress.net/<br />
<br />
===Installation de iPOPO===<br />
<br />
* Cloner le dépôt Git depuis https://github.com/tcalmant/ipopo<br />
* Se placer dans la branche ''dev''<br />
* Pour installer iPOPO, lancer la commande :<br />
<br />
sudo python setup.py install<br />
<br />
===Shell Pelix===<br />
<br />
Pour lancer un shell Pelix, utilisez la commande:<br />
<br />
python -m pelix.shell.console<br />
<br />
Les commandes disponibles sont décrites ici: [https://ipopo.coderxpress.net/wiki/doku.php?id=ipopo:refcards:shell Shell Commands]<br />
<br />
===Rappels de Python===<br />
<br />
* Pas de déclaration du type d'une variable<br />
* Les méthodes d'une classe ont toute comme premier paramètre ''self'', équivalent du ''this'' en Java.<br />
* Blocs définis par indentation (4 espaces ou 1 tab)<br />
* Une ligne finissant par ':' démarre toujours un bloc<br />
<br />
<syntaxhighlight lang="python"><br />
# Import d'un module<br />
import pelix<br />
<br />
# Définition d'une classe<br />
class MaClasse:<br />
# Constructeur<br />
def __init__(self):<br />
self.default = "stanger"<br />
print("Classe construite")<br />
<br />
# Méthode, avec un argument<br />
def sayHello(self, name):<br />
if not name:<br />
# Nom vide ou nul<br />
return "Hello, " + str(self.default)<br />
else:<br />
# Nom valide<br />
return "Hello, " + str(name)<br />
<br />
objet = MaClasse()<br />
print(objet.sayHello(""))<br />
print(objet.sayHello("World"))<br />
</syntaxhighlight><br />
<br />
===Service Ping-Pong===<br />
<br />
===Remote Services===<br />
<br />
==Séance 4==<br />
[[Tutorial OSGi avec Apache Felix]]<br />
<br />
<br />
<br />
==Séance 5==<br />
Faire un projet PDE pour un bundle cron4j.gogo (indépendant de cron4j.bundle)<br />
<br />
Utilisation de https://eclipse.org/tycho/</div>Calmanthttps://air.imag.fr/index.php?title=TAGL/TP&diff=16633TAGL/TP2014-04-04T13:59:10Z<p>Calmant: /* Séance 3 */</p>
<hr />
<div>Travaux pratiques de l'UE [[TAGL]].<br />
<br />
==Séance 1==<br />
===Git===<br />
<br />
Création d'un dépôt Git local<br />
<br />
====Méthode simple: init first====<br />
<br />
Via cette méthode, on crée un dépôt local, avec un répertoire de travail, puis on pousse ses modifications vers un dépôt "bare".<br />
Cette méthode est la plus simple, car on dispose immédiatement d'un répertoire de travail.<br />
<br />
<syntaxhighlight lang="bash"><br />
# Création d'un dépôt Git dans le dossier simple-repo<br />
git init simple-repo<br />
<br />
# Création d'un README<br />
cd simple-repo<br />
echo "Hello, World" > README<br />
<br />
# Ajout du versionnement du fichier README<br />
git add README<br />
<br />
# Commit<br />
git commit<br />
</syntaxhighlight><br />
<br />
À ce niveau, on a un dépôt Git complètement fonctionnel.<br />
Cependant, il est intéressant de pousser ses modifications vers un autre dépôt, sur une autre machine.<br />
On va donc créer un dépôt bare sur une autre machine (ou autre dossier pour l'exemple)<br />
<br />
<syntaxhighlight lang="bash"><br />
git init --bare server-repo<br />
</syntaxhighlight><br />
<br />
On considère que l'URL pour accéder à ce dépôt est URL_REPO.<br />
On va d'abord ajouter ce dépôt serveur à la liste des dépôts connu-repos de votre dépôt local.<br />
Étant donné qu'il s'agit du dépôt "principal" à utiliser, on l'appellera //origin//, par convention.<br />
<br />
<syntaxhighlight lang="bash"><br />
git remote add origin URL_REPO<br />
# Récupération de ses informations<br />
git fetch origin<br />
</syntaxhighlight><br />
<br />
Ce serveur distant est "vide": il n'a aucune branche. On va donc enregistrer notre branche sur le serveur<br />
<br />
<syntaxhighlight lang="bash"><br />
git push origin master<br />
</syntaxhighlight><br />
<br />
À partir de cette commande, la branche locale //master// sera liée à la branche distante //origin/master//.<br />
Lors des prochaines commandes ''git push'', grâce à cette liaison, tous les commits sur la branche locale //master// seront poussées sur le serveur distant.<br />
<br />
====Méthode moins simple: bare first====<br />
<br />
Si on commence dans par le serveur "vide", il faudra le cloner au lieu de le définir comme un dépôt distant.<br />
<br />
<syntaxhighlight lang="bash"><br />
# Création du dépôt vide<br />
git init --bare server-repo<br />
</syntaxhighlight><br />
<br />
On considère que ce dépôt est accessible à l'URL URL_REPO<br />
<br />
<syntaxhighlight lang="bash"><br />
# Clonage du dépôt<br />
git clone URL_REPO clone-repo<br />
</syntaxhighlight><br />
<br />
Un avertissement indique que l'on clone un dépôt vide: le dépôt local à donc une branche master, mais elle n'est pas liée au dépôt distant, car celui-ci n'a aucune branche.<br />
Le dépôt distant est automatiquement appelé //origin//.<br />
<br />
<syntaxhighlight lang="bash"><br />
# Commit dans le dépôt local<br />
cd clone-repo<br />
echo hello > readme.rst<br />
git add readme.rst<br />
git commit et ses dépendances<br />
</syntaxhighlight><br />
<br />
Comme dans la méthode simple, il faut pousser la branche master vers le dépôt distant:<br />
<br />
<syntaxhighlight lang="bash"><br />
git push origin master<br />
</syntaxhighlight><br />
<br />
===De l'importance des README===<br />
<br />
Il est très important d'avoir au moins 2 fichiers dans votre dépôt Git:<br />
<br />
* LICENSE: contenant le texte **complet** de la licence de votre projet<br />
* README: décrivant votre projet et comment l'utiliser. Ce fichier doit rappeler le nom de la licence de votre projet<br />
<br />
Il est aussi recommandé d'avoir les fichiers suivants:<br />
<br />
* AUTHORS: contenant la liste des noms/pseudos et e-mails des auteurs de commits ou de code inclus dans ce projet<br />
* INSTALL: contenant la liste des dépendances de ce projet et des commandes à utiliser pour le compiler et l'installer<br />
<br />
Les fichiers LICENSE sont des fichiers textes bruts.<br />
Les autres fichiers sont généralement dans un format offrant un peu plus de lisibilté, par exemple dans les formats [http://daringfireball.net/projects/markdown/ Markdown] (.md) ou [http://docutils.sourceforge.net/rst.html reStructuredText] (.rst)<br />
<br />
Un plug-in existe pour éditer des fichier reStructuredText dans Eclipse: ReST Editor, disponible sur le [https://marketplace.eclipse.org/content/rest-editor Marketplace Eclipse]<br />
<br />
===GitHub & Travis-CI===<br />
<br />
Travis-CI est un service permettant d'exécuter un script dans une machine virtuelle Ubuntu dès que vous effectuez un push sur un de vos dépôts GitHub.<br />
L'intérêt est de savoir si la version d'un projet que vous avez rendu publique peut être compilée et si ses tests passent.<br />
<br />
La machine virtuelle "offerte" par Travis est préconfigurée pour le language indiqué dans son fichier de configuration ('''.travis.yml'''), mais il est possible d'utiliser la commande '''sudo apt-get install ...''' pour ajouter vos dépendances.<br />
<br />
Pour utiliser Travis:<br />
<br />
# Créez compte individuel sur GitHub https://github.com<br />
# ''Fork''ez le projet TAGL '''cron4j''' depuis https://github.com/donsez/tagl<br />
# Ajoutez un collaborateur (i.e. votre binôme) au projet ''forké'', via les paramètres (''settings'') de ce projet<br />
# Pour l'exemple, activez le service (ou hook) ''Email'' depuis les paramètres du dépôt: à chaque fois que vous ou un de vos collaborateurs ferra un '''git push''', vous recevrez une notification par mail.<br />
# Activez le service Travis-CI: identifiez-vous (''sign in'') sur https://travis-ci.org/ avec votre compte GitHub<br />
# Activez le service pour les projets sur lesquels vous souhaitez appliquer les principes d'intégration continue<br />
<br />
Travis-CI utilise un fichier nommé '''.travis.yml''' (attention: fichier caché sous Unix) pour se configurer et choisir les opérations à effectuer.<br />
Ce fichier doit se trouver à la racine de votre dépôt Git.<br />
<br />
Faites un '''Commit''' puis un '''Push''' du fichier '''.travis.yml''' ci-dessous.<br />
<br />
<pre><br />
language: java<br />
<br />
jdk:<br />
- oraclejdk7<br />
- openjdk6<br />
- openjdk7<br />
<br />
script:<br />
- pushd cron4j-original && ant rel && popd<br />
</pre><br />
<br />
Ce fichier indique que le projet dans ce dépôt doit être testé sur 3 versions de Java (Oracle Java 7, Open JDK 6 et Open JDK 7), et que le script à exécuter pour lancer les tests est '''pushd cron4j-original && ant rel && popd'''.<br />
Travis-CI peut exécuter plusieurs commandes dans script, chacune d'entre elles devant démarrer par un '-' (élément dans une liste de 'scripts').<br />
<br />
Attention: il n'est pas possible d'utiliser '''cd''' pour changer de répertoire, il faut utiliser '''pushd''' (déplacement dans un dossier) et '''popd''' (retour au dossier précédent) à la place.<br />
<br />
Une fois ce fichier de configuration '''pushé''', Travis-CI se mettra en route dès le prochain '''push'''.<br />
<br />
===Maven===<br />
<br />
[http://maven.apache.org/download.cgi Charger et installer Maven 3].<br />
<br />
<pre><br />
mvn -version<br />
</pre><br />
<br />
Faites une copie du projet, basée sur Maven:<br />
<br />
# Dans votre dépôt Git, créez un dossier '''cron4j-mvn''': il contiendra le projet Cron4J avec la structure Maven<br />
# Dans ce dossier, utilisez l'[https://maven.apache.org/guides/introduction/introduction-to-archetypes.html archetype] Maven [http://maven.apache.org/archetype/maven-archetype-bundles/maven-archetype-quickstart/ maven-archetype-quickstart] (la version des sources de cron4j utilisés est la 2.5.5):<br />
#:<pre>mvn archetype:generate -DarchetypeGroupId=org.apache.maven.archetypes -DarchetypeArtifactId=maven-archetype-quickstart</pre><br />
# Cette commande crée un projet avec un fichier ''pom.xml'', et une classe et un test modèles: supprimez ces modèles<br />
# Copiez les sources de Cron4J depuis le dossier '''cron4j-original''' dans le dossier '''src/main/java''' de votre projet Maven<br />
# Faites un essai de compilation:<br />
#:<pre>mvn clean verify</pre><br />
# Enfin modifiez le fichier '''.travis.yml''' à la racine de votre dépôt Git afin que Travis exécute la commande '''mvn clean verify''' à chaque mise à jour du dépôt GitHub.<br />
<br />
===Tests Unitaires avec JUnit 4===<br />
Survoller le tutoriel [http://www.vogella.com/tutorials/JUnit/article.html Unit Testing with JUnit]<br />
<br />
# Ajouter le test unitaire suivant au projet, dans le fichier '''src/test/it/sauronsoftware/SchedulingPatternTest.java<br />
<pre><br />
package it.sauronsoftware;<br />
<br />
import it.sauronsoftware.cron4j.SchedulingPattern;<br />
import it.sauronsoftware.cron4j.InvalidPatternException;<br />
<br />
import static org.junit.Assert.assertEquals;<br />
import static org.junit.Assert.assertTrue;<br />
<br />
import org.junit.AfterClass;<br />
import org.junit.BeforeClass;<br />
import org.junit.Test;<br />
<br />
public class SchedulingPatternTest {<br />
<br />
@BeforeClass<br />
public static void testSetup() {<br />
}<br />
<br />
@AfterClass<br />
public static void testCleanup() {<br />
// Teardown for data used by the unit tests<br />
}<br />
<br />
@Test(expected = InvalidPatternException.class)<br />
public void testExceptionIsThrown() {<br />
SchedulingPattern sp = new SchedulingPattern("0 5 * *");<br />
}<br />
<br />
@Test<br />
public void testPattern() {<br />
String pattern;<br />
pattern="0 5 * * *|8 10 * * *|22 17 * * *";<br />
assertTrue(pattern + "is correct", SchedulingPattern.validate(pattern));<br />
pattern="0 5 * *";<br />
assertTrue(pattern + "is correct", SchedulingPattern.validate(pattern));<br />
}<br />
}<br />
</pre><br />
<br />
# Committez et Pushez ce nouveau fichier, pour que Travis lance les tests dès que possible<br />
# Lancez les tests unitaires avec <pre>mvn test</pre> Ce test va '''échouer''': corrigez le.<br />
# Committez et Pushez la version corrigée des tests: Travis enverra un mail pour indiquer si les tests échouent ou non<br />
#: '''Attention:''' Travis va exécuter les tests ''dès que possible''. Il est possible de recevoir un mail indiquant que les tests du premier ''push'' échouent alors que l'on a déjà ''pushé'' la correction.<br />
# Naviguez sur http://travis-ci.org pour vérifier les builds effectués.<br />
# Créez des tests unitaires supplémentaire du i.s.c.CronParser<br />
<br />
===Git (suite)===<br />
<br />
# Forkez le projet '''tagl''' d'un autre binome (i.e. autre que ''donsez/tagl'')<br />
#: '''Attention:''' donnez lui un nom différent (e.g. ''tagl-licensing'')<br />
# Clonez ce nouveau dépôt<br />
# Lancez une compilation pour valider l'état du projet (bonne pratique)<br />
#:<pre>mvn clean verify</pre><br />
# Ajoutez une bannière de licence dans le fichier '''cron4j-mvn/pom.xml'''<br />
# Lancez une nouvelle compilation pour valider vos modifications<br />
# Commitez et pushez (vers votre fork de ce dépôt, i.e. ''tagl-licensing'')<br />
# Via le site de GitHub, proposez un "Pull Request" au projet initial<br />
<br />
Vous pouvez ensuite supprimer le clone de ce fork.<br />
Lorsque le ''pull request'' aura été accepté, vous pourrez supprimer votre fork (''tagl-licensing'') de votre compte GitHub.<br />
<br />
===Contrôle Continu===<br />
<br />
Dans votre dépôt ''tagl''.<br />
<br />
# Ajoutez le plugin [http://mojo.codehaus.org/cobertura-maven-plugin/usage.html Cobertura] à votre projet Maven.<br />
## Configurez le plugin pour [http://mojo.codehaus.org/cobertura-maven-plugin/examples/report-formats.html générer un rapport] HTML. Le résultat se trouvera dans ''target/site/cobertura''<br />
## Le plugin ne s'exécute automatiquement pas durant la compilation, il faut utiliser la commande : <pre>mvn cobertura:cobertura</pre><br />
## '''Bonus:''' Modifiez le fichier ''pom.xml'' pour que le ''goal'' '''cobertura''' soit exécuté pendant la ''phase'' '''package'''.<br />
# Répondez aux questions : ''Mais qu'est ce que la couverture de code ? En quoi c'est utile ?''<br />
# Ajoutez au projet Maven les plugins pour la génération d'un site et de rapports (Javadoc, tests unitaires, tags list (FIXME, TODO, ...), ...): voir http://maven.apache.org/plugins/maven-site-plugin/ et d'autres.<br />
# Regardez les exemples d'utilisation de cron4j dans cron4j-original/examples<br />
<br />
===Bonus Track===<br />
<br />
====Clone SVN -> Git====<br />
<br />
Source: http://www.yterium.net/Migrer-un-projet-SVN-vers-GIT<br />
<br />
<syntaxhighlight lang="bash"><br />
# Cloner le dépôt SVN en dépôt Git (conservation historique)<br />
$ git svn clone svn://svn.code.sf.net/p/cron4j/code/trunk cron4j-original<br />
$ cd cron4j-original<br />
# Test compilation<br />
$ ant jar<br />
$ cd ..<br />
</syntaxhighlight><br />
<br />
====Préparation TAGL====<br />
<br />
<syntaxhighlight lang="bash"><br />
# Clone du dépôt TAGL<br />
$ git clone git@github.com:donsez/tagl.git<br />
$ cd tagl<br />
# "Fetch" du dépôt local cloné précédemment<br />
$ git fetch file://$(pwd)/../cron4j-original<br />
# Fusion de ce qui vient d'être fetché<br />
$ git merge FETCH_HEAD<br />
# Envoi sur le serveur<br />
$ git push<br />
</syntaxhighlight><br />
<br />
<br />
====Cherry-picking: reprise des modifications d'un collègue====<br />
<br />
On considère que:<br />
<br />
* votre dépôt Git distant est à l'adresse URL_DEPOT<br />
* votre collègue a un dépôt Git à l'adresse URL_COLLEGUE<br />
<br />
<br />
<syntaxhighlight lang="bash"><br />
# Dossier temporaire<br />
cd /tmp<br />
<br />
# Clone de votre dépôt<br />
git clone URL_DEPOT mon_depot<br />
<br />
# Déplacement dans votre dépôt<br />
cd mon_depot<br />
<br />
# Définition du dépôt distant<br />
git remote add collegue URL_COLLEGUE<br />
<br />
# Récupération des infos du dépôt du collègue<br />
git fetch collegue<br />
<br />
# Maintenant, on peut voir les branches du collègue<br />
git branch -a<br />
<br />
# On peut fusionner avec une branche<br />
git merge collegue/master<br />
<br />
# Si vous avez des conflits, éditez les fichiers concernés,<br />
# et committez avec git commit<br />
<br />
# Push vers votre dépôt distant<br />
git push origin<br />
<br />
# Optionnel: supprimez la référence vers le dépôt du collègue<br />
git remote rm collegue<br />
</syntaxhighlight><br />
<br />
<br />
====Archetype webapp====<br />
L'archetype webapp (http://maven.apache.org/archetype/maven-archetype-bundles/maven-archetype-webapp/) permet de créer le squelette d'une webapp. Créez un simple webapp monsite en version 0.1.0. (add/commit/push). Vous pourrez tester cette webapp en ajoutant au pom.xml le [https://wiki.eclipse.org/Jetty/Feature/Jetty_Maven_Plugin plugin maven Jetty].<br />
<br />
<syntaxhighlight lang="bash"><br />
mvn -Djetty.port=9999 jetty:run<br />
</syntaxhighlight><br />
<br />
Naviguez sur http://localhost:9999/monsite<br />
<br />
====Scrum tools====<br />
Ces 3 services peuvent être couplé à votre dépôt GitHub pour votre gestion de projet agile avec [[Scrum]] :<br />
* http://www.acunote.com/<br />
* http://backlogtool.com/<br />
* http://www.scrumdo.com/<br />
<br />
L'activation se fait via ''Settings > Webhooks & Services > Configure services''.<br />
<br />
==Séance 2: AOP & AspectJ==<br />
<br />
Dans votre dépôt Git, projet ''cron4j-mvn''.<br />
<br />
# Ajoutez le [http://mojo.codehaus.org/aspectj-maven-plugin/ plugin Maven pour AspectJ] au pom.xml<br />
# Ajoutez un aspect de trace à l'invocation des méthodes '''run()''' de l'interface java.lang.Runnable (uniquement pour les objets ''schedulé''s)<br />
#: Affichez une trace avant et après l'exécution de la tâche<br />
# Préparez un nouveau test (nouvelle classe) démarrant un Scheduler Cron4j et validant l'exécution d'une tâche au bout d'une minute (pattern "* * * * *")<br />
#: Lors de l'exécution de '''mvn test''', vous devez voir apparaître les traces préparées dans votre aspect.<br />
<br />
Liens utiles:<br />
* [http://ridgetopsolutions.com/blog/2013/02/12/getting-started-with-aspectj-and-maven/ Getting started with AspectJ and Maven]<br />
<br />
===Contrôle continu===<br />
<br />
# Complétez l'aspect de trace avec le positionnement du [http://docs.oracle.com/javase/7/docs/api/java/lang/ThreadLocal.html java.lang.ThreadLocal] pour passer 1) l'identifiant du job et 2) le compteur des appels de la méthode de l'objet.<br />
<br />
==Séance 3: Pelix & iPOPO==<br />
<br />
Pelix est une plate-forme d'application à services (SOA).<br />
iPOPO est un modèle de composants orientés services (SOCM).<br />
<br />
La documentation de Pelix et iPOPO est disponible sur https://ipopo.coderxpress.net/<br />
<br />
===Installation de iPOPO===<br />
<br />
* Cloner le dépôt Git depuis https://github.com/tcalmant/ipopo<br />
* Se placer dans la branche ''dev''<br />
* Pour installer iPOPO, lancer la commande :<br />
<br />
sudo python setup.py install<br />
<br />
===Shell Pelix===<br />
<br />
Pour lancer un shell Pelix, utilisez la commande:<br />
<br />
python -m pelix.shell.console<br />
<br />
Les commandes disponibles sont décrites ici: [https://ipopo.coderxpress.net/wiki/doku.php?id=ipopo:refcards:shell Shell Commands]<br />
<br />
===Rappels de Python===<br />
<br />
===Service Ping-Pong===<br />
<br />
===Remote Services===<br />
<br />
==Séance 4==<br />
[[Tutorial OSGi avec Apache Felix]]<br />
<br />
<br />
<br />
==Séance 5==<br />
Faire un projet PDE pour un bundle cron4j.gogo (indépendant de cron4j.bundle)<br />
<br />
Utilisation de https://eclipse.org/tycho/</div>Calmanthttps://air.imag.fr/index.php?title=SmartCampus2014/Tutoriels&diff=16316SmartCampus2014/Tutoriels2014-03-25T15:51:57Z<p>Calmant: /* Subscribe */</p>
<hr />
<div>= Liens =<br />
<br />
* [http://air.imag.fr/index.php/SmartCampus2014 Présentation] du projet SmartCampus<br />
* [http://air.imag.fr/index.php/SmartCampus2014/FicheSuivi Fiche de suivi] du projet<br />
* [http://air.imag.fr/index.php/SmartCampus2014/CDC Cahier des charges]<br />
<br />
= Mosquitto =<br />
<br />
[[File:logo_mqtt.png | 200px| left]]<br />
<br><br><br><br><br />
Mosquitto est une implémentation de MQTT, un protocole de M2M de type publish-subscribe.<br />
<br />
== Installation ==<br />
* Documentation officielle : [http://mosquitto.org/documentation/]<br />
* Pour Debian/Ubuntu et dérivés: [http://mosquitto.org/2013/01/mosquitto-debian-repository/]<br />
* Ensuite télécharger le client en ligne de commande:<br />
<br />
----<br />
<big><source lang="bash"><br />
sudo apt-get install mosquitto python-mosquitto<br />
sudo apt-get install mosquitto-clients<br />
</source></big><br />
----<br />
<br />
== Exemple de communication ==<br />
* Dans un premier terminal on lance le broker :<br />
<br />
----<br />
<big><source lang="bash"><br />
>mosquitto<br />
1391181009: mosquitto version 1.2.3 (build date 2013-12-04 21:22:55+0000) starting<br />
1391181009: Using default config.<br />
1391181009: Opening ipv4 listen socket on port 1883.<br />
1391181009: Opening ipv6 listen socket on port 1883.<br />
</source></big><br />
----<br />
Sur certaines distributions, mosquitto peut se trouver dans /usr/sbin/.<br />
<br />
* Dans un second terminal on crée un topic "toto" sur lequel on publie des messages.<br />
----<br />
<big><source lang="bash"><br />
mosquitto_sub -d -t toto <br />
</source></big><br />
----<br />
<br />
* Dans un dernier terminal on publie sur le topic "toto".<br />
----<br />
<big><source lang="bash"><br />
mosquitto_pub -t toto -m "Hello world "<br />
</source></big><br />
----<br />
<br />
* Pour communiquer entre différents devices, il faut lancer le broker sur chacun d'eux, puis indiquer lors du subscribe l'adresse IP du publisher. Par exemple :<br />
----<br />
<big><source lang="bash"><br />
mosquitto_sub -d -h 192.168.0.1 -t toto <br />
</source></big><br />
----<br />
<br />
= Comment utiliser openHAB avec Mosquitto ? =<br />
[[File:logo_openhab.png | 200px| left]]<br />
<br><br><br><br />
<br />
== Requis ==<br />
Il faut en premier lieu ajouter le bundle MQTT bindings (disponible [http://code.google.com/p/openhab/downloads/detail?name=openhab-addons-1.3.1.zip&can=2&q= ici]) dans le dossier "addons" du runtime openHAB.<br />
<br />
Ne pas oublier de lancer le broker Mosquitto (commande mosquitto).<br />
<br />
Ajouter l'URL du broker dans le fichier de configuration d'openHAB (e.g. openhab.cfg) :<br />
----<br />
<big><source lang="java"><br />
mqtt:mosquitto.url=tcp://localhost:1883<br />
</source></big><br />
----<br />
<br />
== Subscribe ==<br />
Lier un item à un topic en indiquant l'alias du broker, le type des messages transmis, et l'action effectuée sur openHAB sur réception des messages :<br />
----<br />
<big><source lang="java"><br />
{ mqtt="<[<broker>:<topic>:<type>:<transformation>]" }<br />
</source></big><br />
----<br />
où <type> est soit "command" soit "state" (pour l'update), et où <transformation> est "default".<br />
<br />
Par exemple :<br />
----<br />
<big><source lang="java"><br />
Number Temperature_GF_Corridor "Temperature [%.1f °C]" <temperature> (Temperature, GF_Corridor) { mqtt="<[mosquitto:temperature:state:default]" }<br />
</source></big><br />
----<br />
<br />
On peut alors publier avec "mosquitto_pub" sur le topic défini (e.g. "temperature") et voir le changement dans l'interface openHAB.<br />
<br />
== Publish ==<br />
<br />
Le principe est relativement semblable. On lance "mosquitto_sub" sur le topic voulu (e.g. "light").<br />
Lier un item à un topic en indiquant l'alias du broker, le type des messages transmis, le déclencheur de l'envoi de message, et la transformation :<br />
----<br />
<big><source lang="java"><br />
{ mqtt=">[<broker>:<topic>:<type>:<trigger>:<transformation>]" }<br />
</source></big><br />
----<br />
<br />
Par exemple :<br />
----<br />
<big><source lang="java"><br />
Switch Light_Outdoor_Garage "Garage" (Outdoor, Lights) { mqtt=">[mosquitto:light:command:ON:1],>[mosquitto:light:command:OFF:0]" }<br />
</source></big><br />
----<br />
Ici, lorsque l'interrupteur de la lumière du garage est actionné, le subscriber Mosquitto reçoit 0 ou 1.<br />
<br />
Pour plus d'informations, voir le wiki officiel [https://github.com/openhab/openhab/wiki/MQTT-Binding ici].<br />
<br />
= Comment se connecter en SSH à la carte Galileo =<br />
[[File:logo_arduino.png | 100px| left]]<br />
<br><br><br><br><br />
Voir le tutoriel officiel d'Intel : [[Media:Galileo_GettingStarted.pdf | Galileo_GettingStarted.pdf]]<br />
<br />
== Configuration de la carte Galileo ==<br />
* Avant tout, il est important de toujours alimenter la carte Galileo avant de la brancher à l’ordinateur !<br />
* Connecter le Galileo à l’ordinateur avec le câble USB (port USB client de la carte).<br><br />
* Lancer l'IDE Arduino et sélectionner le port série (Outils > Port série). Si le port série n'est pas reconnu, essayez de relancer l'IDE en Administrateur.<br />
* Updater le firmware via l’IDE Arduino (Aide > Firmware Update). Cette étape est primordiale pour pouvoir se connecter en SSH. Il est aussi important de ne pas lancer de sketchs avant ou pendant la mise à jour.<br />
* Créer un nouveau sketch :<br />
<br />
----<br />
<big><source lang="c"><br />
void setup() {<br />
// put your setup code here, to run once:<br />
system("telnetd -l /bin/sh");<br />
system("ifconfig eth0 169.254.1.1 netmask 255.255.0.0 up"); //adapter l’adresse ip et le masque<br />
system("route add default gw 169.254.1.2"); // le PC devient passerelle par défaut<br />
}<br />
<br />
void loop() {<br />
// put your main code here, to run repeatedly: <br />
}<br />
</source></big><br />
----<br />
<br />
Attention, il faut garder la boucle ''loop'' dans le code, même vide, pour ne pas avoir d'erreur. Dans cet exemple, nous lançons le service Telnet mais si on utilise seulement SSH, cette ligne n'est pas nécessaire.<br />
<br />
* Flasher ce code sur la carte Galileo.<br />
<br />
* Configurer le PC en mode routeur (en root sous Linux) :<br />
----<br />
<big><source lang="bash"><br />
sysctl net.ipv4.ip_forward=1<br />
</source></big><br />
----<br />
<br />
* Activer le NAT sur le PC (en root sous Linux) :<br />
----<br />
<big><source lang="bash"><br />
iptables -t nat -A POSTROUTING -o wlan0 -j MASQUERADE<br />
iptables -A FORWARD -i wlan0 -o eth0:avahi -m state --state RELATED,ESTABLISHED -j ACCEPT<br />
iptables -A FORWARD -i eth0:avahi -o wlan0 -j ACCEPT<br />
</source></big><br />
----<br />
<br />
* Sur Galileo, si la résolution d'adresse ne fonctionne pas (e.g. ping www.google.com ne marche pas), configurer le DNS en ajoutant à /etc/resolv.conf :<br />
----<br />
<big><source lang="bash"><br />
domain grenet.fr<br />
search grenet.fr<br />
nameserver 130.190.190.4<br />
</source></big><br />
----<br />
<i><b>Attention</b> : les domaines ci-dessus sont valables seulement pour un PC connecté à wifi-campus. Sur un autre réseau, il suffit (sur un système UNIX) de copier le contenu de /etc/resolv.conf</i><br />
<br />
== Connexion en SSH ==<br />
* Relier le Galileo à l’ordinateur avec le câble Ethernet.<br />
* Sur windows la connexion se fera automatiquement, mais sur Linux il faut changer l’adresse IP de la carte Ethernet pour être sur le même réseau que le Galileo :<br />
----<br />
<big><source lang="bash"><br />
sudo ifconfig eth0 169.254.1.2 up<br />
</source></big><br />
----<br />
<br />
* Faire un ping vers l’adresse ip 169.254.1.1 pour vérifier que la connexion fonctionne (si cela ne marche pas, il peut être judicieux de déconnecter la prise secteur de la carte et de la rebrancher).<br />
<br />
* Lorsque le ping fonctionne, il est possible de se connecter en root à la carte Galileo, soit en utilisant un client SSH de type PuTTY, ou via la commande :<br />
----<br />
<big><source lang="bash"><br />
ssh root@169.254.1.1<br />
</source></big><br />
----<br />
<br />
= Mis en place d'une base de donnée mongodb (en local) =<br />
[[File:logo_mongodb.png | 200px| left]]<br />
<br><br><br><br><br />
<br />
== [http://docs.mongodb.org/manual/installation/ Installation et lancement] == <br />
<br />
Par la suite il est possible d'accéder à différentes informations de votre BD via l'url : <br />
* http://localhost:28017/<br />
<br />
== Accéder au contenu ==<br />
<br />
Pour accéder au contenu d'une collection de votre base de donnée, lancer la base de donnée en utilisant la commande :<br />
----<br />
<big><source lang="bash"><br />
sudo mongod --rest<br />
</source></big><br />
----<br />
<br />
puis dans votre navigateur, accéder à l'URL :<br />
* http://localhost:28017/nomDeVotreBD/nomDeVotreCollection/<br />
<br />
== Ajouter une base de donnée == <br />
<br />
Pour ajouter une base de donnée lancer mongo en version shell :<br />
----<br />
<big><source lang="bash"><br />
mongo<br />
</source></big><br />
----<br />
Pour visualiser l'ensemble des bases de données :<br />
----<br />
<big><source lang="bash"><br />
show dbs<br />
</source></big><br />
----<br />
Afin de créer une base de donnée ou se connecter à l'une d'elle : <br />
----<br />
<big><source lang="bash"><br />
use nomBD<br />
</source></big><br />
----<br />
<br />
= Mise en place NodeJs Mongoose =<br />
<br />
== Prérequis ==<br />
<br />
Effectuer le point précédent<br />
Lancer les commandes :<br />
----<br />
<big><source lang="bash"><br />
sudo npm install express mongoose mongoose-schema-extend express-restify-mongoose<br />
</source></big><br />
----<br />
<br />
== Connexion à la BD ==<br />
<br />
* Afin de se connecter à la BD réalisée précédemment :<br />
----<br />
<big><source lang="javascript"><br />
//Connection to the a mongodb database path localhost:port/nameOfDB<br />
mongoose.connect("mongodb://localhost:27017/Client", function(err) {<br />
if (err) {<br />
throw err;<br />
}<br />
});<br />
</source></big><br />
----<br />
* On définit le schéma d'une collection en définissant son id et un champs <br />
----<br />
<big><source lang="javascript"><br />
//Definition of a schema<br />
var Temperature = new Schema({<br />
_id: Number,<br />
temp: Number<br />
});<br />
</source></big><br />
----<br />
<br />
* Création du modèle<br />
----<br />
<big><source lang="javascript"><br />
var TemperatureModel = mongoose.model('temperature', Temperature);<br />
<br />
//Creation of an object which respect the model define before<br />
var myTemperatureModel = new TemperatureModel({_id: 1473, temp: 16});<br />
</source></big><br />
----<br />
<br />
* Ajout d'un élèment dans la base de donnée.<br />
----<br />
<big><source lang="javascript"><br />
//saved the temperature in the mongodb database<br />
myTemperatureModel.save(function(err){<br />
if (err) { throw err; }<br />
console.log('Commentaire ajouté avec succès !');<br />
// On se déconnecte de MongoDB maintenant<br />
mongoose.connection.close();<br />
});<br />
</source></big><br />
----<br />
<br />
= Mise en place NodeJs Mongoose MQTT =<br />
<br />
== Prérequis ==<br />
<br />
Installation de mqtt<br />
----<br />
<big><source lang="bash"><br />
npm install mqtt<br />
</source></big><br />
----<br />
<br />
== Utilisation ==<br />
<br />
On fait appel à la librairie mqtt : <br />
<br />
----<br />
<big><source lang="javascript"><br />
var mqtt = require('mqtt')<br />
</source></big><br />
----<br />
<br />
Connexion au broker sur le port 1883 :<br />
----<br />
<big><source lang="javascript"><br />
client = mqtt.createClient(1883, 'localhost');<br />
</source></big><br />
----<br />
<br />
On subscribe au topic 'temperature', et à chaque réception de ce topic on affiche ce qui a été reçu dans la console:<br />
----<br />
<big><source lang="javascript"><br />
client.subscribe('temperature');<br />
client.on('message', function (topic, message) {<br />
console.log(message);<br />
});<br />
</source></big><br />
----<br />
<br />
On peut également publier sur le topic 'light' l'info 'On' :<br />
----<br />
<big><source lang="javascript"><br />
client.publish('light', 'On');<br />
</source></big><br />
----<br />
<br />
En lançant ces commandes le texte 'On' devrait apparaître sur votre console.<br />
<br />
= Utilisation de NodeJS Mongoose MQTT et Mosquitto =<br />
<br />
== Prérequis ==<br />
<br />
Suivre le tuto sur mosquitto, NodeJS Mongoose MQTT et Mosquitto.<br />
Lancer MongoDB.<br />
Ajouter une DB dans mongo "Client" (cf tuto NodeJS Mongoose MQTT).<br />
<br />
== Test == <br />
<br />
Dans le .js Node ajouter le code suivant : <br />
----<br />
<big><source lang="javascript"><br />
var http = require('http');<br />
var express = require('express');<br />
var mongoose = require('mongoose');<br />
var mqtt = require('mqtt')<br />
var Schema = mongoose.Schema;<br />
var restify = require('express-restify-mongoose')<br />
<br />
///////////////////////////////////<br />
/////// MONGODB //////////////////<br />
//////////////////////////////////<br />
//Connection to the a mongodb database path localhost:port/nameOfCollection<br />
mongoose.connect("mongodb://localhost:27017/Client", function(err) {<br />
if (err) {<br />
throw err;<br />
}<br />
});<br />
<br />
//Definition of a schema<br />
var Temperature = new Schema({<br />
_id: Number,<br />
temp: Number<br />
});<br />
//Creation of the model<br />
var TemperatureModel = mongoose.model('temperatures', Temperature);<br />
<br />
<br />
///////////////////////////////////<br />
/////// MQTT //////////////////<br />
//////////////////////////////////<br />
<br />
client = mqtt.createClient(1883, 'localhost');<br />
<br />
client.subscribe('temperature');<br />
<br />
var i = 0;<br />
client.on('message', function(topic, message) {<br />
console.log(message);<br />
var myTemperatureModel = new TemperatureModel({_id: i++, temp: message});<br />
myTemperatureModel.save(function(err) {<br />
if (err) {<br />
throw err;<br />
}<br />
console.log('Température ajouté à la BD avec succès !');<br />
});<br />
});<br />
<br />
<br />
var app = express();<br />
app.configure(function() {<br />
app.use(express.bodyParser());<br />
app.use(express.methodOverride());<br />
restify.serve(app, TemperatureModel);<br />
});<br />
<br />
<br />
//Run the server<br />
http.createServer(app).listen(4242, function() {<br />
console.log("Express server listening on port 4242");<br />
});<br />
</source></big><br />
----<br />
<br />
Lancer ceci avec Node.<br />
<br />
Lancer mosquitto et publier sur le topic 'light' : <br />
----<br />
<big><source lang="bash"><br />
mosquitto<br />
mosquitto_pub -t temperature -m "25"<br />
</source></big><br />
----<br />
<br />
Par la suite, vous devriez voir le message "25°C" dans la console. <br />
De plus, à l'adresse http://localhost:28017/Client/temperatures/ vous devriez apercevoir l'ajout d'un objet JSON contenant en paramètre 'temp' à 25.<br />
<br />
= Carte interactive =<br />
<br />
== Google Maps ==<br />
[[File:logo_maps.png | 75px| left]]<br />
<br><br><br><br><br><br />
Voir la [https://developers.google.com/maps/documentation/javascript/reference?hl=FR documentation de l'API].<br />
<br />
* Intégrer la carte :<br />
----<br />
<big><source lang="xml"><br />
<!DOCTYPE html><br />
<html><br />
<head><br />
<style type="text/css"><br />
html { height: 100% }<br />
body { height: 100%; margin: 0; padding: 0 }<br />
#map-canvas { height: 100% }<br />
</style><br />
<script type="text/javascript" src="http://maps.google.com/maps/api/js?sensor=false"></script><br />
<script type="text/javascript"><br />
</source><br />
<source lang="javascript"><br />
function initialize() {<br />
var mapOptions = {<br />
center: new google.maps.LatLng(45.19091427, 5.76828361), // centrer sur le campus de SMH<br />
zoom: 15,<br />
mapTypeId: google.maps.MapTypeId.ROADMAP<br />
};<br />
var map = new google.maps.Map(document.getElementById("map-canvas"),<br />
mapOptions);<br />
<br />
// bounds of the desired area<br />
var allowedBounds = new google.maps.LatLngBounds( // limites du campus<br />
new google.maps.LatLng(45.18575736, 5.75114965),<br />
new google.maps.LatLng(45.20112086, 5.78054667)<br />
);<br />
var boundLimits = {<br />
maxLat : allowedBounds.getNorthEast().lat(),<br />
maxLng : allowedBounds.getNorthEast().lng(),<br />
minLat : allowedBounds.getSouthWest().lat(),<br />
minLng : allowedBounds.getSouthWest().lng()<br />
};<br />
<br />
var lastValidCenter = map.getCenter();<br />
var newLat, newLng;<br />
google.maps.event.addListener(map, 'center_changed', function() {<br />
center = map.getCenter();<br />
if (allowedBounds.contains(center)) {<br />
// still within valid bounds, so save the last valid position<br />
lastValidCenter = map.getCenter();<br />
return;<br />
}<br />
newLat = lastValidCenter.lat();<br />
newLng = lastValidCenter.lng();<br />
if(center.lng() > boundLimits.minLng && center.lng() < boundLimits.maxLng){<br />
newLng = center.lng();<br />
}<br />
if(center.lat() > boundLimits.minLat && center.lat() < boundLimits.maxLat){<br />
newLat = center.lat();<br />
}<br />
map.panTo(new google.maps.LatLng(newLat, newLng));<br />
});<br />
}<br />
google.maps.event.addDomListener(window, 'load', initialize);<br />
</source></big><br />
<big><source lang="xml"><br />
</script><br />
</head><br />
<body><br />
<div id="map-canvas"/><br />
</body><br />
</html><br />
</source></big><br />
----<br />
<br />
* Ajouter un POI et une infobulle :<br />
----<br />
<big><source lang="javascript"><br />
var latLng = new google.maps.LatLng(45.187778,5.726945);<br />
<br />
var marker = new google.maps.Marker({<br />
position : latLng,<br />
map : map,<br />
title : "titre"<br />
//icon : "marker.gif"<br />
});<br />
<br />
var infoWindow = new google.maps.InfoWindow({<br />
content : 'infobulle',<br />
position : latLng<br />
});<br />
<br />
</source></big><br />
----<br />
<br />
== Leaflet ==<br />
<br />
[[File:Leaflet_logo.png | 200px| left]]<br />
<br><br><br><br><br><br />
<br />
Voir la [http://leafletjs.com/reference.html documentation de l'API].<br />
<br />
* Intégrer la carte (+ marqueurs et popups) :<br />
----<br />
<big><source lang="xml"><br />
<!DOCTYPE html><br />
<html><br />
<head><br />
<title>Leaflet Example</title><br />
<meta charset="utf-8" /><br />
<meta name="viewport" content="width=device-width, initial-scale=1.0"><br />
<link rel="stylesheet" href="http://cdn.leafletjs.com/leaflet-0.7.2/leaflet.css" /><br />
</head><br />
<body><br />
<div id="map" style="width: 600px; height: 400px"></div><br />
<script src="http://cdn.leafletjs.com/leaflet-0.7.2/leaflet.js"></script><br />
<script><br />
</source><br />
<source lang="javascript"><br />
<br />
var map = L.map('map').setView([45.19091427, 5.76828361], 14);<br />
L.tileLayer('http://{s}.tile.cloudmade.com/ec5901144ac74caeb0bf17aeaeea442f/997/256/{z}/{x}/{y}.png', {<br />
attribution: '&copy; <a href="http://osm.org/copyright">OpenStreetMap</a> contributors',<br />
maxZoom: 18<br />
}).addTo(map);<br />
<br />
// add a marker<br />
var marker = L.marker([45.19, 5.77]).addTo(map);<br />
<br />
// add a circle<br />
var circle = L.circle([45.20, 5.76], 300, {<br />
color: 'red',<br />
fillColor: '#f03',<br />
fillOpacity: 0.5<br />
}).addTo(map);<br />
<br />
// add a polygon<br />
var polygon = L.polygon([<br />
[45.189, 5.765],<br />
[45.193, 5.762],<br />
[45.192, 5.750]<br />
]).addTo(map);<br />
<br />
// add popups <br />
marker.bindPopup("<b>Hello world!</b><br>I am a popup.").openPopup();<br />
circle.bindPopup("I am a circle.");<br />
polygon.bindPopup("I am a polygon.");<br />
<br />
// add a standalone popup<br />
var popup = L.popup()<br />
.setLatLng([45.185, 5.775])<br />
.setContent("I am a standalone popup.")<br />
.openOn(map); <br />
<br />
// event<br />
function onMapClick(e) {<br />
popup<br />
.setLatLng(e.latlng)<br />
.setContent("You clicked the map at " + e.latlng.toString())<br />
.openOn(map);<br />
}<br />
map.on('click', onMapClick);<br />
<br />
</source><br />
<source lang="xml"><br />
</script><br />
<br />
</body><br />
</html><br />
</source></big><br />
----<br />
<br />
<!--<br />
= Installation d'un OS basé sur Linux (LSB - Linux Standard Base) sur Intel Galileo =<br />
<br />
== Prérequis ==<br />
<br />
Avoir mis à jour le firmware.<br />
<br />
== Traitement sur sa carte SD == <br />
<br />
Suivre le tuto [https://communities.intel.com/thread/45852 ici] afin que la carte SD respecte le bon format.<br />
<br />
== Utilisation d'un Linux sur la carte SD == <br />
<br />
'''Attention à l'heure actuelle, en utilisant cette solution l'IDE Arduino Galileo ne reconnaitra pas la carte Galileo'''. <br />
<br />
Il existe deux solutions possibles pour installer un linux sur votre OS. La première consiste à créer votre propre OS sur mesure avec Yocto Project mais cela demande plus de 4h avec une machine ayant un i7 haswell (4700hq). Une autre solution est de télécharger les images pré-buildées qui pourraient correspondre à vos besoin. <br />
<br />
=== Créer votre propre OS sur mesure ===<br />
<br />
Grâce à ce pdf, pas à pas, il est expliqué comment réaliser son propre OS basé sur Linux.<br />
[[File:IntelAcademic_IoT_26_IntelInside_Rebuild_Yocto_Reviewed.pdf]]<br />
<br />
=== OS pré-buildé ===<br />
<br />
Des OS pré-buildés sont également disponibles [http://ccc.ntu.edu.tw/index.php/en/news/40 ici] selon ce que vous voulez faire.<br />
Une fois l'une des archives téléchargées il suffit de le dézipper, et de le copier sur sa carte mini-SD. <br />
Une fois ces commandes effectuées, il est possible d'utiliser la carte en suivant ces instructions : <br />
* Brancher le câble ethernet au routeur ;<br />
* Mettre la mini carte SD ;<br />
* Brancher la carte Galileo au secteur.<br />
Sur la carte Galileo, l'adresse IP de la carte Galileo est "settée" grâce au protocole DHCP, ce qui permet ainsi d'y accéder en ssh une fois que l'on a trouvé l'adresse IP donnée à sa carte Galileo.<br />
<br />
=== Utilisation des sketchs ===<br />
<br />
La solution pour lancer des sketchs sur Galileo il faut utiliser les GPIO (General Purpose Input/Output) de la carte, via un langage de programmation.<br />
Exemple : <br />
*[https://github.com/agnathan/iot-mwc-samples langageC] <br />
*[http://wiki.ros.org/IntelGalileo/IntelGalileoGPIO python].<br />
<br />
== Utilisation d'un Debian ==<br />
<br />
Nous n'avons pas testé l'utilisation d'un OS Debian car selon la communauté Intel, cela rendrait la carte trop lente.<br />
<br />
== Utilisation de Java, Openhab, Mosquitto ==<br />
<br />
* Effectuer ce qui est indiqué dans la section [http://air.imag.fr/index.php/SmartCampus2014/Tutoriels#OS_pr.C3.A9-build.C3.A9 OS-prébuildé] en téléchargeant le lien "Yocto Project Linux image w/ Clanton-full kernel + general SDKs + OpenJDK-6".<br />
* Se connecter en ssh à la carte Galileo<br />
* Ajuster la date de la carte à celle de votre ordinateur avec la commande : "date DateSurOrdi" <br />
* Depuis une autre console, copier le dossier ''openhab runtime'' sur la carte Galileo : "scp -r openhabruntime root@ipAdressGalileo:."<br />
* Télécharger les sources de mosquitto [http://mosquitto.org/download/ ici] <br />
* Copier les sources mosquitto sur Galileo<br />
* Les décompresser depuis ssh<br />
* Accéder à ce dossier<br />
* Effectuer la commande ''make'' <br />
* Accéder à src/mosquitto.conf avec vi (ou votre éditeur préféré) et ajouter ''user root''<br />
* Lancer mosquitto : "./src/mosquitto -c src/mosquitto.conf"<br />
* Lancer openhab : "sh start.sh"<br />
* Après l'affichage de "started classic UI at /openhab.app", vous pouvez accéder à http://@ipGalileo:8080/openhab.app?sitemap=demo<br />
--><br />
<br />
=Création d'une route personnalisée avec Express (framework node.js) =<br />
<br />
==Prérequis==<br />
* nodejs et Express installés<br />
Installer nodejs et npm. [http://nodejs.org/]<br />
Ensuite : <br />
npm install express<br />
<br />
== Introduction ==<br />
<br />
Express est un framework Node.js MVC.<br />
Il s'organise autour de trois dossiers principaux : routes, views et public.<br />
* views : regroupe l'ensemble des vues ; dans notre présentation une simple page HTML.<br />
* routes : le modèle où l'on définit les fonctionnalités de chaque "route"<br />
* public : rassemble les éléments statiques (js, css, ...)<br />
<br />
Une route désigne une adresse adresse:port/une/route/personnalisee.<br />
<br />
Le fichier principal fait office de contrôleur.<br />
== Un hello world avec Express==<br />
Un simple hello world avec Express.<br />
<br />
serveur.js<br />
----------------<br />
<big><source lang="javascript"><br />
<br />
var express = require('express'); // include express<br />
var app = express(); // lance l'application<br />
<br />
app.get('/', function(req, res){ // définit la route racine<br />
res.send('hello world');<br />
});<br />
<br />
app.listen(4242); // ecoute sur le port 4242<br />
<br />
</source></big><br />
----------------<br />
<br />
Pour lancer l'application <br />
nodejs serveur.js<br />
Allez sur http://localhost:4242/<br />
<br />
== Organiser le routage ==<br />
L'ensemble des routes peut être décrit dans le fichier principal serveur.js. Cependant pour plus de clarté les routes sont généralement définies dans le dossier /routes.<br />
<br />
serveur.js<br />
----------------<br />
<big><source lang="javascript"><br />
<br />
var express = require('express'); // include express<br />
var routes = require('./routes');<br />
var app = express(); // lance l'application<br />
<br />
app.get('/', routes.hello); // définit la route racine<br />
app.get('/json', routes.exjson); <br />
app.get('/unepage', routes.unepage); <br />
<br />
app.listen(4242); // ecoute sur le port 4242<br />
<br />
</source></big><br />
----------------<br />
<br />
/routes/index.js<br />
----------------<br />
<big><source lang="javascript"><br />
<br />
exports.hello = function(req, res) {<br />
res.send("<h1>Hello World !</h1>");<br />
};<br />
exports.unepage = function(req, res) {<br />
res.render('une_page.html');<br />
}<br />
exports.exjson = function(req, res) {<br />
res.json(200, {message: "Welcome in our site !"});<br />
};<br />
<br />
</source></big><br />
----------------<br />
<br />
views/une_page.html<br />
----<br />
<big><source lang="xml"><br />
<!DOCTYPE html><br />
<html><br />
<head><br />
<title>Leaflet Example</title><br />
<meta charset="utf-8" /><br />
<meta name="viewport" content="width=device-width, initial-scale=1.0"><br />
</head><br />
<body><br />
Une simple page <br />
</body><br />
</html><br />
</source></big><br />
----</div>Calmanthttps://air.imag.fr/index.php?title=TAGL/TP&diff=15678TAGL/TP2014-02-21T13:48:20Z<p>Calmant: /* Séance 2: AOP & AspectJ */</p>
<hr />
<div>Travaux pratiques de l'UE [[TAGL]].<br />
<br />
==Séance 1==<br />
===Git===<br />
<br />
Création d'un dépôt Git local<br />
<br />
====Méthode simple: init first====<br />
<br />
Via cette méthode, on crée un dépôt local, avec un répertoire de travail, puis on pousse ses modifications vers un dépôt "bare".<br />
Cette méthode est la plus simple, car on dispose immédiatement d'un répertoire de travail.<br />
<br />
<syntaxhighlight lang="bash"><br />
# Création d'un dépôt Git dans le dossier simple-repo<br />
git init simple-repo<br />
<br />
# Création d'un README<br />
cd simple-repo<br />
echo "Hello, World" > README<br />
<br />
# Ajout du versionnement du fichier README<br />
git add README<br />
<br />
# Commit<br />
git commit<br />
</syntaxhighlight><br />
<br />
À ce niveau, on a un dépôt Git complètement fonctionnel.<br />
Cependant, il est intéressant de pousser ses modifications vers un autre dépôt, sur une autre machine.<br />
On va donc créer un dépôt bare sur une autre machine (ou autre dossier pour l'exemple)<br />
<br />
<syntaxhighlight lang="bash"><br />
git init --bare server-repo<br />
</syntaxhighlight><br />
<br />
On considère que l'URL pour accéder à ce dépôt est URL_REPO.<br />
On va d'abord ajouter ce dépôt serveur à la liste des dépôts connu-repos de votre dépôt local.<br />
Étant donné qu'il s'agit du dépôt "principal" à utiliser, on l'appellera //origin//, par convention.<br />
<br />
<syntaxhighlight lang="bash"><br />
git remote add origin URL_REPO<br />
# Récupération de ses informations<br />
git fetch origin<br />
</syntaxhighlight><br />
<br />
Ce serveur distant est "vide": il n'a aucune branche. On va donc enregistrer notre branche sur le serveur<br />
<br />
<syntaxhighlight lang="bash"><br />
git push origin master<br />
</syntaxhighlight><br />
<br />
À partir de cette commande, la branche locale //master// sera liée à la branche distante //origin/master//.<br />
Lors des prochaines commandes ''git push'', grâce à cette liaison, tous les commits sur la branche locale //master// seront poussées sur le serveur distant.<br />
<br />
====Méthode moins simple: bare first====<br />
<br />
Si on commence dans par le serveur "vide", il faudra le cloner au lieu de le définir comme un dépôt distant.<br />
<br />
<syntaxhighlight lang="bash"><br />
# Création du dépôt vide<br />
git init --bare server-repo<br />
</syntaxhighlight><br />
<br />
On considère que ce dépôt est accessible à l'URL URL_REPO<br />
<br />
<syntaxhighlight lang="bash"><br />
# Clonage du dépôt<br />
git clone URL_REPO clone-repo<br />
</syntaxhighlight><br />
<br />
Un avertissement indique que l'on clone un dépôt vide: le dépôt local à donc une branche master, mais elle n'est pas liée au dépôt distant, car celui-ci n'a aucune branche.<br />
Le dépôt distant est automatiquement appelé //origin//.<br />
<br />
<syntaxhighlight lang="bash"><br />
# Commit dans le dépôt local<br />
cd clone-repo<br />
echo hello > readme.rst<br />
git add readme.rst<br />
git commit et ses dépendances<br />
</syntaxhighlight><br />
<br />
Comme dans la méthode simple, il faut pousser la branche master vers le dépôt distant:<br />
<br />
<syntaxhighlight lang="bash"><br />
git push origin master<br />
</syntaxhighlight><br />
<br />
===De l'importance des README===<br />
<br />
Il est très important d'avoir au moins 2 fichiers dans votre dépôt Git:<br />
<br />
* LICENSE: contenant le texte **complet** de la licence de votre projet<br />
* README: décrivant votre projet et comment l'utiliser. Ce fichier doit rappeler le nom de la licence de votre projet<br />
<br />
Il est aussi recommandé d'avoir les fichiers suivants:<br />
<br />
* AUTHORS: contenant la liste des noms/pseudos et e-mails des auteurs de commits ou de code inclus dans ce projet<br />
* INSTALL: contenant la liste des dépendances de ce projet et des commandes à utiliser pour le compiler et l'installer<br />
<br />
Les fichiers LICENSE sont des fichiers textes bruts.<br />
Les autres fichiers sont généralement dans un format offrant un peu plus de lisibilté, par exemple dans les formats [http://daringfireball.net/projects/markdown/ Markdown] (.md) ou [http://docutils.sourceforge.net/rst.html reStructuredText] (.rst)<br />
<br />
Un plug-in existe pour éditer des fichier reStructuredText dans Eclipse: ReST Editor, disponible sur le [https://marketplace.eclipse.org/content/rest-editor Marketplace Eclipse]<br />
<br />
===GitHub & Travis-CI===<br />
<br />
Travis-CI est un service permettant d'exécuter un script dans une machine virtuelle Ubuntu dès que vous effectuez un push sur un de vos dépôts GitHub.<br />
L'intérêt est de savoir si la version d'un projet que vous avez rendu publique peut être compilée et si ses tests passent.<br />
<br />
La machine virtuelle "offerte" par Travis est préconfigurée pour le language indiqué dans son fichier de configuration ('''.travis.yml'''), mais il est possible d'utiliser la commande '''sudo apt-get install ...''' pour ajouter vos dépendances.<br />
<br />
Pour utiliser Travis:<br />
<br />
# Créez compte individuel sur GitHub https://github.com<br />
# ''Fork''ez le projet TAGL '''cron4j''' depuis https://github.com/donsez/tagl<br />
# Ajoutez un collaborateur (i.e. votre binôme) au projet ''forké'', via les paramètres (''settings'') de ce projet<br />
# Pour l'exemple, activez le service (ou hook) ''Email'' depuis les paramètres du dépôt: à chaque fois que vous ou un de vos collaborateurs ferra un '''git push''', vous recevrez une notification par mail.<br />
# Activez le service Travis-CI: identifiez-vous (''sign in'') sur https://travis-ci.org/ avec votre compte GitHub<br />
# Activez le service pour les projets sur lesquels vous souhaitez appliquer les principes d'intégration continue<br />
<br />
Travis-CI utilise un fichier nommé '''.travis.yml''' (attention: fichier caché sous Unix) pour se configurer et choisir les opérations à effectuer.<br />
Ce fichier doit se trouver à la racine de votre dépôt Git.<br />
<br />
Faites un '''Commit''' puis un '''Push''' du fichier '''.travis.yml''' ci-dessous.<br />
<br />
<pre><br />
language: java<br />
<br />
jdk:<br />
- oraclejdk7<br />
- openjdk6<br />
- openjdk7<br />
<br />
script:<br />
- pushd cron4j-original && ant rel && popd<br />
</pre><br />
<br />
Ce fichier indique que le projet dans ce dépôt doit être testé sur 3 versions de Java (Oracle Java 7, Open JDK 6 et Open JDK 7), et que le script à exécuter pour lancer les tests est '''pushd cron4j-original && ant rel && popd'''.<br />
Travis-CI peut exécuter plusieurs commandes dans script, chacune d'entre elles devant démarrer par un '-' (élément dans une liste de 'scripts').<br />
<br />
Attention: il n'est pas possible d'utiliser '''cd''' pour changer de répertoire, il faut utiliser '''pushd''' (déplacement dans un dossier) et '''popd''' (retour au dossier précédent) à la place.<br />
<br />
Une fois ce fichier de configuration '''pushé''', Travis-CI se mettra en route dès le prochain '''push'''.<br />
<br />
===Maven===<br />
<br />
[http://maven.apache.org/download.cgi Charger et installer Maven 3].<br />
<br />
<pre><br />
mvn -version<br />
</pre><br />
<br />
Faites une copie du projet, basée sur Maven:<br />
<br />
# Dans votre dépôt Git, créez un dossier '''cron4j-mvn''': il contiendra le projet Cron4J avec la structure Maven<br />
# Dans ce dossier, utilisez l'[https://maven.apache.org/guides/introduction/introduction-to-archetypes.html archetype] Maven [http://maven.apache.org/archetype/maven-archetype-bundles/maven-archetype-quickstart/ maven-archetype-quickstart] (la version des sources de cron4j utilisés est la 2.5.5):<br />
#:<pre>mvn archetype:generate -DarchetypeGroupId=org.apache.maven.archetypes -DarchetypeArtifactId=maven-archetype-quickstart</pre><br />
# Cette commande crée un projet avec un fichier ''pom.xml'', et une classe et un test modèles: supprimez ces modèles<br />
# Copiez les sources de Cron4J depuis le dossier '''cron4j-original''' dans le dossier '''src/main/java''' de votre projet Maven<br />
# Faites un essai de compilation:<br />
#:<pre>mvn clean verify</pre><br />
# Enfin modifiez le fichier '''.travis.yml''' à la racine de votre dépôt Git afin que Travis exécute la commande '''mvn clean verify''' à chaque mise à jour du dépôt GitHub.<br />
<br />
===Tests Unitaires avec JUnit 4===<br />
Survoller le tutoriel [http://www.vogella.com/tutorials/JUnit/article.html Unit Testing with JUnit]<br />
<br />
# Ajouter le test unitaire suivant au projet, dans le fichier '''src/test/it/sauronsoftware/SchedulingPatternTest.java<br />
<pre><br />
package it.sauronsoftware;<br />
<br />
import it.sauronsoftware.cron4j.SchedulingPattern;<br />
import it.sauronsoftware.cron4j.InvalidPatternException;<br />
<br />
import static org.junit.Assert.assertEquals;<br />
import static org.junit.Assert.assertTrue;<br />
<br />
import org.junit.AfterClass;<br />
import org.junit.BeforeClass;<br />
import org.junit.Test;<br />
<br />
public class SchedulingPatternTest {<br />
<br />
@BeforeClass<br />
public static void testSetup() {<br />
}<br />
<br />
@AfterClass<br />
public static void testCleanup() {<br />
// Teardown for data used by the unit tests<br />
}<br />
<br />
@Test(expected = InvalidPatternException.class)<br />
public void testExceptionIsThrown() {<br />
SchedulingPattern sp = new SchedulingPattern("0 5 * *");<br />
}<br />
<br />
@Test<br />
public void testPattern() {<br />
String pattern;<br />
pattern="0 5 * * *|8 10 * * *|22 17 * * *";<br />
assertTrue(pattern + "is correct", SchedulingPattern.validate(pattern));<br />
pattern="0 5 * *";<br />
assertTrue(pattern + "is correct", SchedulingPattern.validate(pattern));<br />
}<br />
}<br />
</pre><br />
<br />
# Committez et Pushez ce nouveau fichier, pour que Travis lance les tests dès que possible<br />
# Lancez les tests unitaires avec <pre>mvn test</pre> Ce test va '''échouer''': corrigez le.<br />
# Committez et Pushez la version corrigée des tests: Travis enverra un mail pour indiquer si les tests échouent ou non<br />
#: '''Attention:''' Travis va exécuter les tests ''dès que possible''. Il est possible de recevoir un mail indiquant que les tests du premier ''push'' échouent alors que l'on a déjà ''pushé'' la correction.<br />
# Naviguez sur http://travis-ci.org pour vérifier les builds effectués.<br />
# Créez des tests unitaires supplémentaire du i.s.c.CronParser<br />
<br />
===Git (suite)===<br />
<br />
# Forkez le projet '''tagl''' d'un autre binome (i.e. autre que ''donsez/tagl'')<br />
#: '''Attention:''' donnez lui un nom différent (e.g. ''tagl-licensing'')<br />
# Clonez ce nouveau dépôt<br />
# Lancez une compilation pour valider l'état du projet (bonne pratique)<br />
#:<pre>mvn clean verify</pre><br />
# Ajoutez une bannière de licence dans le fichier '''cron4j-mvn/pom.xml'''<br />
# Lancez une nouvelle compilation pour valider vos modifications<br />
# Commitez et pushez (vers votre fork de ce dépôt, i.e. ''tagl-licensing'')<br />
# Via le site de GitHub, proposez un "Pull Request" au projet initial<br />
<br />
Vous pouvez ensuite supprimer le clone de ce fork.<br />
Lorsque le ''pull request'' aura été accepté, vous pourrez supprimer votre fork (''tagl-licensing'') de votre compte GitHub.<br />
<br />
===Contrôle Continu===<br />
<br />
Dans votre dépôt ''tagl''.<br />
<br />
# Ajoutez le plugin [http://mojo.codehaus.org/cobertura-maven-plugin/usage.html Cobertura] à votre projet Maven.<br />
## Configurez le plugin pour [http://mojo.codehaus.org/cobertura-maven-plugin/examples/report-formats.html générer un rapport] HTML. Le résultat se trouvera dans ''target/site/cobertura''<br />
## Le plugin ne s'exécute automatiquement pas durant la compilation, il faut utiliser la commande : <pre>mvn cobertura:cobertura</pre><br />
## '''Bonus:''' Modifiez le fichier ''pom.xml'' pour que le ''goal'' '''cobertura''' soit exécuté pendant la ''phase'' '''package'''.<br />
# Répondez aux questions : ''Mais qu'est ce que la couverture de code ? En quoi c'est utile ?''<br />
# Ajoutez au projet Maven les plugins pour la génération d'un site et de rapports (Javadoc, tests unitaires, tags list (FIXME, TODO, ...), ...): voir http://maven.apache.org/plugins/maven-site-plugin/ et d'autres.<br />
# Regardez les exemples d'utilisation de cron4j dans cron4j-original/examples<br />
<br />
===Bonus Track===<br />
<br />
====Clone SVN -> Git====<br />
<br />
Source: http://www.yterium.net/Migrer-un-projet-SVN-vers-GIT<br />
<br />
<syntaxhighlight lang="bash"><br />
# Cloner le dépôt SVN en dépôt Git (conservation historique)<br />
$ git svn clone svn://svn.code.sf.net/p/cron4j/code/trunk cron4j-original<br />
$ cd cron4j-original<br />
# Test compilation<br />
$ ant jar<br />
$ cd ..<br />
</syntaxhighlight><br />
<br />
====Préparation TAGL====<br />
<br />
<syntaxhighlight lang="bash"><br />
# Clone du dépôt TAGL<br />
$ git clone git@github.com:donsez/tagl.git<br />
$ cd tagl<br />
# "Fetch" du dépôt local cloné précédemment<br />
$ git fetch file://$(pwd)/../cron4j-original<br />
# Fusion de ce qui vient d'être fetché<br />
$ git merge FETCH_HEAD<br />
# Envoi sur le serveur<br />
$ git push<br />
</syntaxhighlight><br />
<br />
<br />
====Cherry-picking: reprise des modifications d'un collègue====<br />
<br />
On considère que:<br />
<br />
* votre dépôt Git distant est à l'adresse URL_DEPOT<br />
* votre collègue a un dépôt Git à l'adresse URL_COLLEGUE<br />
<br />
<br />
<syntaxhighlight lang="bash"><br />
# Dossier temporaire<br />
cd /tmp<br />
<br />
# Clone de votre dépôt<br />
git clone URL_DEPOT mon_depot<br />
<br />
# Déplacement dans votre dépôt<br />
cd mon_depot<br />
<br />
# Définition du dépôt distant<br />
git remote add collegue URL_COLLEGUE<br />
<br />
# Récupération des infos du dépôt du collègue<br />
git fetch collegue<br />
<br />
# Maintenant, on peut voir les branches du collègue<br />
git branch -a<br />
<br />
# On peut fusionner avec une branche<br />
git merge collegue/master<br />
<br />
# Si vous avez des conflits, éditez les fichiers concernés,<br />
# et committez avec git commit<br />
<br />
# Push vers votre dépôt distant<br />
git push origin<br />
<br />
# Optionnel: supprimez la référence vers le dépôt du collègue<br />
git remote rm collegue<br />
</syntaxhighlight><br />
<br />
<br />
====Archetype webapp====<br />
L'archetype webapp (http://maven.apache.org/archetype/maven-archetype-bundles/maven-archetype-webapp/) permet de créer le squelette d'une webapp. Créez un simple webapp monsite en version 0.1.0. (add/commit/push). Vous pourrez tester cette webapp en ajoutant au pom.xml le [https://wiki.eclipse.org/Jetty/Feature/Jetty_Maven_Plugin plugin maven Jetty].<br />
<br />
<syntaxhighlight lang="bash"><br />
mvn -Djetty.port=9999 jetty:run<br />
</syntaxhighlight><br />
<br />
Naviguez sur http://localhost:9999/monsite<br />
<br />
====Scrum tools====<br />
Ces 3 services peuvent être couplé à votre dépôt GitHub pour votre gestion de projet agile avec [[Scrum]] :<br />
* http://www.acunote.com/<br />
* http://backlogtool.com/<br />
* http://www.scrumdo.com/<br />
<br />
L'activation se fait via ''Settings > Webhooks & Services > Configure services''.<br />
<br />
==Séance 2: AOP & AspectJ==<br />
<br />
Dans votre dépôt Git, projet ''cron4j-mvn''.<br />
<br />
# Ajoutez le [http://mojo.codehaus.org/aspectj-maven-plugin/ plugin Maven pour AspectJ] au pom.xml<br />
# Ajoutez un aspect de trace à l'invocation des méthodes '''run()''' de l'interface java.lang.Runnable (uniquement pour les objets ''schedulé''s)<br />
#: Affichez une trace avant et après l'exécution de la tâche<br />
# Préparez un nouveau test (nouvelle classe) démarrant un Scheduler Cron4j et validant l'exécution d'une tâche au bout d'une minute (pattern "* * * * *")<br />
#: Lors de l'exécution de '''mvn test''', vous devez voir apparaître les traces préparées dans votre aspect.<br />
<br />
Liens utiles:<br />
* [http://ridgetopsolutions.com/blog/2013/02/12/getting-started-with-aspectj-and-maven/ Getting started with AspectJ and Maven]<br />
<br />
===Contrôle continu===<br />
<br />
# Complétez l'aspect de trace avec le positionnement du [http://docs.oracle.com/javase/7/docs/api/java/lang/ThreadLocal.html java.lang.ThreadLocal] pour passer 1) l'identifiant du job et 2) le compteur des appels de la méthode de l'objet.<br />
<br />
==Séance 3==<br />
@WIP<br />
<br />
Injection de dépendances avec [[Guice]] <br />
<br />
<br />
==Séance 4==<br />
[[Tutorial OSGi avec Apache Felix]]<br />
<br />
<br />
<br />
==Séance 5==<br />
Faire un projet PDE pour un bundle cron4j.gogo (indépendant de cron4j.bundle)<br />
<br />
Utilisation de https://eclipse.org/tycho/</div>Calmanthttps://air.imag.fr/index.php?title=TAGL/TP&diff=15666TAGL/TP2014-02-20T16:45:54Z<p>Calmant: /* Séance 2: AOP & AspectJ */</p>
<hr />
<div>Travaux pratiques de l'UE [[TAGL]].<br />
<br />
==Séance 1==<br />
===Git===<br />
<br />
Création d'un dépôt Git local<br />
<br />
====Méthode simple: init first====<br />
<br />
Via cette méthode, on crée un dépôt local, avec un répertoire de travail, puis on pousse ses modifications vers un dépôt "bare".<br />
Cette méthode est la plus simple, car on dispose immédiatement d'un répertoire de travail.<br />
<br />
<syntaxhighlight lang="bash"><br />
# Création d'un dépôt Git dans le dossier simple-repo<br />
git init simple-repo<br />
<br />
# Création d'un README<br />
cd simple-repo<br />
echo "Hello, World" > README<br />
<br />
# Ajout du versionnement du fichier README<br />
git add README<br />
<br />
# Commit<br />
git commit<br />
</syntaxhighlight><br />
<br />
À ce niveau, on a un dépôt Git complètement fonctionnel.<br />
Cependant, il est intéressant de pousser ses modifications vers un autre dépôt, sur une autre machine.<br />
On va donc créer un dépôt bare sur une autre machine (ou autre dossier pour l'exemple)<br />
<br />
<syntaxhighlight lang="bash"><br />
git init --bare server-repo<br />
</syntaxhighlight><br />
<br />
On considère que l'URL pour accéder à ce dépôt est URL_REPO.<br />
On va d'abord ajouter ce dépôt serveur à la liste des dépôts connu-repos de votre dépôt local.<br />
Étant donné qu'il s'agit du dépôt "principal" à utiliser, on l'appellera //origin//, par convention.<br />
<br />
<syntaxhighlight lang="bash"><br />
git remote add origin URL_REPO<br />
# Récupération de ses informations<br />
git fetch origin<br />
</syntaxhighlight><br />
<br />
Ce serveur distant est "vide": il n'a aucune branche. On va donc enregistrer notre branche sur le serveur<br />
<br />
<syntaxhighlight lang="bash"><br />
git push origin master<br />
</syntaxhighlight><br />
<br />
À partir de cette commande, la branche locale //master// sera liée à la branche distante //origin/master//.<br />
Lors des prochaines commandes ''git push'', grâce à cette liaison, tous les commits sur la branche locale //master// seront poussées sur le serveur distant.<br />
<br />
====Méthode moins simple: bare first====<br />
<br />
Si on commence dans par le serveur "vide", il faudra le cloner au lieu de le définir comme un dépôt distant.<br />
<br />
<syntaxhighlight lang="bash"><br />
# Création du dépôt vide<br />
git init --bare server-repo<br />
</syntaxhighlight><br />
<br />
On considère que ce dépôt est accessible à l'URL URL_REPO<br />
<br />
<syntaxhighlight lang="bash"><br />
# Clonage du dépôt<br />
git clone URL_REPO clone-repo<br />
</syntaxhighlight><br />
<br />
Un avertissement indique que l'on clone un dépôt vide: le dépôt local à donc une branche master, mais elle n'est pas liée au dépôt distant, car celui-ci n'a aucune branche.<br />
Le dépôt distant est automatiquement appelé //origin//.<br />
<br />
<syntaxhighlight lang="bash"><br />
# Commit dans le dépôt local<br />
cd clone-repo<br />
echo hello > readme.rst<br />
git add readme.rst<br />
git commit et ses dépendances<br />
</syntaxhighlight><br />
<br />
Comme dans la méthode simple, il faut pousser la branche master vers le dépôt distant:<br />
<br />
<syntaxhighlight lang="bash"><br />
git push origin master<br />
</syntaxhighlight><br />
<br />
===De l'importance des README===<br />
<br />
Il est très important d'avoir au moins 2 fichiers dans votre dépôt Git:<br />
<br />
* LICENSE: contenant le texte **complet** de la licence de votre projet<br />
* README: décrivant votre projet et comment l'utiliser. Ce fichier doit rappeler le nom de la licence de votre projet<br />
<br />
Il est aussi recommandé d'avoir les fichiers suivants:<br />
<br />
* AUTHORS: contenant la liste des noms/pseudos et e-mails des auteurs de commits ou de code inclus dans ce projet<br />
* INSTALL: contenant la liste des dépendances de ce projet et des commandes à utiliser pour le compiler et l'installer<br />
<br />
Les fichiers LICENSE sont des fichiers textes bruts.<br />
Les autres fichiers sont généralement dans un format offrant un peu plus de lisibilté, par exemple dans les formats [http://daringfireball.net/projects/markdown/ Markdown] (.md) ou [http://docutils.sourceforge.net/rst.html reStructuredText] (.rst)<br />
<br />
Un plug-in existe pour éditer des fichier reStructuredText dans Eclipse: ReST Editor, disponible sur le [https://marketplace.eclipse.org/content/rest-editor Marketplace Eclipse]<br />
<br />
===GitHub & Travis-CI===<br />
<br />
Travis-CI est un service permettant d'exécuter un script dans une machine virtuelle Ubuntu dès que vous effectuez un push sur un de vos dépôts GitHub.<br />
L'intérêt est de savoir si la version d'un projet que vous avez rendu publique peut être compilée et si ses tests passent.<br />
<br />
La machine virtuelle "offerte" par Travis est préconfigurée pour le language indiqué dans son fichier de configuration ('''.travis.yml'''), mais il est possible d'utiliser la commande '''sudo apt-get install ...''' pour ajouter vos dépendances.<br />
<br />
Pour utiliser Travis:<br />
<br />
# Créez compte individuel sur GitHub https://github.com<br />
# ''Fork''ez le projet TAGL '''cron4j''' depuis https://github.com/donsez/tagl<br />
# Ajoutez un collaborateur (i.e. votre binôme) au projet ''forké'', via les paramètres (''settings'') de ce projet<br />
# Pour l'exemple, activez le service (ou hook) ''Email'' depuis les paramètres du dépôt: à chaque fois que vous ou un de vos collaborateurs ferra un '''git push''', vous recevrez une notification par mail.<br />
# Activez le service Travis-CI: identifiez-vous (''sign in'') sur https://travis-ci.org/ avec votre compte GitHub<br />
# Activez le service pour les projets sur lesquels vous souhaitez appliquer les principes d'intégration continue<br />
<br />
Travis-CI utilise un fichier nommé '''.travis.yml''' (attention: fichier caché sous Unix) pour se configurer et choisir les opérations à effectuer.<br />
Ce fichier doit se trouver à la racine de votre dépôt Git.<br />
<br />
Faites un '''Commit''' puis un '''Push''' du fichier '''.travis.yml''' ci-dessous.<br />
<br />
<pre><br />
language: java<br />
<br />
jdk:<br />
- oraclejdk7<br />
- openjdk6<br />
- openjdk7<br />
<br />
script:<br />
- pushd cron4j-original && ant rel && popd<br />
</pre><br />
<br />
Ce fichier indique que le projet dans ce dépôt doit être testé sur 3 versions de Java (Oracle Java 7, Open JDK 6 et Open JDK 7), et que le script à exécuter pour lancer les tests est '''pushd cron4j-original && ant rel && popd'''.<br />
Travis-CI peut exécuter plusieurs commandes dans script, chacune d'entre elles devant démarrer par un '-' (élément dans une liste de 'scripts').<br />
<br />
Attention: il n'est pas possible d'utiliser '''cd''' pour changer de répertoire, il faut utiliser '''pushd''' (déplacement dans un dossier) et '''popd''' (retour au dossier précédent) à la place.<br />
<br />
Une fois ce fichier de configuration '''pushé''', Travis-CI se mettra en route dès le prochain '''push'''.<br />
<br />
===Maven===<br />
<br />
[http://maven.apache.org/download.cgi Charger et installer Maven 3].<br />
<br />
<pre><br />
mvn -version<br />
</pre><br />
<br />
Faites une copie du projet, basée sur Maven:<br />
<br />
# Dans votre dépôt Git, créez un dossier '''cron4j-mvn''': il contiendra le projet Cron4J avec la structure Maven<br />
# Dans ce dossier, utilisez l'[https://maven.apache.org/guides/introduction/introduction-to-archetypes.html archetype] Maven [http://maven.apache.org/archetype/maven-archetype-bundles/maven-archetype-quickstart/ maven-archetype-quickstart] (la version des sources de cron4j utilisés est la 2.5.5):<br />
#:<pre>mvn archetype:generate -DarchetypeGroupId=org.apache.maven.archetypes -DarchetypeArtifactId=maven-archetype-quickstart</pre><br />
# Cette commande crée un projet avec un fichier ''pom.xml'', et une classe et un test modèles: supprimez ces modèles<br />
# Copiez les sources de Cron4J depuis le dossier '''cron4j-original''' dans le dossier '''src/main/java''' de votre projet Maven<br />
# Faites un essai de compilation:<br />
#:<pre>mvn clean verify</pre><br />
# Enfin modifiez le fichier '''.travis.yml''' à la racine de votre dépôt Git afin que Travis exécute la commande '''mvn clean verify''' à chaque mise à jour du dépôt GitHub.<br />
<br />
===Tests Unitaires avec JUnit 4===<br />
Survoller le tutoriel [http://www.vogella.com/tutorials/JUnit/article.html Unit Testing with JUnit]<br />
<br />
# Ajouter le test unitaire suivant au projet, dans le fichier '''src/test/it/sauronsoftware/SchedulingPatternTest.java<br />
<pre><br />
package it.sauronsoftware;<br />
<br />
import it.sauronsoftware.cron4j.SchedulingPattern;<br />
import it.sauronsoftware.cron4j.InvalidPatternException;<br />
<br />
import static org.junit.Assert.assertEquals;<br />
import static org.junit.Assert.assertTrue;<br />
<br />
import org.junit.AfterClass;<br />
import org.junit.BeforeClass;<br />
import org.junit.Test;<br />
<br />
public class SchedulingPatternTest {<br />
<br />
@BeforeClass<br />
public static void testSetup() {<br />
}<br />
<br />
@AfterClass<br />
public static void testCleanup() {<br />
// Teardown for data used by the unit tests<br />
}<br />
<br />
@Test(expected = InvalidPatternException.class)<br />
public void testExceptionIsThrown() {<br />
SchedulingPattern sp = new SchedulingPattern("0 5 * *");<br />
}<br />
<br />
@Test<br />
public void testPattern() {<br />
String pattern;<br />
pattern="0 5 * * *|8 10 * * *|22 17 * * *";<br />
assertTrue(pattern + "is correct", SchedulingPattern.validate(pattern));<br />
pattern="0 5 * *";<br />
assertTrue(pattern + "is correct", SchedulingPattern.validate(pattern));<br />
}<br />
}<br />
</pre><br />
<br />
# Committez et Pushez ce nouveau fichier, pour que Travis lance les tests dès que possible<br />
# Lancez les tests unitaires avec <pre>mvn test</pre> Ce test va '''échouer''': corrigez le.<br />
# Committez et Pushez la version corrigée des tests: Travis enverra un mail pour indiquer si les tests échouent ou non<br />
#: '''Attention:''' Travis va exécuter les tests ''dès que possible''. Il est possible de recevoir un mail indiquant que les tests du premier ''push'' échouent alors que l'on a déjà ''pushé'' la correction.<br />
# Naviguez sur http://travis-ci.org pour vérifier les builds effectués.<br />
# Créez des tests unitaires supplémentaire du i.s.c.CronParser<br />
<br />
===Git (suite)===<br />
<br />
# Forkez le projet '''tagl''' d'un autre binome (i.e. autre que ''donsez/tagl'')<br />
#: '''Attention:''' donnez lui un nom différent (e.g. ''tagl-licensing'')<br />
# Clonez ce nouveau dépôt<br />
# Lancez une compilation pour valider l'état du projet (bonne pratique)<br />
#:<pre>mvn clean verify</pre><br />
# Ajoutez une bannière de licence dans le fichier '''cron4j-mvn/pom.xml'''<br />
# Lancez une nouvelle compilation pour valider vos modifications<br />
# Commitez et pushez (vers votre fork de ce dépôt, i.e. ''tagl-licensing'')<br />
# Via le site de GitHub, proposez un "Pull Request" au projet initial<br />
<br />
Vous pouvez ensuite supprimer le clone de ce fork.<br />
Lorsque le ''pull request'' aura été accepté, vous pourrez supprimer votre fork (''tagl-licensing'') de votre compte GitHub.<br />
<br />
===Contrôle Continu===<br />
<br />
Dans votre dépôt ''tagl''.<br />
<br />
# Ajoutez le plugin [http://mojo.codehaus.org/cobertura-maven-plugin/usage.html Cobertura] à votre projet Maven.<br />
## Configurez le plugin pour [http://mojo.codehaus.org/cobertura-maven-plugin/examples/report-formats.html générer un rapport] HTML. Le résultat se trouvera dans ''target/site/cobertura''<br />
## Le plugin ne s'exécute automatiquement pas durant la compilation, il faut utiliser la commande : <pre>mvn cobertura:cobertura</pre><br />
## '''Bonus:''' Modifiez le fichier ''pom.xml'' pour que le ''goal'' '''cobertura''' soit exécuté pendant la ''phase'' '''package'''.<br />
# Répondez aux questions : ''Mais qu'est ce que la couverture de code ? En quoi c'est utile ?''<br />
# Ajoutez au projet Maven les plugins pour la génération d'un site et de rapports (Javadoc, tests unitaires, tags list (FIXME, TODO, ...), ...): voir http://maven.apache.org/plugins/maven-site-plugin/ et d'autres.<br />
# Regardez les exemples d'utilisation de cron4j dans cron4j-original/examples<br />
<br />
===Bonus Track===<br />
<br />
====Clone SVN -> Git====<br />
<br />
Source: http://www.yterium.net/Migrer-un-projet-SVN-vers-GIT<br />
<br />
<syntaxhighlight lang="bash"><br />
# Cloner le dépôt SVN en dépôt Git (conservation historique)<br />
$ git svn clone svn://svn.code.sf.net/p/cron4j/code/trunk cron4j-original<br />
$ cd cron4j-original<br />
# Test compilation<br />
$ ant jar<br />
$ cd ..<br />
</syntaxhighlight><br />
<br />
====Préparation TAGL====<br />
<br />
<syntaxhighlight lang="bash"><br />
# Clone du dépôt TAGL<br />
$ git clone git@github.com:donsez/tagl.git<br />
$ cd tagl<br />
# "Fetch" du dépôt local cloné précédemment<br />
$ git fetch file://$(pwd)/../cron4j-original<br />
# Fusion de ce qui vient d'être fetché<br />
$ git merge FETCH_HEAD<br />
# Envoi sur le serveur<br />
$ git push<br />
</syntaxhighlight><br />
<br />
<br />
====Cherry-picking: reprise des modifications d'un collègue====<br />
<br />
On considère que:<br />
<br />
* votre dépôt Git distant est à l'adresse URL_DEPOT<br />
* votre collègue a un dépôt Git à l'adresse URL_COLLEGUE<br />
<br />
<br />
<syntaxhighlight lang="bash"><br />
# Dossier temporaire<br />
cd /tmp<br />
<br />
# Clone de votre dépôt<br />
git clone URL_DEPOT mon_depot<br />
<br />
# Déplacement dans votre dépôt<br />
cd mon_depot<br />
<br />
# Définition du dépôt distant<br />
git remote add collegue URL_COLLEGUE<br />
<br />
# Récupération des infos du dépôt du collègue<br />
git fetch collegue<br />
<br />
# Maintenant, on peut voir les branches du collègue<br />
git branch -a<br />
<br />
# On peut fusionner avec une branche<br />
git merge collegue/master<br />
<br />
# Si vous avez des conflits, éditez les fichiers concernés,<br />
# et committez avec git commit<br />
<br />
# Push vers votre dépôt distant<br />
git push origin<br />
<br />
# Optionnel: supprimez la référence vers le dépôt du collègue<br />
git remote rm collegue<br />
</syntaxhighlight><br />
<br />
<br />
====Archetype webapp====<br />
L'archetype webapp (http://maven.apache.org/archetype/maven-archetype-bundles/maven-archetype-webapp/) permet de créer le squelette d'une webapp. Créez un simple webapp monsite en version 0.1.0. (add/commit/push). Vous pourrez tester cette webapp en ajoutant au pom.xml le [https://wiki.eclipse.org/Jetty/Feature/Jetty_Maven_Plugin plugin maven Jetty].<br />
<br />
<syntaxhighlight lang="bash"><br />
mvn -Djetty.port=9999 jetty:run<br />
</syntaxhighlight><br />
<br />
Naviguez sur http://localhost:9999/monsite<br />
<br />
====Scrum tools====<br />
Ces 3 services peuvent être couplé à votre dépôt GitHub pour votre gestion de projet agile avec [[Scrum]] :<br />
* http://www.acunote.com/<br />
* http://backlogtool.com/<br />
* http://www.scrumdo.com/<br />
<br />
L'activation se fait via ''Settings > Webhooks & Services > Configure services''.<br />
<br />
==Séance 2: AOP & AspectJ==<br />
<br />
Dans votre dépôt Git, projet ''cron4j-mvn''.<br />
<br />
# Ajoutez le [http://mojo.codehaus.org/aspectj-maven-plugin/ plugin Maven pour AspectJ] au pom.xml<br />
# Ajoutez un aspect de trace à l'invocation des méthodes '''run()''' de l'interface java.lang.Runnable (uniquement pour les objets ''schedulé''s).<br />
<br />
Liens utiles:<br />
* [http://ridgetopsolutions.com/blog/2013/02/12/getting-started-with-aspectj-and-maven/ Getting started with AspectJ and Maven]<br />
<br />
===Contrôle continu===<br />
<br />
# Complétez l'aspect de trace avec le positionnement du [http://docs.oracle.com/javase/7/docs/api/java/lang/ThreadLocal.html java.lang.ThreadLocal] pour passer 1) l'identifiant du job et 2) le compteur des appels de la méthode de l'objet.<br />
<br />
==Séance 3==<br />
@WIP<br />
<br />
Injection de dépendances avec [[Guice]] <br />
<br />
<br />
==Séance 4==<br />
[[Tutorial OSGi avec Apache Felix]]<br />
<br />
<br />
<br />
==Séance 5==<br />
Faire un projet PDE pour un bundle cron4j.gogo (indépendant de cron4j.bundle)<br />
<br />
Utilisation de https://eclipse.org/tycho/</div>Calmanthttps://air.imag.fr/index.php?title=TAGL/TP&diff=15665TAGL/TP2014-02-20T16:00:41Z<p>Calmant: /* Séance 2 */</p>
<hr />
<div>Travaux pratiques de l'UE [[TAGL]].<br />
<br />
==Séance 1==<br />
===Git===<br />
<br />
Création d'un dépôt Git local<br />
<br />
====Méthode simple: init first====<br />
<br />
Via cette méthode, on crée un dépôt local, avec un répertoire de travail, puis on pousse ses modifications vers un dépôt "bare".<br />
Cette méthode est la plus simple, car on dispose immédiatement d'un répertoire de travail.<br />
<br />
<syntaxhighlight lang="bash"><br />
# Création d'un dépôt Git dans le dossier simple-repo<br />
git init simple-repo<br />
<br />
# Création d'un README<br />
cd simple-repo<br />
echo "Hello, World" > README<br />
<br />
# Ajout du versionnement du fichier README<br />
git add README<br />
<br />
# Commit<br />
git commit<br />
</syntaxhighlight><br />
<br />
À ce niveau, on a un dépôt Git complètement fonctionnel.<br />
Cependant, il est intéressant de pousser ses modifications vers un autre dépôt, sur une autre machine.<br />
On va donc créer un dépôt bare sur une autre machine (ou autre dossier pour l'exemple)<br />
<br />
<syntaxhighlight lang="bash"><br />
git init --bare server-repo<br />
</syntaxhighlight><br />
<br />
On considère que l'URL pour accéder à ce dépôt est URL_REPO.<br />
On va d'abord ajouter ce dépôt serveur à la liste des dépôts connu-repos de votre dépôt local.<br />
Étant donné qu'il s'agit du dépôt "principal" à utiliser, on l'appellera //origin//, par convention.<br />
<br />
<syntaxhighlight lang="bash"><br />
git remote add origin URL_REPO<br />
# Récupération de ses informations<br />
git fetch origin<br />
</syntaxhighlight><br />
<br />
Ce serveur distant est "vide": il n'a aucune branche. On va donc enregistrer notre branche sur le serveur<br />
<br />
<syntaxhighlight lang="bash"><br />
git push origin master<br />
</syntaxhighlight><br />
<br />
À partir de cette commande, la branche locale //master// sera liée à la branche distante //origin/master//.<br />
Lors des prochaines commandes ''git push'', grâce à cette liaison, tous les commits sur la branche locale //master// seront poussées sur le serveur distant.<br />
<br />
====Méthode moins simple: bare first====<br />
<br />
Si on commence dans par le serveur "vide", il faudra le cloner au lieu de le définir comme un dépôt distant.<br />
<br />
<syntaxhighlight lang="bash"><br />
# Création du dépôt vide<br />
git init --bare server-repo<br />
</syntaxhighlight><br />
<br />
On considère que ce dépôt est accessible à l'URL URL_REPO<br />
<br />
<syntaxhighlight lang="bash"><br />
# Clonage du dépôt<br />
git clone URL_REPO clone-repo<br />
</syntaxhighlight><br />
<br />
Un avertissement indique que l'on clone un dépôt vide: le dépôt local à donc une branche master, mais elle n'est pas liée au dépôt distant, car celui-ci n'a aucune branche.<br />
Le dépôt distant est automatiquement appelé //origin//.<br />
<br />
<syntaxhighlight lang="bash"><br />
# Commit dans le dépôt local<br />
cd clone-repo<br />
echo hello > readme.rst<br />
git add readme.rst<br />
git commit et ses dépendances<br />
</syntaxhighlight><br />
<br />
Comme dans la méthode simple, il faut pousser la branche master vers le dépôt distant:<br />
<br />
<syntaxhighlight lang="bash"><br />
git push origin master<br />
</syntaxhighlight><br />
<br />
===De l'importance des README===<br />
<br />
Il est très important d'avoir au moins 2 fichiers dans votre dépôt Git:<br />
<br />
* LICENSE: contenant le texte **complet** de la licence de votre projet<br />
* README: décrivant votre projet et comment l'utiliser. Ce fichier doit rappeler le nom de la licence de votre projet<br />
<br />
Il est aussi recommandé d'avoir les fichiers suivants:<br />
<br />
* AUTHORS: contenant la liste des noms/pseudos et e-mails des auteurs de commits ou de code inclus dans ce projet<br />
* INSTALL: contenant la liste des dépendances de ce projet et des commandes à utiliser pour le compiler et l'installer<br />
<br />
Les fichiers LICENSE sont des fichiers textes bruts.<br />
Les autres fichiers sont généralement dans un format offrant un peu plus de lisibilté, par exemple dans les formats [http://daringfireball.net/projects/markdown/ Markdown] (.md) ou [http://docutils.sourceforge.net/rst.html reStructuredText] (.rst)<br />
<br />
Un plug-in existe pour éditer des fichier reStructuredText dans Eclipse: ReST Editor, disponible sur le [https://marketplace.eclipse.org/content/rest-editor Marketplace Eclipse]<br />
<br />
===GitHub & Travis-CI===<br />
<br />
Travis-CI est un service permettant d'exécuter un script dans une machine virtuelle Ubuntu dès que vous effectuez un push sur un de vos dépôts GitHub.<br />
L'intérêt est de savoir si la version d'un projet que vous avez rendu publique peut être compilée et si ses tests passent.<br />
<br />
La machine virtuelle "offerte" par Travis est préconfigurée pour le language indiqué dans son fichier de configuration ('''.travis.yml'''), mais il est possible d'utiliser la commande '''sudo apt-get install ...''' pour ajouter vos dépendances.<br />
<br />
Pour utiliser Travis:<br />
<br />
# Créez compte individuel sur GitHub https://github.com<br />
# ''Fork''ez le projet TAGL '''cron4j''' depuis https://github.com/donsez/tagl<br />
# Ajoutez un collaborateur (i.e. votre binôme) au projet ''forké'', via les paramètres (''settings'') de ce projet<br />
# Pour l'exemple, activez le service (ou hook) ''Email'' depuis les paramètres du dépôt: à chaque fois que vous ou un de vos collaborateurs ferra un '''git push''', vous recevrez une notification par mail.<br />
# Activez le service Travis-CI: identifiez-vous (''sign in'') sur https://travis-ci.org/ avec votre compte GitHub<br />
# Activez le service pour les projets sur lesquels vous souhaitez appliquer les principes d'intégration continue<br />
<br />
Travis-CI utilise un fichier nommé '''.travis.yml''' (attention: fichier caché sous Unix) pour se configurer et choisir les opérations à effectuer.<br />
Ce fichier doit se trouver à la racine de votre dépôt Git.<br />
<br />
Faites un '''Commit''' puis un '''Push''' du fichier '''.travis.yml''' ci-dessous.<br />
<br />
<pre><br />
language: java<br />
<br />
jdk:<br />
- oraclejdk7<br />
- openjdk6<br />
- openjdk7<br />
<br />
script:<br />
- pushd cron4j-original && ant rel && popd<br />
</pre><br />
<br />
Ce fichier indique que le projet dans ce dépôt doit être testé sur 3 versions de Java (Oracle Java 7, Open JDK 6 et Open JDK 7), et que le script à exécuter pour lancer les tests est '''pushd cron4j-original && ant rel && popd'''.<br />
Travis-CI peut exécuter plusieurs commandes dans script, chacune d'entre elles devant démarrer par un '-' (élément dans une liste de 'scripts').<br />
<br />
Attention: il n'est pas possible d'utiliser '''cd''' pour changer de répertoire, il faut utiliser '''pushd''' (déplacement dans un dossier) et '''popd''' (retour au dossier précédent) à la place.<br />
<br />
Une fois ce fichier de configuration '''pushé''', Travis-CI se mettra en route dès le prochain '''push'''.<br />
<br />
===Maven===<br />
<br />
[http://maven.apache.org/download.cgi Charger et installer Maven 3].<br />
<br />
<pre><br />
mvn -version<br />
</pre><br />
<br />
Faites une copie du projet, basée sur Maven:<br />
<br />
# Dans votre dépôt Git, créez un dossier '''cron4j-mvn''': il contiendra le projet Cron4J avec la structure Maven<br />
# Dans ce dossier, utilisez l'[https://maven.apache.org/guides/introduction/introduction-to-archetypes.html archetype] Maven [http://maven.apache.org/archetype/maven-archetype-bundles/maven-archetype-quickstart/ maven-archetype-quickstart] (la version des sources de cron4j utilisés est la 2.5.5):<br />
#:<pre>mvn archetype:generate -DarchetypeGroupId=org.apache.maven.archetypes -DarchetypeArtifactId=maven-archetype-quickstart</pre><br />
# Cette commande crée un projet avec un fichier ''pom.xml'', et une classe et un test modèles: supprimez ces modèles<br />
# Copiez les sources de Cron4J depuis le dossier '''cron4j-original''' dans le dossier '''src/main/java''' de votre projet Maven<br />
# Faites un essai de compilation:<br />
#:<pre>mvn clean verify</pre><br />
# Enfin modifiez le fichier '''.travis.yml''' à la racine de votre dépôt Git afin que Travis exécute la commande '''mvn clean verify''' à chaque mise à jour du dépôt GitHub.<br />
<br />
===Tests Unitaires avec JUnit 4===<br />
Survoller le tutoriel [http://www.vogella.com/tutorials/JUnit/article.html Unit Testing with JUnit]<br />
<br />
# Ajouter le test unitaire suivant au projet, dans le fichier '''src/test/it/sauronsoftware/SchedulingPatternTest.java<br />
<pre><br />
package it.sauronsoftware;<br />
<br />
import it.sauronsoftware.cron4j.SchedulingPattern;<br />
import it.sauronsoftware.cron4j.InvalidPatternException;<br />
<br />
import static org.junit.Assert.assertEquals;<br />
import static org.junit.Assert.assertTrue;<br />
<br />
import org.junit.AfterClass;<br />
import org.junit.BeforeClass;<br />
import org.junit.Test;<br />
<br />
public class SchedulingPatternTest {<br />
<br />
@BeforeClass<br />
public static void testSetup() {<br />
}<br />
<br />
@AfterClass<br />
public static void testCleanup() {<br />
// Teardown for data used by the unit tests<br />
}<br />
<br />
@Test(expected = InvalidPatternException.class)<br />
public void testExceptionIsThrown() {<br />
SchedulingPattern sp = new SchedulingPattern("0 5 * *");<br />
}<br />
<br />
@Test<br />
public void testPattern() {<br />
String pattern;<br />
pattern="0 5 * * *|8 10 * * *|22 17 * * *";<br />
assertTrue(pattern + "is correct", SchedulingPattern.validate(pattern));<br />
pattern="0 5 * *";<br />
assertTrue(pattern + "is correct", SchedulingPattern.validate(pattern));<br />
}<br />
}<br />
</pre><br />
<br />
# Committez et Pushez ce nouveau fichier, pour que Travis lance les tests dès que possible<br />
# Lancez les tests unitaires avec <pre>mvn test</pre> Ce test va '''échouer''': corrigez le.<br />
# Committez et Pushez la version corrigée des tests: Travis enverra un mail pour indiquer si les tests échouent ou non<br />
#: '''Attention:''' Travis va exécuter les tests ''dès que possible''. Il est possible de recevoir un mail indiquant que les tests du premier ''push'' échouent alors que l'on a déjà ''pushé'' la correction.<br />
# Naviguez sur http://travis-ci.org pour vérifier les builds effectués.<br />
# Créez des tests unitaires supplémentaire du i.s.c.CronParser<br />
<br />
===Git (suite)===<br />
<br />
# Forkez le projet '''tagl''' d'un autre binome (i.e. autre que ''donsez/tagl'')<br />
#: '''Attention:''' donnez lui un nom différent (e.g. ''tagl-licensing'')<br />
# Clonez ce nouveau dépôt<br />
# Lancez une compilation pour valider l'état du projet (bonne pratique)<br />
#:<pre>mvn clean verify</pre><br />
# Ajoutez une bannière de licence dans le fichier '''cron4j-mvn/pom.xml'''<br />
# Lancez une nouvelle compilation pour valider vos modifications<br />
# Commitez et pushez (vers votre fork de ce dépôt, i.e. ''tagl-licensing'')<br />
# Via le site de GitHub, proposez un "Pull Request" au projet initial<br />
<br />
Vous pouvez ensuite supprimer le clone de ce fork.<br />
Lorsque le ''pull request'' aura été accepté, vous pourrez supprimer votre fork (''tagl-licensing'') de votre compte GitHub.<br />
<br />
===Contrôle Continu===<br />
<br />
Dans votre dépôt ''tagl''.<br />
<br />
# Ajoutez le plugin [http://mojo.codehaus.org/cobertura-maven-plugin/usage.html Cobertura] à votre projet Maven.<br />
## Configurez le plugin pour [http://mojo.codehaus.org/cobertura-maven-plugin/examples/report-formats.html générer un rapport] HTML. Le résultat se trouvera dans ''target/site/cobertura''<br />
## Le plugin ne s'exécute automatiquement pas durant la compilation, il faut utiliser la commande : <pre>mvn cobertura:cobertura</pre><br />
## '''Bonus:''' Modifiez le fichier ''pom.xml'' pour que le ''goal'' '''cobertura''' soit exécuté pendant la ''phase'' '''package'''.<br />
# Répondez aux questions : ''Mais qu'est ce que la couverture de code ? En quoi c'est utile ?''<br />
# Ajoutez au projet Maven les plugins pour la génération d'un site et de rapports (Javadoc, tests unitaires, tags list (FIXME, TODO, ...), ...): voir http://maven.apache.org/plugins/maven-site-plugin/ et d'autres.<br />
# Regardez les exemples d'utilisation de cron4j dans cron4j-original/examples<br />
<br />
===Bonus Track===<br />
<br />
====Clone SVN -> Git====<br />
<br />
Source: http://www.yterium.net/Migrer-un-projet-SVN-vers-GIT<br />
<br />
<syntaxhighlight lang="bash"><br />
# Cloner le dépôt SVN en dépôt Git (conservation historique)<br />
$ git svn clone svn://svn.code.sf.net/p/cron4j/code/trunk cron4j-original<br />
$ cd cron4j-original<br />
# Test compilation<br />
$ ant jar<br />
$ cd ..<br />
</syntaxhighlight><br />
<br />
====Préparation TAGL====<br />
<br />
<syntaxhighlight lang="bash"><br />
# Clone du dépôt TAGL<br />
$ git clone git@github.com:donsez/tagl.git<br />
$ cd tagl<br />
# "Fetch" du dépôt local cloné précédemment<br />
$ git fetch file://$(pwd)/../cron4j-original<br />
# Fusion de ce qui vient d'être fetché<br />
$ git merge FETCH_HEAD<br />
# Envoi sur le serveur<br />
$ git push<br />
</syntaxhighlight><br />
<br />
<br />
====Cherry-picking: reprise des modifications d'un collègue====<br />
<br />
On considère que:<br />
<br />
* votre dépôt Git distant est à l'adresse URL_DEPOT<br />
* votre collègue a un dépôt Git à l'adresse URL_COLLEGUE<br />
<br />
<br />
<syntaxhighlight lang="bash"><br />
# Dossier temporaire<br />
cd /tmp<br />
<br />
# Clone de votre dépôt<br />
git clone URL_DEPOT mon_depot<br />
<br />
# Déplacement dans votre dépôt<br />
cd mon_depot<br />
<br />
# Définition du dépôt distant<br />
git remote add collegue URL_COLLEGUE<br />
<br />
# Récupération des infos du dépôt du collègue<br />
git fetch collegue<br />
<br />
# Maintenant, on peut voir les branches du collègue<br />
git branch -a<br />
<br />
# On peut fusionner avec une branche<br />
git merge collegue/master<br />
<br />
# Si vous avez des conflits, éditez les fichiers concernés,<br />
# et committez avec git commit<br />
<br />
# Push vers votre dépôt distant<br />
git push origin<br />
<br />
# Optionnel: supprimez la référence vers le dépôt du collègue<br />
git remote rm collegue<br />
</syntaxhighlight><br />
<br />
<br />
====Archetype webapp====<br />
L'archetype webapp (http://maven.apache.org/archetype/maven-archetype-bundles/maven-archetype-webapp/) permet de créer le squelette d'une webapp. Créez un simple webapp monsite en version 0.1.0. (add/commit/push). Vous pourrez tester cette webapp en ajoutant au pom.xml le [https://wiki.eclipse.org/Jetty/Feature/Jetty_Maven_Plugin plugin maven Jetty].<br />
<br />
<syntaxhighlight lang="bash"><br />
mvn -Djetty.port=9999 jetty:run<br />
</syntaxhighlight><br />
<br />
Naviguez sur http://localhost:9999/monsite<br />
<br />
====Scrum tools====<br />
Ces 3 services peuvent être couplé à votre dépôt GitHub pour votre gestion de projet agile avec [[Scrum]] :<br />
* http://www.acunote.com/<br />
* http://backlogtool.com/<br />
* http://www.scrumdo.com/<br />
<br />
L'activation se fait via ''Settings > Webhooks & Services > Configure services''.<br />
<br />
==Séance 2: AOP & AspectJ==<br />
<br />
Dans votre dépôt Git, projet ''cron4j-mvn''.<br />
<br />
# Ajoutez le [http://mojo.codehaus.org/aspectj-maven-plugin/ plugin Maven pour AspectJ] au pom.xml<br />
# Ajoutez un aspect de trace à l'invocation des méthodes '''run()''' de l'interface java.lang.Runnable (uniquement pour les objets ''schedulé''s).<br />
<br />
===Contrôle continu===<br />
<br />
# Complétez l'aspect de trace avec le positionnement du [http://docs.oracle.com/javase/7/docs/api/java/lang/ThreadLocal.html java.lang.ThreadLocal] pour passer 1) l'identifiant du job et 2) le compteur des appels de la méthode de l'objet.<br />
<br />
==Séance 3==<br />
@WIP<br />
<br />
Injection de dépendances avec [[Guice]] <br />
<br />
<br />
==Séance 4==<br />
[[Tutorial OSGi avec Apache Felix]]<br />
<br />
<br />
<br />
==Séance 5==<br />
Faire un projet PDE pour un bundle cron4j.gogo (indépendant de cron4j.bundle)<br />
<br />
Utilisation de https://eclipse.org/tycho/</div>Calmanthttps://air.imag.fr/index.php?title=TAGL/TP&diff=15664TAGL/TP2014-02-20T15:58:23Z<p>Calmant: /* Contrôle Continu */</p>
<hr />
<div>Travaux pratiques de l'UE [[TAGL]].<br />
<br />
==Séance 1==<br />
===Git===<br />
<br />
Création d'un dépôt Git local<br />
<br />
====Méthode simple: init first====<br />
<br />
Via cette méthode, on crée un dépôt local, avec un répertoire de travail, puis on pousse ses modifications vers un dépôt "bare".<br />
Cette méthode est la plus simple, car on dispose immédiatement d'un répertoire de travail.<br />
<br />
<syntaxhighlight lang="bash"><br />
# Création d'un dépôt Git dans le dossier simple-repo<br />
git init simple-repo<br />
<br />
# Création d'un README<br />
cd simple-repo<br />
echo "Hello, World" > README<br />
<br />
# Ajout du versionnement du fichier README<br />
git add README<br />
<br />
# Commit<br />
git commit<br />
</syntaxhighlight><br />
<br />
À ce niveau, on a un dépôt Git complètement fonctionnel.<br />
Cependant, il est intéressant de pousser ses modifications vers un autre dépôt, sur une autre machine.<br />
On va donc créer un dépôt bare sur une autre machine (ou autre dossier pour l'exemple)<br />
<br />
<syntaxhighlight lang="bash"><br />
git init --bare server-repo<br />
</syntaxhighlight><br />
<br />
On considère que l'URL pour accéder à ce dépôt est URL_REPO.<br />
On va d'abord ajouter ce dépôt serveur à la liste des dépôts connu-repos de votre dépôt local.<br />
Étant donné qu'il s'agit du dépôt "principal" à utiliser, on l'appellera //origin//, par convention.<br />
<br />
<syntaxhighlight lang="bash"><br />
git remote add origin URL_REPO<br />
# Récupération de ses informations<br />
git fetch origin<br />
</syntaxhighlight><br />
<br />
Ce serveur distant est "vide": il n'a aucune branche. On va donc enregistrer notre branche sur le serveur<br />
<br />
<syntaxhighlight lang="bash"><br />
git push origin master<br />
</syntaxhighlight><br />
<br />
À partir de cette commande, la branche locale //master// sera liée à la branche distante //origin/master//.<br />
Lors des prochaines commandes ''git push'', grâce à cette liaison, tous les commits sur la branche locale //master// seront poussées sur le serveur distant.<br />
<br />
====Méthode moins simple: bare first====<br />
<br />
Si on commence dans par le serveur "vide", il faudra le cloner au lieu de le définir comme un dépôt distant.<br />
<br />
<syntaxhighlight lang="bash"><br />
# Création du dépôt vide<br />
git init --bare server-repo<br />
</syntaxhighlight><br />
<br />
On considère que ce dépôt est accessible à l'URL URL_REPO<br />
<br />
<syntaxhighlight lang="bash"><br />
# Clonage du dépôt<br />
git clone URL_REPO clone-repo<br />
</syntaxhighlight><br />
<br />
Un avertissement indique que l'on clone un dépôt vide: le dépôt local à donc une branche master, mais elle n'est pas liée au dépôt distant, car celui-ci n'a aucune branche.<br />
Le dépôt distant est automatiquement appelé //origin//.<br />
<br />
<syntaxhighlight lang="bash"><br />
# Commit dans le dépôt local<br />
cd clone-repo<br />
echo hello > readme.rst<br />
git add readme.rst<br />
git commit et ses dépendances<br />
</syntaxhighlight><br />
<br />
Comme dans la méthode simple, il faut pousser la branche master vers le dépôt distant:<br />
<br />
<syntaxhighlight lang="bash"><br />
git push origin master<br />
</syntaxhighlight><br />
<br />
===De l'importance des README===<br />
<br />
Il est très important d'avoir au moins 2 fichiers dans votre dépôt Git:<br />
<br />
* LICENSE: contenant le texte **complet** de la licence de votre projet<br />
* README: décrivant votre projet et comment l'utiliser. Ce fichier doit rappeler le nom de la licence de votre projet<br />
<br />
Il est aussi recommandé d'avoir les fichiers suivants:<br />
<br />
* AUTHORS: contenant la liste des noms/pseudos et e-mails des auteurs de commits ou de code inclus dans ce projet<br />
* INSTALL: contenant la liste des dépendances de ce projet et des commandes à utiliser pour le compiler et l'installer<br />
<br />
Les fichiers LICENSE sont des fichiers textes bruts.<br />
Les autres fichiers sont généralement dans un format offrant un peu plus de lisibilté, par exemple dans les formats [http://daringfireball.net/projects/markdown/ Markdown] (.md) ou [http://docutils.sourceforge.net/rst.html reStructuredText] (.rst)<br />
<br />
Un plug-in existe pour éditer des fichier reStructuredText dans Eclipse: ReST Editor, disponible sur le [https://marketplace.eclipse.org/content/rest-editor Marketplace Eclipse]<br />
<br />
===GitHub & Travis-CI===<br />
<br />
Travis-CI est un service permettant d'exécuter un script dans une machine virtuelle Ubuntu dès que vous effectuez un push sur un de vos dépôts GitHub.<br />
L'intérêt est de savoir si la version d'un projet que vous avez rendu publique peut être compilée et si ses tests passent.<br />
<br />
La machine virtuelle "offerte" par Travis est préconfigurée pour le language indiqué dans son fichier de configuration ('''.travis.yml'''), mais il est possible d'utiliser la commande '''sudo apt-get install ...''' pour ajouter vos dépendances.<br />
<br />
Pour utiliser Travis:<br />
<br />
# Créez compte individuel sur GitHub https://github.com<br />
# ''Fork''ez le projet TAGL '''cron4j''' depuis https://github.com/donsez/tagl<br />
# Ajoutez un collaborateur (i.e. votre binôme) au projet ''forké'', via les paramètres (''settings'') de ce projet<br />
# Pour l'exemple, activez le service (ou hook) ''Email'' depuis les paramètres du dépôt: à chaque fois que vous ou un de vos collaborateurs ferra un '''git push''', vous recevrez une notification par mail.<br />
# Activez le service Travis-CI: identifiez-vous (''sign in'') sur https://travis-ci.org/ avec votre compte GitHub<br />
# Activez le service pour les projets sur lesquels vous souhaitez appliquer les principes d'intégration continue<br />
<br />
Travis-CI utilise un fichier nommé '''.travis.yml''' (attention: fichier caché sous Unix) pour se configurer et choisir les opérations à effectuer.<br />
Ce fichier doit se trouver à la racine de votre dépôt Git.<br />
<br />
Faites un '''Commit''' puis un '''Push''' du fichier '''.travis.yml''' ci-dessous.<br />
<br />
<pre><br />
language: java<br />
<br />
jdk:<br />
- oraclejdk7<br />
- openjdk6<br />
- openjdk7<br />
<br />
script:<br />
- pushd cron4j-original && ant rel && popd<br />
</pre><br />
<br />
Ce fichier indique que le projet dans ce dépôt doit être testé sur 3 versions de Java (Oracle Java 7, Open JDK 6 et Open JDK 7), et que le script à exécuter pour lancer les tests est '''pushd cron4j-original && ant rel && popd'''.<br />
Travis-CI peut exécuter plusieurs commandes dans script, chacune d'entre elles devant démarrer par un '-' (élément dans une liste de 'scripts').<br />
<br />
Attention: il n'est pas possible d'utiliser '''cd''' pour changer de répertoire, il faut utiliser '''pushd''' (déplacement dans un dossier) et '''popd''' (retour au dossier précédent) à la place.<br />
<br />
Une fois ce fichier de configuration '''pushé''', Travis-CI se mettra en route dès le prochain '''push'''.<br />
<br />
===Maven===<br />
<br />
[http://maven.apache.org/download.cgi Charger et installer Maven 3].<br />
<br />
<pre><br />
mvn -version<br />
</pre><br />
<br />
Faites une copie du projet, basée sur Maven:<br />
<br />
# Dans votre dépôt Git, créez un dossier '''cron4j-mvn''': il contiendra le projet Cron4J avec la structure Maven<br />
# Dans ce dossier, utilisez l'[https://maven.apache.org/guides/introduction/introduction-to-archetypes.html archetype] Maven [http://maven.apache.org/archetype/maven-archetype-bundles/maven-archetype-quickstart/ maven-archetype-quickstart] (la version des sources de cron4j utilisés est la 2.5.5):<br />
#:<pre>mvn archetype:generate -DarchetypeGroupId=org.apache.maven.archetypes -DarchetypeArtifactId=maven-archetype-quickstart</pre><br />
# Cette commande crée un projet avec un fichier ''pom.xml'', et une classe et un test modèles: supprimez ces modèles<br />
# Copiez les sources de Cron4J depuis le dossier '''cron4j-original''' dans le dossier '''src/main/java''' de votre projet Maven<br />
# Faites un essai de compilation:<br />
#:<pre>mvn clean verify</pre><br />
# Enfin modifiez le fichier '''.travis.yml''' à la racine de votre dépôt Git afin que Travis exécute la commande '''mvn clean verify''' à chaque mise à jour du dépôt GitHub.<br />
<br />
===Tests Unitaires avec JUnit 4===<br />
Survoller le tutoriel [http://www.vogella.com/tutorials/JUnit/article.html Unit Testing with JUnit]<br />
<br />
# Ajouter le test unitaire suivant au projet, dans le fichier '''src/test/it/sauronsoftware/SchedulingPatternTest.java<br />
<pre><br />
package it.sauronsoftware;<br />
<br />
import it.sauronsoftware.cron4j.SchedulingPattern;<br />
import it.sauronsoftware.cron4j.InvalidPatternException;<br />
<br />
import static org.junit.Assert.assertEquals;<br />
import static org.junit.Assert.assertTrue;<br />
<br />
import org.junit.AfterClass;<br />
import org.junit.BeforeClass;<br />
import org.junit.Test;<br />
<br />
public class SchedulingPatternTest {<br />
<br />
@BeforeClass<br />
public static void testSetup() {<br />
}<br />
<br />
@AfterClass<br />
public static void testCleanup() {<br />
// Teardown for data used by the unit tests<br />
}<br />
<br />
@Test(expected = InvalidPatternException.class)<br />
public void testExceptionIsThrown() {<br />
SchedulingPattern sp = new SchedulingPattern("0 5 * *");<br />
}<br />
<br />
@Test<br />
public void testPattern() {<br />
String pattern;<br />
pattern="0 5 * * *|8 10 * * *|22 17 * * *";<br />
assertTrue(pattern + "is correct", SchedulingPattern.validate(pattern));<br />
pattern="0 5 * *";<br />
assertTrue(pattern + "is correct", SchedulingPattern.validate(pattern));<br />
}<br />
}<br />
</pre><br />
<br />
# Committez et Pushez ce nouveau fichier, pour que Travis lance les tests dès que possible<br />
# Lancez les tests unitaires avec <pre>mvn test</pre> Ce test va '''échouer''': corrigez le.<br />
# Committez et Pushez la version corrigée des tests: Travis enverra un mail pour indiquer si les tests échouent ou non<br />
#: '''Attention:''' Travis va exécuter les tests ''dès que possible''. Il est possible de recevoir un mail indiquant que les tests du premier ''push'' échouent alors que l'on a déjà ''pushé'' la correction.<br />
# Naviguez sur http://travis-ci.org pour vérifier les builds effectués.<br />
# Créez des tests unitaires supplémentaire du i.s.c.CronParser<br />
<br />
===Git (suite)===<br />
<br />
# Forkez le projet '''tagl''' d'un autre binome (i.e. autre que ''donsez/tagl'')<br />
#: '''Attention:''' donnez lui un nom différent (e.g. ''tagl-licensing'')<br />
# Clonez ce nouveau dépôt<br />
# Lancez une compilation pour valider l'état du projet (bonne pratique)<br />
#:<pre>mvn clean verify</pre><br />
# Ajoutez une bannière de licence dans le fichier '''cron4j-mvn/pom.xml'''<br />
# Lancez une nouvelle compilation pour valider vos modifications<br />
# Commitez et pushez (vers votre fork de ce dépôt, i.e. ''tagl-licensing'')<br />
# Via le site de GitHub, proposez un "Pull Request" au projet initial<br />
<br />
Vous pouvez ensuite supprimer le clone de ce fork.<br />
Lorsque le ''pull request'' aura été accepté, vous pourrez supprimer votre fork (''tagl-licensing'') de votre compte GitHub.<br />
<br />
===Contrôle Continu===<br />
<br />
Dans votre dépôt ''tagl''.<br />
<br />
# Ajoutez le plugin [http://mojo.codehaus.org/cobertura-maven-plugin/usage.html Cobertura] à votre projet Maven.<br />
## Configurez le plugin pour [http://mojo.codehaus.org/cobertura-maven-plugin/examples/report-formats.html générer un rapport] HTML. Le résultat se trouvera dans ''target/site/cobertura''<br />
## Le plugin ne s'exécute automatiquement pas durant la compilation, il faut utiliser la commande : <pre>mvn cobertura:cobertura</pre><br />
## '''Bonus:''' Modifiez le fichier ''pom.xml'' pour que le ''goal'' '''cobertura''' soit exécuté pendant la ''phase'' '''package'''.<br />
# Répondez aux questions : ''Mais qu'est ce que la couverture de code ? En quoi c'est utile ?''<br />
# Ajoutez au projet Maven les plugins pour la génération d'un site et de rapports (Javadoc, tests unitaires, tags list (FIXME, TODO, ...), ...): voir http://maven.apache.org/plugins/maven-site-plugin/ et d'autres.<br />
# Regardez les exemples d'utilisation de cron4j dans cron4j-original/examples<br />
<br />
===Bonus Track===<br />
<br />
====Clone SVN -> Git====<br />
<br />
Source: http://www.yterium.net/Migrer-un-projet-SVN-vers-GIT<br />
<br />
<syntaxhighlight lang="bash"><br />
# Cloner le dépôt SVN en dépôt Git (conservation historique)<br />
$ git svn clone svn://svn.code.sf.net/p/cron4j/code/trunk cron4j-original<br />
$ cd cron4j-original<br />
# Test compilation<br />
$ ant jar<br />
$ cd ..<br />
</syntaxhighlight><br />
<br />
====Préparation TAGL====<br />
<br />
<syntaxhighlight lang="bash"><br />
# Clone du dépôt TAGL<br />
$ git clone git@github.com:donsez/tagl.git<br />
$ cd tagl<br />
# "Fetch" du dépôt local cloné précédemment<br />
$ git fetch file://$(pwd)/../cron4j-original<br />
# Fusion de ce qui vient d'être fetché<br />
$ git merge FETCH_HEAD<br />
# Envoi sur le serveur<br />
$ git push<br />
</syntaxhighlight><br />
<br />
<br />
====Cherry-picking: reprise des modifications d'un collègue====<br />
<br />
On considère que:<br />
<br />
* votre dépôt Git distant est à l'adresse URL_DEPOT<br />
* votre collègue a un dépôt Git à l'adresse URL_COLLEGUE<br />
<br />
<br />
<syntaxhighlight lang="bash"><br />
# Dossier temporaire<br />
cd /tmp<br />
<br />
# Clone de votre dépôt<br />
git clone URL_DEPOT mon_depot<br />
<br />
# Déplacement dans votre dépôt<br />
cd mon_depot<br />
<br />
# Définition du dépôt distant<br />
git remote add collegue URL_COLLEGUE<br />
<br />
# Récupération des infos du dépôt du collègue<br />
git fetch collegue<br />
<br />
# Maintenant, on peut voir les branches du collègue<br />
git branch -a<br />
<br />
# On peut fusionner avec une branche<br />
git merge collegue/master<br />
<br />
# Si vous avez des conflits, éditez les fichiers concernés,<br />
# et committez avec git commit<br />
<br />
# Push vers votre dépôt distant<br />
git push origin<br />
<br />
# Optionnel: supprimez la référence vers le dépôt du collègue<br />
git remote rm collegue<br />
</syntaxhighlight><br />
<br />
<br />
====Archetype webapp====<br />
L'archetype webapp (http://maven.apache.org/archetype/maven-archetype-bundles/maven-archetype-webapp/) permet de créer le squelette d'une webapp. Créez un simple webapp monsite en version 0.1.0. (add/commit/push). Vous pourrez tester cette webapp en ajoutant au pom.xml le [https://wiki.eclipse.org/Jetty/Feature/Jetty_Maven_Plugin plugin maven Jetty].<br />
<br />
<syntaxhighlight lang="bash"><br />
mvn -Djetty.port=9999 jetty:run<br />
</syntaxhighlight><br />
<br />
Naviguez sur http://localhost:9999/monsite<br />
<br />
====Scrum tools====<br />
Ces 3 services peuvent être couplé à votre dépôt GitHub pour votre gestion de projet agile avec [[Scrum]] :<br />
* http://www.acunote.com/<br />
* http://backlogtool.com/<br />
* http://www.scrumdo.com/<br />
<br />
L'activation se fait via ''Settings > Webhooks & Services > Configure services''.<br />
<br />
==Séance 2==<br />
AOP & AspectJ<br />
<br />
Ajouter le [http://mojo.codehaus.org/aspectj-maven-plugin/ plugin Maven pour AspectJ] au pom.xml<br />
<br />
Ajouter un aspect de trace à l'invocation des méthodes run() de l'interface java.lang.Runnable (uniquement pour les objets ''schedulé''s).<br />
<br />
===Contrôle continu===<br />
Compléter l'aspect de trace avec le positionnement du [http://docs.oracle.com/javase/7/docs/api/java/lang/ThreadLocal.html java.lang.ThreadLocal] pour passer 1) l'identifiant du job et 2) le compteur des appels de la méthode de l'objet.<br />
<br />
==Séance 3==<br />
@WIP<br />
<br />
Injection de dépendances avec [[Guice]] <br />
<br />
<br />
==Séance 4==<br />
[[Tutorial OSGi avec Apache Felix]]<br />
<br />
<br />
<br />
==Séance 5==<br />
Faire un projet PDE pour un bundle cron4j.gogo (indépendant de cron4j.bundle)<br />
<br />
Utilisation de https://eclipse.org/tycho/</div>Calmanthttps://air.imag.fr/index.php?title=TAGL/TP&diff=15663TAGL/TP2014-02-20T15:36:25Z<p>Calmant: /* Contrôle Continu */</p>
<hr />
<div>Travaux pratiques de l'UE [[TAGL]].<br />
<br />
==Séance 1==<br />
===Git===<br />
<br />
Création d'un dépôt Git local<br />
<br />
====Méthode simple: init first====<br />
<br />
Via cette méthode, on crée un dépôt local, avec un répertoire de travail, puis on pousse ses modifications vers un dépôt "bare".<br />
Cette méthode est la plus simple, car on dispose immédiatement d'un répertoire de travail.<br />
<br />
<syntaxhighlight lang="bash"><br />
# Création d'un dépôt Git dans le dossier simple-repo<br />
git init simple-repo<br />
<br />
# Création d'un README<br />
cd simple-repo<br />
echo "Hello, World" > README<br />
<br />
# Ajout du versionnement du fichier README<br />
git add README<br />
<br />
# Commit<br />
git commit<br />
</syntaxhighlight><br />
<br />
À ce niveau, on a un dépôt Git complètement fonctionnel.<br />
Cependant, il est intéressant de pousser ses modifications vers un autre dépôt, sur une autre machine.<br />
On va donc créer un dépôt bare sur une autre machine (ou autre dossier pour l'exemple)<br />
<br />
<syntaxhighlight lang="bash"><br />
git init --bare server-repo<br />
</syntaxhighlight><br />
<br />
On considère que l'URL pour accéder à ce dépôt est URL_REPO.<br />
On va d'abord ajouter ce dépôt serveur à la liste des dépôts connu-repos de votre dépôt local.<br />
Étant donné qu'il s'agit du dépôt "principal" à utiliser, on l'appellera //origin//, par convention.<br />
<br />
<syntaxhighlight lang="bash"><br />
git remote add origin URL_REPO<br />
# Récupération de ses informations<br />
git fetch origin<br />
</syntaxhighlight><br />
<br />
Ce serveur distant est "vide": il n'a aucune branche. On va donc enregistrer notre branche sur le serveur<br />
<br />
<syntaxhighlight lang="bash"><br />
git push origin master<br />
</syntaxhighlight><br />
<br />
À partir de cette commande, la branche locale //master// sera liée à la branche distante //origin/master//.<br />
Lors des prochaines commandes ''git push'', grâce à cette liaison, tous les commits sur la branche locale //master// seront poussées sur le serveur distant.<br />
<br />
====Méthode moins simple: bare first====<br />
<br />
Si on commence dans par le serveur "vide", il faudra le cloner au lieu de le définir comme un dépôt distant.<br />
<br />
<syntaxhighlight lang="bash"><br />
# Création du dépôt vide<br />
git init --bare server-repo<br />
</syntaxhighlight><br />
<br />
On considère que ce dépôt est accessible à l'URL URL_REPO<br />
<br />
<syntaxhighlight lang="bash"><br />
# Clonage du dépôt<br />
git clone URL_REPO clone-repo<br />
</syntaxhighlight><br />
<br />
Un avertissement indique que l'on clone un dépôt vide: le dépôt local à donc une branche master, mais elle n'est pas liée au dépôt distant, car celui-ci n'a aucune branche.<br />
Le dépôt distant est automatiquement appelé //origin//.<br />
<br />
<syntaxhighlight lang="bash"><br />
# Commit dans le dépôt local<br />
cd clone-repo<br />
echo hello > readme.rst<br />
git add readme.rst<br />
git commit et ses dépendances<br />
</syntaxhighlight><br />
<br />
Comme dans la méthode simple, il faut pousser la branche master vers le dépôt distant:<br />
<br />
<syntaxhighlight lang="bash"><br />
git push origin master<br />
</syntaxhighlight><br />
<br />
===De l'importance des README===<br />
<br />
Il est très important d'avoir au moins 2 fichiers dans votre dépôt Git:<br />
<br />
* LICENSE: contenant le texte **complet** de la licence de votre projet<br />
* README: décrivant votre projet et comment l'utiliser. Ce fichier doit rappeler le nom de la licence de votre projet<br />
<br />
Il est aussi recommandé d'avoir les fichiers suivants:<br />
<br />
* AUTHORS: contenant la liste des noms/pseudos et e-mails des auteurs de commits ou de code inclus dans ce projet<br />
* INSTALL: contenant la liste des dépendances de ce projet et des commandes à utiliser pour le compiler et l'installer<br />
<br />
Les fichiers LICENSE sont des fichiers textes bruts.<br />
Les autres fichiers sont généralement dans un format offrant un peu plus de lisibilté, par exemple dans les formats [http://daringfireball.net/projects/markdown/ Markdown] (.md) ou [http://docutils.sourceforge.net/rst.html reStructuredText] (.rst)<br />
<br />
Un plug-in existe pour éditer des fichier reStructuredText dans Eclipse: ReST Editor, disponible sur le [https://marketplace.eclipse.org/content/rest-editor Marketplace Eclipse]<br />
<br />
===GitHub & Travis-CI===<br />
<br />
Travis-CI est un service permettant d'exécuter un script dans une machine virtuelle Ubuntu dès que vous effectuez un push sur un de vos dépôts GitHub.<br />
L'intérêt est de savoir si la version d'un projet que vous avez rendu publique peut être compilée et si ses tests passent.<br />
<br />
La machine virtuelle "offerte" par Travis est préconfigurée pour le language indiqué dans son fichier de configuration ('''.travis.yml'''), mais il est possible d'utiliser la commande '''sudo apt-get install ...''' pour ajouter vos dépendances.<br />
<br />
Pour utiliser Travis:<br />
<br />
# Créez compte individuel sur GitHub https://github.com<br />
# ''Fork''ez le projet TAGL '''cron4j''' depuis https://github.com/donsez/tagl<br />
# Ajoutez un collaborateur (i.e. votre binôme) au projet ''forké'', via les paramètres (''settings'') de ce projet<br />
# Pour l'exemple, activez le service (ou hook) ''Email'' depuis les paramètres du dépôt: à chaque fois que vous ou un de vos collaborateurs ferra un '''git push''', vous recevrez une notification par mail.<br />
# Activez le service Travis-CI: identifiez-vous (''sign in'') sur https://travis-ci.org/ avec votre compte GitHub<br />
# Activez le service pour les projets sur lesquels vous souhaitez appliquer les principes d'intégration continue<br />
<br />
Travis-CI utilise un fichier nommé '''.travis.yml''' (attention: fichier caché sous Unix) pour se configurer et choisir les opérations à effectuer.<br />
Ce fichier doit se trouver à la racine de votre dépôt Git.<br />
<br />
Faites un '''Commit''' puis un '''Push''' du fichier '''.travis.yml''' ci-dessous.<br />
<br />
<pre><br />
language: java<br />
<br />
jdk:<br />
- oraclejdk7<br />
- openjdk6<br />
- openjdk7<br />
<br />
script:<br />
- pushd cron4j-original && ant rel && popd<br />
</pre><br />
<br />
Ce fichier indique que le projet dans ce dépôt doit être testé sur 3 versions de Java (Oracle Java 7, Open JDK 6 et Open JDK 7), et que le script à exécuter pour lancer les tests est '''pushd cron4j-original && ant rel && popd'''.<br />
Travis-CI peut exécuter plusieurs commandes dans script, chacune d'entre elles devant démarrer par un '-' (élément dans une liste de 'scripts').<br />
<br />
Attention: il n'est pas possible d'utiliser '''cd''' pour changer de répertoire, il faut utiliser '''pushd''' (déplacement dans un dossier) et '''popd''' (retour au dossier précédent) à la place.<br />
<br />
Une fois ce fichier de configuration '''pushé''', Travis-CI se mettra en route dès le prochain '''push'''.<br />
<br />
===Maven===<br />
<br />
[http://maven.apache.org/download.cgi Charger et installer Maven 3].<br />
<br />
<pre><br />
mvn -version<br />
</pre><br />
<br />
Faites une copie du projet, basée sur Maven:<br />
<br />
# Dans votre dépôt Git, créez un dossier '''cron4j-mvn''': il contiendra le projet Cron4J avec la structure Maven<br />
# Dans ce dossier, utilisez l'[https://maven.apache.org/guides/introduction/introduction-to-archetypes.html archetype] Maven [http://maven.apache.org/archetype/maven-archetype-bundles/maven-archetype-quickstart/ maven-archetype-quickstart] (la version des sources de cron4j utilisés est la 2.5.5):<br />
#:<pre>mvn archetype:generate -DarchetypeGroupId=org.apache.maven.archetypes -DarchetypeArtifactId=maven-archetype-quickstart</pre><br />
# Cette commande crée un projet avec un fichier ''pom.xml'', et une classe et un test modèles: supprimez ces modèles<br />
# Copiez les sources de Cron4J depuis le dossier '''cron4j-original''' dans le dossier '''src/main/java''' de votre projet Maven<br />
# Faites un essai de compilation:<br />
#:<pre>mvn clean verify</pre><br />
# Enfin modifiez le fichier '''.travis.yml''' à la racine de votre dépôt Git afin que Travis exécute la commande '''mvn clean verify''' à chaque mise à jour du dépôt GitHub.<br />
<br />
===Tests Unitaires avec JUnit 4===<br />
Survoller le tutoriel [http://www.vogella.com/tutorials/JUnit/article.html Unit Testing with JUnit]<br />
<br />
# Ajouter le test unitaire suivant au projet, dans le fichier '''src/test/it/sauronsoftware/SchedulingPatternTest.java<br />
<pre><br />
package it.sauronsoftware;<br />
<br />
import it.sauronsoftware.cron4j.SchedulingPattern;<br />
import it.sauronsoftware.cron4j.InvalidPatternException;<br />
<br />
import static org.junit.Assert.assertEquals;<br />
import static org.junit.Assert.assertTrue;<br />
<br />
import org.junit.AfterClass;<br />
import org.junit.BeforeClass;<br />
import org.junit.Test;<br />
<br />
public class SchedulingPatternTest {<br />
<br />
@BeforeClass<br />
public static void testSetup() {<br />
}<br />
<br />
@AfterClass<br />
public static void testCleanup() {<br />
// Teardown for data used by the unit tests<br />
}<br />
<br />
@Test(expected = InvalidPatternException.class)<br />
public void testExceptionIsThrown() {<br />
SchedulingPattern sp = new SchedulingPattern("0 5 * *");<br />
}<br />
<br />
@Test<br />
public void testPattern() {<br />
String pattern;<br />
pattern="0 5 * * *|8 10 * * *|22 17 * * *";<br />
assertTrue(pattern + "is correct", SchedulingPattern.validate(pattern));<br />
pattern="0 5 * *";<br />
assertTrue(pattern + "is correct", SchedulingPattern.validate(pattern));<br />
}<br />
}<br />
</pre><br />
<br />
# Committez et Pushez ce nouveau fichier, pour que Travis lance les tests dès que possible<br />
# Lancez les tests unitaires avec <pre>mvn test</pre> Ce test va '''échouer''': corrigez le.<br />
# Committez et Pushez la version corrigée des tests: Travis enverra un mail pour indiquer si les tests échouent ou non<br />
#: '''Attention:''' Travis va exécuter les tests ''dès que possible''. Il est possible de recevoir un mail indiquant que les tests du premier ''push'' échouent alors que l'on a déjà ''pushé'' la correction.<br />
# Naviguez sur http://travis-ci.org pour vérifier les builds effectués.<br />
# Créez des tests unitaires supplémentaire du i.s.c.CronParser<br />
<br />
===Git (suite)===<br />
<br />
# Forkez le projet '''tagl''' d'un autre binome (i.e. autre que ''donsez/tagl'')<br />
#: '''Attention:''' donnez lui un nom différent (e.g. ''tagl-licensing'')<br />
# Clonez ce nouveau dépôt<br />
# Lancez une compilation pour valider l'état du projet (bonne pratique)<br />
#:<pre>mvn clean verify</pre><br />
# Ajoutez une bannière de licence dans le fichier '''cron4j-mvn/pom.xml'''<br />
# Lancez une nouvelle compilation pour valider vos modifications<br />
# Commitez et pushez (vers votre fork de ce dépôt, i.e. ''tagl-licensing'')<br />
# Via le site de GitHub, proposez un "Pull Request" au projet initial<br />
<br />
Vous pouvez ensuite supprimer le clone de ce fork.<br />
Lorsque le ''pull request'' aura été accepté, vous pourrez supprimer votre fork (''tagl-licensing'') de votre compte GitHub.<br />
<br />
===Contrôle Continu===<br />
<br />
Dans votre dépôt ''tagl''.<br />
<br />
# Ajoutez le plugin [http://mojo.codehaus.org/cobertura-maven-plugin/usage.html Cobertura] à votre projet Maven.<br />
# Répondez aux questions : ''Mais qu'est ce que la couverture de code ? En quoi c'est utile ?''<br />
# Ajoutez au projet Maven les plugins pour la génération d'un site et de rapports (Javadoc, tests unitaires, tags list (FIXME, TODO, ...), ...): voir http://maven.apache.org/plugins/maven-site-plugin/ et d'autres.<br />
# Regardez les exemples d'utilisation de cron4j dans cron4j-original/examples<br />
<br />
===Bonus Track===<br />
<br />
====Clone SVN -> Git====<br />
<br />
Source: http://www.yterium.net/Migrer-un-projet-SVN-vers-GIT<br />
<br />
<syntaxhighlight lang="bash"><br />
# Cloner le dépôt SVN en dépôt Git (conservation historique)<br />
$ git svn clone svn://svn.code.sf.net/p/cron4j/code/trunk cron4j-original<br />
$ cd cron4j-original<br />
# Test compilation<br />
$ ant jar<br />
$ cd ..<br />
</syntaxhighlight><br />
<br />
====Préparation TAGL====<br />
<br />
<syntaxhighlight lang="bash"><br />
# Clone du dépôt TAGL<br />
$ git clone git@github.com:donsez/tagl.git<br />
$ cd tagl<br />
# "Fetch" du dépôt local cloné précédemment<br />
$ git fetch file://$(pwd)/../cron4j-original<br />
# Fusion de ce qui vient d'être fetché<br />
$ git merge FETCH_HEAD<br />
# Envoi sur le serveur<br />
$ git push<br />
</syntaxhighlight><br />
<br />
<br />
====Cherry-picking: reprise des modifications d'un collègue====<br />
<br />
On considère que:<br />
<br />
* votre dépôt Git distant est à l'adresse URL_DEPOT<br />
* votre collègue a un dépôt Git à l'adresse URL_COLLEGUE<br />
<br />
<br />
<syntaxhighlight lang="bash"><br />
# Dossier temporaire<br />
cd /tmp<br />
<br />
# Clone de votre dépôt<br />
git clone URL_DEPOT mon_depot<br />
<br />
# Déplacement dans votre dépôt<br />
cd mon_depot<br />
<br />
# Définition du dépôt distant<br />
git remote add collegue URL_COLLEGUE<br />
<br />
# Récupération des infos du dépôt du collègue<br />
git fetch collegue<br />
<br />
# Maintenant, on peut voir les branches du collègue<br />
git branch -a<br />
<br />
# On peut fusionner avec une branche<br />
git merge collegue/master<br />
<br />
# Si vous avez des conflits, éditez les fichiers concernés,<br />
# et committez avec git commit<br />
<br />
# Push vers votre dépôt distant<br />
git push origin<br />
<br />
# Optionnel: supprimez la référence vers le dépôt du collègue<br />
git remote rm collegue<br />
</syntaxhighlight><br />
<br />
<br />
====Archetype webapp====<br />
L'archetype webapp (http://maven.apache.org/archetype/maven-archetype-bundles/maven-archetype-webapp/) permet de créer le squelette d'une webapp. Créez un simple webapp monsite en version 0.1.0. (add/commit/push). Vous pourrez tester cette webapp en ajoutant au pom.xml le [https://wiki.eclipse.org/Jetty/Feature/Jetty_Maven_Plugin plugin maven Jetty].<br />
<br />
<syntaxhighlight lang="bash"><br />
mvn -Djetty.port=9999 jetty:run<br />
</syntaxhighlight><br />
<br />
Naviguez sur http://localhost:9999/monsite<br />
<br />
====Scrum tools====<br />
Ces 3 services peuvent être couplé à votre dépôt GitHub pour votre gestion de projet agile avec [[Scrum]] :<br />
* http://www.acunote.com/<br />
* http://backlogtool.com/<br />
* http://www.scrumdo.com/<br />
<br />
L'activation se fait via ''Settings > Webhooks & Services > Configure services''.<br />
<br />
==Séance 2==<br />
AOP & AspectJ<br />
<br />
Ajouter le [http://mojo.codehaus.org/aspectj-maven-plugin/ plugin Maven pour AspectJ] au pom.xml<br />
<br />
Ajouter un aspect de trace à l'invocation des méthodes run() de l'interface java.lang.Runnable (uniquement pour les objets ''schedulé''s).<br />
<br />
===Contrôle continu===<br />
Compléter l'aspect de trace avec le positionnement du [http://docs.oracle.com/javase/7/docs/api/java/lang/ThreadLocal.html java.lang.ThreadLocal] pour passer 1) l'identifiant du job et 2) le compteur des appels de la méthode de l'objet.<br />
<br />
==Séance 3==<br />
@WIP<br />
<br />
Injection de dépendances avec [[Guice]] <br />
<br />
<br />
==Séance 4==<br />
[[Tutorial OSGi avec Apache Felix]]<br />
<br />
<br />
<br />
==Séance 5==<br />
Faire un projet PDE pour un bundle cron4j.gogo (indépendant de cron4j.bundle)<br />
<br />
Utilisation de https://eclipse.org/tycho/</div>Calmanthttps://air.imag.fr/index.php?title=TAGL/TP&diff=15662TAGL/TP2014-02-20T15:33:35Z<p>Calmant: /* Git (suite) */</p>
<hr />
<div>Travaux pratiques de l'UE [[TAGL]].<br />
<br />
==Séance 1==<br />
===Git===<br />
<br />
Création d'un dépôt Git local<br />
<br />
====Méthode simple: init first====<br />
<br />
Via cette méthode, on crée un dépôt local, avec un répertoire de travail, puis on pousse ses modifications vers un dépôt "bare".<br />
Cette méthode est la plus simple, car on dispose immédiatement d'un répertoire de travail.<br />
<br />
<syntaxhighlight lang="bash"><br />
# Création d'un dépôt Git dans le dossier simple-repo<br />
git init simple-repo<br />
<br />
# Création d'un README<br />
cd simple-repo<br />
echo "Hello, World" > README<br />
<br />
# Ajout du versionnement du fichier README<br />
git add README<br />
<br />
# Commit<br />
git commit<br />
</syntaxhighlight><br />
<br />
À ce niveau, on a un dépôt Git complètement fonctionnel.<br />
Cependant, il est intéressant de pousser ses modifications vers un autre dépôt, sur une autre machine.<br />
On va donc créer un dépôt bare sur une autre machine (ou autre dossier pour l'exemple)<br />
<br />
<syntaxhighlight lang="bash"><br />
git init --bare server-repo<br />
</syntaxhighlight><br />
<br />
On considère que l'URL pour accéder à ce dépôt est URL_REPO.<br />
On va d'abord ajouter ce dépôt serveur à la liste des dépôts connu-repos de votre dépôt local.<br />
Étant donné qu'il s'agit du dépôt "principal" à utiliser, on l'appellera //origin//, par convention.<br />
<br />
<syntaxhighlight lang="bash"><br />
git remote add origin URL_REPO<br />
# Récupération de ses informations<br />
git fetch origin<br />
</syntaxhighlight><br />
<br />
Ce serveur distant est "vide": il n'a aucune branche. On va donc enregistrer notre branche sur le serveur<br />
<br />
<syntaxhighlight lang="bash"><br />
git push origin master<br />
</syntaxhighlight><br />
<br />
À partir de cette commande, la branche locale //master// sera liée à la branche distante //origin/master//.<br />
Lors des prochaines commandes ''git push'', grâce à cette liaison, tous les commits sur la branche locale //master// seront poussées sur le serveur distant.<br />
<br />
====Méthode moins simple: bare first====<br />
<br />
Si on commence dans par le serveur "vide", il faudra le cloner au lieu de le définir comme un dépôt distant.<br />
<br />
<syntaxhighlight lang="bash"><br />
# Création du dépôt vide<br />
git init --bare server-repo<br />
</syntaxhighlight><br />
<br />
On considère que ce dépôt est accessible à l'URL URL_REPO<br />
<br />
<syntaxhighlight lang="bash"><br />
# Clonage du dépôt<br />
git clone URL_REPO clone-repo<br />
</syntaxhighlight><br />
<br />
Un avertissement indique que l'on clone un dépôt vide: le dépôt local à donc une branche master, mais elle n'est pas liée au dépôt distant, car celui-ci n'a aucune branche.<br />
Le dépôt distant est automatiquement appelé //origin//.<br />
<br />
<syntaxhighlight lang="bash"><br />
# Commit dans le dépôt local<br />
cd clone-repo<br />
echo hello > readme.rst<br />
git add readme.rst<br />
git commit et ses dépendances<br />
</syntaxhighlight><br />
<br />
Comme dans la méthode simple, il faut pousser la branche master vers le dépôt distant:<br />
<br />
<syntaxhighlight lang="bash"><br />
git push origin master<br />
</syntaxhighlight><br />
<br />
===De l'importance des README===<br />
<br />
Il est très important d'avoir au moins 2 fichiers dans votre dépôt Git:<br />
<br />
* LICENSE: contenant le texte **complet** de la licence de votre projet<br />
* README: décrivant votre projet et comment l'utiliser. Ce fichier doit rappeler le nom de la licence de votre projet<br />
<br />
Il est aussi recommandé d'avoir les fichiers suivants:<br />
<br />
* AUTHORS: contenant la liste des noms/pseudos et e-mails des auteurs de commits ou de code inclus dans ce projet<br />
* INSTALL: contenant la liste des dépendances de ce projet et des commandes à utiliser pour le compiler et l'installer<br />
<br />
Les fichiers LICENSE sont des fichiers textes bruts.<br />
Les autres fichiers sont généralement dans un format offrant un peu plus de lisibilté, par exemple dans les formats [http://daringfireball.net/projects/markdown/ Markdown] (.md) ou [http://docutils.sourceforge.net/rst.html reStructuredText] (.rst)<br />
<br />
Un plug-in existe pour éditer des fichier reStructuredText dans Eclipse: ReST Editor, disponible sur le [https://marketplace.eclipse.org/content/rest-editor Marketplace Eclipse]<br />
<br />
===GitHub & Travis-CI===<br />
<br />
Travis-CI est un service permettant d'exécuter un script dans une machine virtuelle Ubuntu dès que vous effectuez un push sur un de vos dépôts GitHub.<br />
L'intérêt est de savoir si la version d'un projet que vous avez rendu publique peut être compilée et si ses tests passent.<br />
<br />
La machine virtuelle "offerte" par Travis est préconfigurée pour le language indiqué dans son fichier de configuration ('''.travis.yml'''), mais il est possible d'utiliser la commande '''sudo apt-get install ...''' pour ajouter vos dépendances.<br />
<br />
Pour utiliser Travis:<br />
<br />
# Créez compte individuel sur GitHub https://github.com<br />
# ''Fork''ez le projet TAGL '''cron4j''' depuis https://github.com/donsez/tagl<br />
# Ajoutez un collaborateur (i.e. votre binôme) au projet ''forké'', via les paramètres (''settings'') de ce projet<br />
# Pour l'exemple, activez le service (ou hook) ''Email'' depuis les paramètres du dépôt: à chaque fois que vous ou un de vos collaborateurs ferra un '''git push''', vous recevrez une notification par mail.<br />
# Activez le service Travis-CI: identifiez-vous (''sign in'') sur https://travis-ci.org/ avec votre compte GitHub<br />
# Activez le service pour les projets sur lesquels vous souhaitez appliquer les principes d'intégration continue<br />
<br />
Travis-CI utilise un fichier nommé '''.travis.yml''' (attention: fichier caché sous Unix) pour se configurer et choisir les opérations à effectuer.<br />
Ce fichier doit se trouver à la racine de votre dépôt Git.<br />
<br />
Faites un '''Commit''' puis un '''Push''' du fichier '''.travis.yml''' ci-dessous.<br />
<br />
<pre><br />
language: java<br />
<br />
jdk:<br />
- oraclejdk7<br />
- openjdk6<br />
- openjdk7<br />
<br />
script:<br />
- pushd cron4j-original && ant rel && popd<br />
</pre><br />
<br />
Ce fichier indique que le projet dans ce dépôt doit être testé sur 3 versions de Java (Oracle Java 7, Open JDK 6 et Open JDK 7), et que le script à exécuter pour lancer les tests est '''pushd cron4j-original && ant rel && popd'''.<br />
Travis-CI peut exécuter plusieurs commandes dans script, chacune d'entre elles devant démarrer par un '-' (élément dans une liste de 'scripts').<br />
<br />
Attention: il n'est pas possible d'utiliser '''cd''' pour changer de répertoire, il faut utiliser '''pushd''' (déplacement dans un dossier) et '''popd''' (retour au dossier précédent) à la place.<br />
<br />
Une fois ce fichier de configuration '''pushé''', Travis-CI se mettra en route dès le prochain '''push'''.<br />
<br />
===Maven===<br />
<br />
[http://maven.apache.org/download.cgi Charger et installer Maven 3].<br />
<br />
<pre><br />
mvn -version<br />
</pre><br />
<br />
Faites une copie du projet, basée sur Maven:<br />
<br />
# Dans votre dépôt Git, créez un dossier '''cron4j-mvn''': il contiendra le projet Cron4J avec la structure Maven<br />
# Dans ce dossier, utilisez l'[https://maven.apache.org/guides/introduction/introduction-to-archetypes.html archetype] Maven [http://maven.apache.org/archetype/maven-archetype-bundles/maven-archetype-quickstart/ maven-archetype-quickstart] (la version des sources de cron4j utilisés est la 2.5.5):<br />
#:<pre>mvn archetype:generate -DarchetypeGroupId=org.apache.maven.archetypes -DarchetypeArtifactId=maven-archetype-quickstart</pre><br />
# Cette commande crée un projet avec un fichier ''pom.xml'', et une classe et un test modèles: supprimez ces modèles<br />
# Copiez les sources de Cron4J depuis le dossier '''cron4j-original''' dans le dossier '''src/main/java''' de votre projet Maven<br />
# Faites un essai de compilation:<br />
#:<pre>mvn clean verify</pre><br />
# Enfin modifiez le fichier '''.travis.yml''' à la racine de votre dépôt Git afin que Travis exécute la commande '''mvn clean verify''' à chaque mise à jour du dépôt GitHub.<br />
<br />
===Tests Unitaires avec JUnit 4===<br />
Survoller le tutoriel [http://www.vogella.com/tutorials/JUnit/article.html Unit Testing with JUnit]<br />
<br />
# Ajouter le test unitaire suivant au projet, dans le fichier '''src/test/it/sauronsoftware/SchedulingPatternTest.java<br />
<pre><br />
package it.sauronsoftware;<br />
<br />
import it.sauronsoftware.cron4j.SchedulingPattern;<br />
import it.sauronsoftware.cron4j.InvalidPatternException;<br />
<br />
import static org.junit.Assert.assertEquals;<br />
import static org.junit.Assert.assertTrue;<br />
<br />
import org.junit.AfterClass;<br />
import org.junit.BeforeClass;<br />
import org.junit.Test;<br />
<br />
public class SchedulingPatternTest {<br />
<br />
@BeforeClass<br />
public static void testSetup() {<br />
}<br />
<br />
@AfterClass<br />
public static void testCleanup() {<br />
// Teardown for data used by the unit tests<br />
}<br />
<br />
@Test(expected = InvalidPatternException.class)<br />
public void testExceptionIsThrown() {<br />
SchedulingPattern sp = new SchedulingPattern("0 5 * *");<br />
}<br />
<br />
@Test<br />
public void testPattern() {<br />
String pattern;<br />
pattern="0 5 * * *|8 10 * * *|22 17 * * *";<br />
assertTrue(pattern + "is correct", SchedulingPattern.validate(pattern));<br />
pattern="0 5 * *";<br />
assertTrue(pattern + "is correct", SchedulingPattern.validate(pattern));<br />
}<br />
}<br />
</pre><br />
<br />
# Committez et Pushez ce nouveau fichier, pour que Travis lance les tests dès que possible<br />
# Lancez les tests unitaires avec <pre>mvn test</pre> Ce test va '''échouer''': corrigez le.<br />
# Committez et Pushez la version corrigée des tests: Travis enverra un mail pour indiquer si les tests échouent ou non<br />
#: '''Attention:''' Travis va exécuter les tests ''dès que possible''. Il est possible de recevoir un mail indiquant que les tests du premier ''push'' échouent alors que l'on a déjà ''pushé'' la correction.<br />
# Naviguez sur http://travis-ci.org pour vérifier les builds effectués.<br />
# Créez des tests unitaires supplémentaire du i.s.c.CronParser<br />
<br />
===Git (suite)===<br />
<br />
# Forkez le projet '''tagl''' d'un autre binome (i.e. autre que ''donsez/tagl'')<br />
#: '''Attention:''' donnez lui un nom différent (e.g. ''tagl-licensing'')<br />
# Clonez ce nouveau dépôt<br />
# Lancez une compilation pour valider l'état du projet (bonne pratique)<br />
#:<pre>mvn clean verify</pre><br />
# Ajoutez une bannière de licence dans le fichier '''cron4j-mvn/pom.xml'''<br />
# Lancez une nouvelle compilation pour valider vos modifications<br />
# Commitez et pushez (vers votre fork de ce dépôt, i.e. ''tagl-licensing'')<br />
# Via le site de GitHub, proposez un "Pull Request" au projet initial<br />
<br />
Vous pouvez ensuite supprimer le clone de ce fork.<br />
Lorsque le ''pull request'' aura été accepté, vous pourrez supprimer votre fork (''tagl-licensing'') de votre compte GitHub.<br />
<br />
===Contrôle Continu===<br />
Ajoutez au pom.xml le plugin Covertura pour la couverture de code.<br />
<br />
Répondez aux questions : ''Mais qu'est ce que la couverture de code ? En quoi c'est utile ?''<br />
<br />
Ajoutez au pom.xml les plugins pour la gestion du site et des rapports (Javadoc, tests unitaires, tags list (FIXME, TODO, ...), ...): http://maven.apache.org/plugins/maven-site-plugin/ et d'autres.<br />
<br />
Pour la prochaine séance, regardez les exemples d'utilisation de cron4j dans cron4j-original/examples<br />
<br />
===Bonus Track===<br />
<br />
====Clone SVN -> Git====<br />
<br />
Source: http://www.yterium.net/Migrer-un-projet-SVN-vers-GIT<br />
<br />
<syntaxhighlight lang="bash"><br />
# Cloner le dépôt SVN en dépôt Git (conservation historique)<br />
$ git svn clone svn://svn.code.sf.net/p/cron4j/code/trunk cron4j-original<br />
$ cd cron4j-original<br />
# Test compilation<br />
$ ant jar<br />
$ cd ..<br />
</syntaxhighlight><br />
<br />
====Préparation TAGL====<br />
<br />
<syntaxhighlight lang="bash"><br />
# Clone du dépôt TAGL<br />
$ git clone git@github.com:donsez/tagl.git<br />
$ cd tagl<br />
# "Fetch" du dépôt local cloné précédemment<br />
$ git fetch file://$(pwd)/../cron4j-original<br />
# Fusion de ce qui vient d'être fetché<br />
$ git merge FETCH_HEAD<br />
# Envoi sur le serveur<br />
$ git push<br />
</syntaxhighlight><br />
<br />
<br />
====Cherry-picking: reprise des modifications d'un collègue====<br />
<br />
On considère que:<br />
<br />
* votre dépôt Git distant est à l'adresse URL_DEPOT<br />
* votre collègue a un dépôt Git à l'adresse URL_COLLEGUE<br />
<br />
<br />
<syntaxhighlight lang="bash"><br />
# Dossier temporaire<br />
cd /tmp<br />
<br />
# Clone de votre dépôt<br />
git clone URL_DEPOT mon_depot<br />
<br />
# Déplacement dans votre dépôt<br />
cd mon_depot<br />
<br />
# Définition du dépôt distant<br />
git remote add collegue URL_COLLEGUE<br />
<br />
# Récupération des infos du dépôt du collègue<br />
git fetch collegue<br />
<br />
# Maintenant, on peut voir les branches du collègue<br />
git branch -a<br />
<br />
# On peut fusionner avec une branche<br />
git merge collegue/master<br />
<br />
# Si vous avez des conflits, éditez les fichiers concernés,<br />
# et committez avec git commit<br />
<br />
# Push vers votre dépôt distant<br />
git push origin<br />
<br />
# Optionnel: supprimez la référence vers le dépôt du collègue<br />
git remote rm collegue<br />
</syntaxhighlight><br />
<br />
<br />
====Archetype webapp====<br />
L'archetype webapp (http://maven.apache.org/archetype/maven-archetype-bundles/maven-archetype-webapp/) permet de créer le squelette d'une webapp. Créez un simple webapp monsite en version 0.1.0. (add/commit/push). Vous pourrez tester cette webapp en ajoutant au pom.xml le [https://wiki.eclipse.org/Jetty/Feature/Jetty_Maven_Plugin plugin maven Jetty].<br />
<br />
<syntaxhighlight lang="bash"><br />
mvn -Djetty.port=9999 jetty:run<br />
</syntaxhighlight><br />
<br />
Naviguez sur http://localhost:9999/monsite<br />
<br />
====Scrum tools====<br />
Ces 3 services peuvent être couplé à votre dépôt GitHub pour votre gestion de projet agile avec [[Scrum]] :<br />
* http://www.acunote.com/<br />
* http://backlogtool.com/<br />
* http://www.scrumdo.com/<br />
<br />
L'activation se fait via ''Settings > Webhooks & Services > Configure services''.<br />
<br />
==Séance 2==<br />
AOP & AspectJ<br />
<br />
Ajouter le [http://mojo.codehaus.org/aspectj-maven-plugin/ plugin Maven pour AspectJ] au pom.xml<br />
<br />
Ajouter un aspect de trace à l'invocation des méthodes run() de l'interface java.lang.Runnable (uniquement pour les objets ''schedulé''s).<br />
<br />
===Contrôle continu===<br />
Compléter l'aspect de trace avec le positionnement du [http://docs.oracle.com/javase/7/docs/api/java/lang/ThreadLocal.html java.lang.ThreadLocal] pour passer 1) l'identifiant du job et 2) le compteur des appels de la méthode de l'objet.<br />
<br />
==Séance 3==<br />
@WIP<br />
<br />
Injection de dépendances avec [[Guice]] <br />
<br />
<br />
==Séance 4==<br />
[[Tutorial OSGi avec Apache Felix]]<br />
<br />
<br />
<br />
==Séance 5==<br />
Faire un projet PDE pour un bundle cron4j.gogo (indépendant de cron4j.bundle)<br />
<br />
Utilisation de https://eclipse.org/tycho/</div>Calmanthttps://air.imag.fr/index.php?title=TAGL/TP&diff=15661TAGL/TP2014-02-20T15:31:04Z<p>Calmant: /* Git (suite) */</p>
<hr />
<div>Travaux pratiques de l'UE [[TAGL]].<br />
<br />
==Séance 1==<br />
===Git===<br />
<br />
Création d'un dépôt Git local<br />
<br />
====Méthode simple: init first====<br />
<br />
Via cette méthode, on crée un dépôt local, avec un répertoire de travail, puis on pousse ses modifications vers un dépôt "bare".<br />
Cette méthode est la plus simple, car on dispose immédiatement d'un répertoire de travail.<br />
<br />
<syntaxhighlight lang="bash"><br />
# Création d'un dépôt Git dans le dossier simple-repo<br />
git init simple-repo<br />
<br />
# Création d'un README<br />
cd simple-repo<br />
echo "Hello, World" > README<br />
<br />
# Ajout du versionnement du fichier README<br />
git add README<br />
<br />
# Commit<br />
git commit<br />
</syntaxhighlight><br />
<br />
À ce niveau, on a un dépôt Git complètement fonctionnel.<br />
Cependant, il est intéressant de pousser ses modifications vers un autre dépôt, sur une autre machine.<br />
On va donc créer un dépôt bare sur une autre machine (ou autre dossier pour l'exemple)<br />
<br />
<syntaxhighlight lang="bash"><br />
git init --bare server-repo<br />
</syntaxhighlight><br />
<br />
On considère que l'URL pour accéder à ce dépôt est URL_REPO.<br />
On va d'abord ajouter ce dépôt serveur à la liste des dépôts connu-repos de votre dépôt local.<br />
Étant donné qu'il s'agit du dépôt "principal" à utiliser, on l'appellera //origin//, par convention.<br />
<br />
<syntaxhighlight lang="bash"><br />
git remote add origin URL_REPO<br />
# Récupération de ses informations<br />
git fetch origin<br />
</syntaxhighlight><br />
<br />
Ce serveur distant est "vide": il n'a aucune branche. On va donc enregistrer notre branche sur le serveur<br />
<br />
<syntaxhighlight lang="bash"><br />
git push origin master<br />
</syntaxhighlight><br />
<br />
À partir de cette commande, la branche locale //master// sera liée à la branche distante //origin/master//.<br />
Lors des prochaines commandes ''git push'', grâce à cette liaison, tous les commits sur la branche locale //master// seront poussées sur le serveur distant.<br />
<br />
====Méthode moins simple: bare first====<br />
<br />
Si on commence dans par le serveur "vide", il faudra le cloner au lieu de le définir comme un dépôt distant.<br />
<br />
<syntaxhighlight lang="bash"><br />
# Création du dépôt vide<br />
git init --bare server-repo<br />
</syntaxhighlight><br />
<br />
On considère que ce dépôt est accessible à l'URL URL_REPO<br />
<br />
<syntaxhighlight lang="bash"><br />
# Clonage du dépôt<br />
git clone URL_REPO clone-repo<br />
</syntaxhighlight><br />
<br />
Un avertissement indique que l'on clone un dépôt vide: le dépôt local à donc une branche master, mais elle n'est pas liée au dépôt distant, car celui-ci n'a aucune branche.<br />
Le dépôt distant est automatiquement appelé //origin//.<br />
<br />
<syntaxhighlight lang="bash"><br />
# Commit dans le dépôt local<br />
cd clone-repo<br />
echo hello > readme.rst<br />
git add readme.rst<br />
git commit et ses dépendances<br />
</syntaxhighlight><br />
<br />
Comme dans la méthode simple, il faut pousser la branche master vers le dépôt distant:<br />
<br />
<syntaxhighlight lang="bash"><br />
git push origin master<br />
</syntaxhighlight><br />
<br />
===De l'importance des README===<br />
<br />
Il est très important d'avoir au moins 2 fichiers dans votre dépôt Git:<br />
<br />
* LICENSE: contenant le texte **complet** de la licence de votre projet<br />
* README: décrivant votre projet et comment l'utiliser. Ce fichier doit rappeler le nom de la licence de votre projet<br />
<br />
Il est aussi recommandé d'avoir les fichiers suivants:<br />
<br />
* AUTHORS: contenant la liste des noms/pseudos et e-mails des auteurs de commits ou de code inclus dans ce projet<br />
* INSTALL: contenant la liste des dépendances de ce projet et des commandes à utiliser pour le compiler et l'installer<br />
<br />
Les fichiers LICENSE sont des fichiers textes bruts.<br />
Les autres fichiers sont généralement dans un format offrant un peu plus de lisibilté, par exemple dans les formats [http://daringfireball.net/projects/markdown/ Markdown] (.md) ou [http://docutils.sourceforge.net/rst.html reStructuredText] (.rst)<br />
<br />
Un plug-in existe pour éditer des fichier reStructuredText dans Eclipse: ReST Editor, disponible sur le [https://marketplace.eclipse.org/content/rest-editor Marketplace Eclipse]<br />
<br />
===GitHub & Travis-CI===<br />
<br />
Travis-CI est un service permettant d'exécuter un script dans une machine virtuelle Ubuntu dès que vous effectuez un push sur un de vos dépôts GitHub.<br />
L'intérêt est de savoir si la version d'un projet que vous avez rendu publique peut être compilée et si ses tests passent.<br />
<br />
La machine virtuelle "offerte" par Travis est préconfigurée pour le language indiqué dans son fichier de configuration ('''.travis.yml'''), mais il est possible d'utiliser la commande '''sudo apt-get install ...''' pour ajouter vos dépendances.<br />
<br />
Pour utiliser Travis:<br />
<br />
# Créez compte individuel sur GitHub https://github.com<br />
# ''Fork''ez le projet TAGL '''cron4j''' depuis https://github.com/donsez/tagl<br />
# Ajoutez un collaborateur (i.e. votre binôme) au projet ''forké'', via les paramètres (''settings'') de ce projet<br />
# Pour l'exemple, activez le service (ou hook) ''Email'' depuis les paramètres du dépôt: à chaque fois que vous ou un de vos collaborateurs ferra un '''git push''', vous recevrez une notification par mail.<br />
# Activez le service Travis-CI: identifiez-vous (''sign in'') sur https://travis-ci.org/ avec votre compte GitHub<br />
# Activez le service pour les projets sur lesquels vous souhaitez appliquer les principes d'intégration continue<br />
<br />
Travis-CI utilise un fichier nommé '''.travis.yml''' (attention: fichier caché sous Unix) pour se configurer et choisir les opérations à effectuer.<br />
Ce fichier doit se trouver à la racine de votre dépôt Git.<br />
<br />
Faites un '''Commit''' puis un '''Push''' du fichier '''.travis.yml''' ci-dessous.<br />
<br />
<pre><br />
language: java<br />
<br />
jdk:<br />
- oraclejdk7<br />
- openjdk6<br />
- openjdk7<br />
<br />
script:<br />
- pushd cron4j-original && ant rel && popd<br />
</pre><br />
<br />
Ce fichier indique que le projet dans ce dépôt doit être testé sur 3 versions de Java (Oracle Java 7, Open JDK 6 et Open JDK 7), et que le script à exécuter pour lancer les tests est '''pushd cron4j-original && ant rel && popd'''.<br />
Travis-CI peut exécuter plusieurs commandes dans script, chacune d'entre elles devant démarrer par un '-' (élément dans une liste de 'scripts').<br />
<br />
Attention: il n'est pas possible d'utiliser '''cd''' pour changer de répertoire, il faut utiliser '''pushd''' (déplacement dans un dossier) et '''popd''' (retour au dossier précédent) à la place.<br />
<br />
Une fois ce fichier de configuration '''pushé''', Travis-CI se mettra en route dès le prochain '''push'''.<br />
<br />
===Maven===<br />
<br />
[http://maven.apache.org/download.cgi Charger et installer Maven 3].<br />
<br />
<pre><br />
mvn -version<br />
</pre><br />
<br />
Faites une copie du projet, basée sur Maven:<br />
<br />
# Dans votre dépôt Git, créez un dossier '''cron4j-mvn''': il contiendra le projet Cron4J avec la structure Maven<br />
# Dans ce dossier, utilisez l'[https://maven.apache.org/guides/introduction/introduction-to-archetypes.html archetype] Maven [http://maven.apache.org/archetype/maven-archetype-bundles/maven-archetype-quickstart/ maven-archetype-quickstart] (la version des sources de cron4j utilisés est la 2.5.5):<br />
#:<pre>mvn archetype:generate -DarchetypeGroupId=org.apache.maven.archetypes -DarchetypeArtifactId=maven-archetype-quickstart</pre><br />
# Cette commande crée un projet avec un fichier ''pom.xml'', et une classe et un test modèles: supprimez ces modèles<br />
# Copiez les sources de Cron4J depuis le dossier '''cron4j-original''' dans le dossier '''src/main/java''' de votre projet Maven<br />
# Faites un essai de compilation:<br />
#:<pre>mvn clean verify</pre><br />
# Enfin modifiez le fichier '''.travis.yml''' à la racine de votre dépôt Git afin que Travis exécute la commande '''mvn clean verify''' à chaque mise à jour du dépôt GitHub.<br />
<br />
===Tests Unitaires avec JUnit 4===<br />
Survoller le tutoriel [http://www.vogella.com/tutorials/JUnit/article.html Unit Testing with JUnit]<br />
<br />
# Ajouter le test unitaire suivant au projet, dans le fichier '''src/test/it/sauronsoftware/SchedulingPatternTest.java<br />
<pre><br />
package it.sauronsoftware;<br />
<br />
import it.sauronsoftware.cron4j.SchedulingPattern;<br />
import it.sauronsoftware.cron4j.InvalidPatternException;<br />
<br />
import static org.junit.Assert.assertEquals;<br />
import static org.junit.Assert.assertTrue;<br />
<br />
import org.junit.AfterClass;<br />
import org.junit.BeforeClass;<br />
import org.junit.Test;<br />
<br />
public class SchedulingPatternTest {<br />
<br />
@BeforeClass<br />
public static void testSetup() {<br />
}<br />
<br />
@AfterClass<br />
public static void testCleanup() {<br />
// Teardown for data used by the unit tests<br />
}<br />
<br />
@Test(expected = InvalidPatternException.class)<br />
public void testExceptionIsThrown() {<br />
SchedulingPattern sp = new SchedulingPattern("0 5 * *");<br />
}<br />
<br />
@Test<br />
public void testPattern() {<br />
String pattern;<br />
pattern="0 5 * * *|8 10 * * *|22 17 * * *";<br />
assertTrue(pattern + "is correct", SchedulingPattern.validate(pattern));<br />
pattern="0 5 * *";<br />
assertTrue(pattern + "is correct", SchedulingPattern.validate(pattern));<br />
}<br />
}<br />
</pre><br />
<br />
# Committez et Pushez ce nouveau fichier, pour que Travis lance les tests dès que possible<br />
# Lancez les tests unitaires avec <pre>mvn test</pre> Ce test va '''échouer''': corrigez le.<br />
# Committez et Pushez la version corrigée des tests: Travis enverra un mail pour indiquer si les tests échouent ou non<br />
#: '''Attention:''' Travis va exécuter les tests ''dès que possible''. Il est possible de recevoir un mail indiquant que les tests du premier ''push'' échouent alors que l'on a déjà ''pushé'' la correction.<br />
# Naviguez sur http://travis-ci.org pour vérifier les builds effectués.<br />
# Créez des tests unitaires supplémentaire du i.s.c.CronParser<br />
<br />
===Git (suite)===<br />
<br />
# Forkez le projet '''tagl''' d'un autre binome (i.e. autre que donsez/tagl)<br />
#: '''Attention:''' donnez lui un nom différent (e.g. tagl-licensing)<br />
# Clonez ce nouveau dépôt<br />
# Lancez une compilation pour valider l'état du projet (bonne pratique)<br />
#:<pre>mvn clean verify</pre><br />
# Ajoutez une bannière de licence dans le fichier '''cron4j-mvn/pom.xml'''<br />
# Lancez une nouvelle compilation pour valider vos modifications<br />
# Commitez et pushez (vers votre fork de ce dépôt, i.e. tagl-licensing)<br />
# Via le site de GitHub, proposez un "Pull Request" au projet initial<br />
<br />
===Contrôle Continu===<br />
Ajoutez au pom.xml le plugin Covertura pour la couverture de code.<br />
<br />
Répondez aux questions : ''Mais qu'est ce que la couverture de code ? En quoi c'est utile ?''<br />
<br />
Ajoutez au pom.xml les plugins pour la gestion du site et des rapports (Javadoc, tests unitaires, tags list (FIXME, TODO, ...), ...): http://maven.apache.org/plugins/maven-site-plugin/ et d'autres.<br />
<br />
Pour la prochaine séance, regardez les exemples d'utilisation de cron4j dans cron4j-original/examples<br />
<br />
===Bonus Track===<br />
<br />
====Clone SVN -> Git====<br />
<br />
Source: http://www.yterium.net/Migrer-un-projet-SVN-vers-GIT<br />
<br />
<syntaxhighlight lang="bash"><br />
# Cloner le dépôt SVN en dépôt Git (conservation historique)<br />
$ git svn clone svn://svn.code.sf.net/p/cron4j/code/trunk cron4j-original<br />
$ cd cron4j-original<br />
# Test compilation<br />
$ ant jar<br />
$ cd ..<br />
</syntaxhighlight><br />
<br />
====Préparation TAGL====<br />
<br />
<syntaxhighlight lang="bash"><br />
# Clone du dépôt TAGL<br />
$ git clone git@github.com:donsez/tagl.git<br />
$ cd tagl<br />
# "Fetch" du dépôt local cloné précédemment<br />
$ git fetch file://$(pwd)/../cron4j-original<br />
# Fusion de ce qui vient d'être fetché<br />
$ git merge FETCH_HEAD<br />
# Envoi sur le serveur<br />
$ git push<br />
</syntaxhighlight><br />
<br />
<br />
====Cherry-picking: reprise des modifications d'un collègue====<br />
<br />
On considère que:<br />
<br />
* votre dépôt Git distant est à l'adresse URL_DEPOT<br />
* votre collègue a un dépôt Git à l'adresse URL_COLLEGUE<br />
<br />
<br />
<syntaxhighlight lang="bash"><br />
# Dossier temporaire<br />
cd /tmp<br />
<br />
# Clone de votre dépôt<br />
git clone URL_DEPOT mon_depot<br />
<br />
# Déplacement dans votre dépôt<br />
cd mon_depot<br />
<br />
# Définition du dépôt distant<br />
git remote add collegue URL_COLLEGUE<br />
<br />
# Récupération des infos du dépôt du collègue<br />
git fetch collegue<br />
<br />
# Maintenant, on peut voir les branches du collègue<br />
git branch -a<br />
<br />
# On peut fusionner avec une branche<br />
git merge collegue/master<br />
<br />
# Si vous avez des conflits, éditez les fichiers concernés,<br />
# et committez avec git commit<br />
<br />
# Push vers votre dépôt distant<br />
git push origin<br />
<br />
# Optionnel: supprimez la référence vers le dépôt du collègue<br />
git remote rm collegue<br />
</syntaxhighlight><br />
<br />
<br />
====Archetype webapp====<br />
L'archetype webapp (http://maven.apache.org/archetype/maven-archetype-bundles/maven-archetype-webapp/) permet de créer le squelette d'une webapp. Créez un simple webapp monsite en version 0.1.0. (add/commit/push). Vous pourrez tester cette webapp en ajoutant au pom.xml le [https://wiki.eclipse.org/Jetty/Feature/Jetty_Maven_Plugin plugin maven Jetty].<br />
<br />
<syntaxhighlight lang="bash"><br />
mvn -Djetty.port=9999 jetty:run<br />
</syntaxhighlight><br />
<br />
Naviguez sur http://localhost:9999/monsite<br />
<br />
====Scrum tools====<br />
Ces 3 services peuvent être couplé à votre dépôt GitHub pour votre gestion de projet agile avec [[Scrum]] :<br />
* http://www.acunote.com/<br />
* http://backlogtool.com/<br />
* http://www.scrumdo.com/<br />
<br />
L'activation se fait via ''Settings > Webhooks & Services > Configure services''.<br />
<br />
==Séance 2==<br />
AOP & AspectJ<br />
<br />
Ajouter le [http://mojo.codehaus.org/aspectj-maven-plugin/ plugin Maven pour AspectJ] au pom.xml<br />
<br />
Ajouter un aspect de trace à l'invocation des méthodes run() de l'interface java.lang.Runnable (uniquement pour les objets ''schedulé''s).<br />
<br />
===Contrôle continu===<br />
Compléter l'aspect de trace avec le positionnement du [http://docs.oracle.com/javase/7/docs/api/java/lang/ThreadLocal.html java.lang.ThreadLocal] pour passer 1) l'identifiant du job et 2) le compteur des appels de la méthode de l'objet.<br />
<br />
==Séance 3==<br />
@WIP<br />
<br />
Injection de dépendances avec [[Guice]] <br />
<br />
<br />
==Séance 4==<br />
[[Tutorial OSGi avec Apache Felix]]<br />
<br />
<br />
<br />
==Séance 5==<br />
Faire un projet PDE pour un bundle cron4j.gogo (indépendant de cron4j.bundle)<br />
<br />
Utilisation de https://eclipse.org/tycho/</div>Calmanthttps://air.imag.fr/index.php?title=TAGL/TP&diff=15660TAGL/TP2014-02-20T15:07:47Z<p>Calmant: /* Tests Unitaires avec JUnit 4 */</p>
<hr />
<div>Travaux pratiques de l'UE [[TAGL]].<br />
<br />
==Séance 1==<br />
===Git===<br />
<br />
Création d'un dépôt Git local<br />
<br />
====Méthode simple: init first====<br />
<br />
Via cette méthode, on crée un dépôt local, avec un répertoire de travail, puis on pousse ses modifications vers un dépôt "bare".<br />
Cette méthode est la plus simple, car on dispose immédiatement d'un répertoire de travail.<br />
<br />
<syntaxhighlight lang="bash"><br />
# Création d'un dépôt Git dans le dossier simple-repo<br />
git init simple-repo<br />
<br />
# Création d'un README<br />
cd simple-repo<br />
echo "Hello, World" > README<br />
<br />
# Ajout du versionnement du fichier README<br />
git add README<br />
<br />
# Commit<br />
git commit<br />
</syntaxhighlight><br />
<br />
À ce niveau, on a un dépôt Git complètement fonctionnel.<br />
Cependant, il est intéressant de pousser ses modifications vers un autre dépôt, sur une autre machine.<br />
On va donc créer un dépôt bare sur une autre machine (ou autre dossier pour l'exemple)<br />
<br />
<syntaxhighlight lang="bash"><br />
git init --bare server-repo<br />
</syntaxhighlight><br />
<br />
On considère que l'URL pour accéder à ce dépôt est URL_REPO.<br />
On va d'abord ajouter ce dépôt serveur à la liste des dépôts connu-repos de votre dépôt local.<br />
Étant donné qu'il s'agit du dépôt "principal" à utiliser, on l'appellera //origin//, par convention.<br />
<br />
<syntaxhighlight lang="bash"><br />
git remote add origin URL_REPO<br />
# Récupération de ses informations<br />
git fetch origin<br />
</syntaxhighlight><br />
<br />
Ce serveur distant est "vide": il n'a aucune branche. On va donc enregistrer notre branche sur le serveur<br />
<br />
<syntaxhighlight lang="bash"><br />
git push origin master<br />
</syntaxhighlight><br />
<br />
À partir de cette commande, la branche locale //master// sera liée à la branche distante //origin/master//.<br />
Lors des prochaines commandes ''git push'', grâce à cette liaison, tous les commits sur la branche locale //master// seront poussées sur le serveur distant.<br />
<br />
====Méthode moins simple: bare first====<br />
<br />
Si on commence dans par le serveur "vide", il faudra le cloner au lieu de le définir comme un dépôt distant.<br />
<br />
<syntaxhighlight lang="bash"><br />
# Création du dépôt vide<br />
git init --bare server-repo<br />
</syntaxhighlight><br />
<br />
On considère que ce dépôt est accessible à l'URL URL_REPO<br />
<br />
<syntaxhighlight lang="bash"><br />
# Clonage du dépôt<br />
git clone URL_REPO clone-repo<br />
</syntaxhighlight><br />
<br />
Un avertissement indique que l'on clone un dépôt vide: le dépôt local à donc une branche master, mais elle n'est pas liée au dépôt distant, car celui-ci n'a aucune branche.<br />
Le dépôt distant est automatiquement appelé //origin//.<br />
<br />
<syntaxhighlight lang="bash"><br />
# Commit dans le dépôt local<br />
cd clone-repo<br />
echo hello > readme.rst<br />
git add readme.rst<br />
git commit et ses dépendances<br />
</syntaxhighlight><br />
<br />
Comme dans la méthode simple, il faut pousser la branche master vers le dépôt distant:<br />
<br />
<syntaxhighlight lang="bash"><br />
git push origin master<br />
</syntaxhighlight><br />
<br />
===De l'importance des README===<br />
<br />
Il est très important d'avoir au moins 2 fichiers dans votre dépôt Git:<br />
<br />
* LICENSE: contenant le texte **complet** de la licence de votre projet<br />
* README: décrivant votre projet et comment l'utiliser. Ce fichier doit rappeler le nom de la licence de votre projet<br />
<br />
Il est aussi recommandé d'avoir les fichiers suivants:<br />
<br />
* AUTHORS: contenant la liste des noms/pseudos et e-mails des auteurs de commits ou de code inclus dans ce projet<br />
* INSTALL: contenant la liste des dépendances de ce projet et des commandes à utiliser pour le compiler et l'installer<br />
<br />
Les fichiers LICENSE sont des fichiers textes bruts.<br />
Les autres fichiers sont généralement dans un format offrant un peu plus de lisibilté, par exemple dans les formats [http://daringfireball.net/projects/markdown/ Markdown] (.md) ou [http://docutils.sourceforge.net/rst.html reStructuredText] (.rst)<br />
<br />
Un plug-in existe pour éditer des fichier reStructuredText dans Eclipse: ReST Editor, disponible sur le [https://marketplace.eclipse.org/content/rest-editor Marketplace Eclipse]<br />
<br />
===GitHub & Travis-CI===<br />
<br />
Travis-CI est un service permettant d'exécuter un script dans une machine virtuelle Ubuntu dès que vous effectuez un push sur un de vos dépôts GitHub.<br />
L'intérêt est de savoir si la version d'un projet que vous avez rendu publique peut être compilée et si ses tests passent.<br />
<br />
La machine virtuelle "offerte" par Travis est préconfigurée pour le language indiqué dans son fichier de configuration ('''.travis.yml'''), mais il est possible d'utiliser la commande '''sudo apt-get install ...''' pour ajouter vos dépendances.<br />
<br />
Pour utiliser Travis:<br />
<br />
# Créez compte individuel sur GitHub https://github.com<br />
# ''Fork''ez le projet TAGL '''cron4j''' depuis https://github.com/donsez/tagl<br />
# Ajoutez un collaborateur (i.e. votre binôme) au projet ''forké'', via les paramètres (''settings'') de ce projet<br />
# Pour l'exemple, activez le service (ou hook) ''Email'' depuis les paramètres du dépôt: à chaque fois que vous ou un de vos collaborateurs ferra un '''git push''', vous recevrez une notification par mail.<br />
# Activez le service Travis-CI: identifiez-vous (''sign in'') sur https://travis-ci.org/ avec votre compte GitHub<br />
# Activez le service pour les projets sur lesquels vous souhaitez appliquer les principes d'intégration continue<br />
<br />
Travis-CI utilise un fichier nommé '''.travis.yml''' (attention: fichier caché sous Unix) pour se configurer et choisir les opérations à effectuer.<br />
Ce fichier doit se trouver à la racine de votre dépôt Git.<br />
<br />
Faites un '''Commit''' puis un '''Push''' du fichier '''.travis.yml''' ci-dessous.<br />
<br />
<pre><br />
language: java<br />
<br />
jdk:<br />
- oraclejdk7<br />
- openjdk6<br />
- openjdk7<br />
<br />
script:<br />
- pushd cron4j-original && ant rel && popd<br />
</pre><br />
<br />
Ce fichier indique que le projet dans ce dépôt doit être testé sur 3 versions de Java (Oracle Java 7, Open JDK 6 et Open JDK 7), et que le script à exécuter pour lancer les tests est '''pushd cron4j-original && ant rel && popd'''.<br />
Travis-CI peut exécuter plusieurs commandes dans script, chacune d'entre elles devant démarrer par un '-' (élément dans une liste de 'scripts').<br />
<br />
Attention: il n'est pas possible d'utiliser '''cd''' pour changer de répertoire, il faut utiliser '''pushd''' (déplacement dans un dossier) et '''popd''' (retour au dossier précédent) à la place.<br />
<br />
Une fois ce fichier de configuration '''pushé''', Travis-CI se mettra en route dès le prochain '''push'''.<br />
<br />
===Maven===<br />
<br />
[http://maven.apache.org/download.cgi Charger et installer Maven 3].<br />
<br />
<pre><br />
mvn -version<br />
</pre><br />
<br />
Faites une copie du projet, basée sur Maven:<br />
<br />
# Dans votre dépôt Git, créez un dossier '''cron4j-mvn''': il contiendra le projet Cron4J avec la structure Maven<br />
# Dans ce dossier, utilisez l'[https://maven.apache.org/guides/introduction/introduction-to-archetypes.html archetype] Maven [http://maven.apache.org/archetype/maven-archetype-bundles/maven-archetype-quickstart/ maven-archetype-quickstart] (la version des sources de cron4j utilisés est la 2.5.5):<br />
#:<pre>mvn archetype:generate -DarchetypeGroupId=org.apache.maven.archetypes -DarchetypeArtifactId=maven-archetype-quickstart</pre><br />
# Cette commande crée un projet avec un fichier ''pom.xml'', et une classe et un test modèles: supprimez ces modèles<br />
# Copiez les sources de Cron4J depuis le dossier '''cron4j-original''' dans le dossier '''src/main/java''' de votre projet Maven<br />
# Faites un essai de compilation:<br />
#:<pre>mvn clean verify</pre><br />
# Enfin modifiez le fichier '''.travis.yml''' à la racine de votre dépôt Git afin que Travis exécute la commande '''mvn clean verify''' à chaque mise à jour du dépôt GitHub.<br />
<br />
===Tests Unitaires avec JUnit 4===<br />
Survoller le tutoriel [http://www.vogella.com/tutorials/JUnit/article.html Unit Testing with JUnit]<br />
<br />
# Ajouter le test unitaire suivant au projet, dans le fichier '''src/test/it/sauronsoftware/SchedulingPatternTest.java<br />
<pre><br />
package it.sauronsoftware;<br />
<br />
import it.sauronsoftware.cron4j.SchedulingPattern;<br />
import it.sauronsoftware.cron4j.InvalidPatternException;<br />
<br />
import static org.junit.Assert.assertEquals;<br />
import static org.junit.Assert.assertTrue;<br />
<br />
import org.junit.AfterClass;<br />
import org.junit.BeforeClass;<br />
import org.junit.Test;<br />
<br />
public class SchedulingPatternTest {<br />
<br />
@BeforeClass<br />
public static void testSetup() {<br />
}<br />
<br />
@AfterClass<br />
public static void testCleanup() {<br />
// Teardown for data used by the unit tests<br />
}<br />
<br />
@Test(expected = InvalidPatternException.class)<br />
public void testExceptionIsThrown() {<br />
SchedulingPattern sp = new SchedulingPattern("0 5 * *");<br />
}<br />
<br />
@Test<br />
public void testPattern() {<br />
String pattern;<br />
pattern="0 5 * * *|8 10 * * *|22 17 * * *";<br />
assertTrue(pattern + "is correct", SchedulingPattern.validate(pattern));<br />
pattern="0 5 * *";<br />
assertTrue(pattern + "is correct", SchedulingPattern.validate(pattern));<br />
}<br />
}<br />
</pre><br />
<br />
# Committez et Pushez ce nouveau fichier, pour que Travis lance les tests dès que possible<br />
# Lancez les tests unitaires avec <pre>mvn test</pre> Ce test va '''échouer''': corrigez le.<br />
# Committez et Pushez la version corrigée des tests: Travis enverra un mail pour indiquer si les tests échouent ou non<br />
#: '''Attention:''' Travis va exécuter les tests ''dès que possible''. Il est possible de recevoir un mail indiquant que les tests du premier ''push'' échouent alors que l'on a déjà ''pushé'' la correction.<br />
# Naviguez sur http://travis-ci.org pour vérifier les builds effectués.<br />
# Créez des tests unitaires supplémentaire du i.s.c.CronParser<br />
<br />
===Git (suite)===<br />
# Forker le projet '''cron4j-mvn''' d'un autre binome (ie l'origine)<br />
# Ajouter une bannière de licence dans le pom.xml<br />
# Lancer mvn clean install (bonne pratique)<br />
# Commiter<br />
# Faire un Push request vers l'origine<br />
<br />
===Contrôle Continu===<br />
Ajoutez au pom.xml le plugin Covertura pour la couverture de code.<br />
<br />
Répondez aux questions : ''Mais qu'est ce que la couverture de code ? En quoi c'est utile ?''<br />
<br />
Ajoutez au pom.xml les plugins pour la gestion du site et des rapports (Javadoc, tests unitaires, tags list (FIXME, TODO, ...), ...): http://maven.apache.org/plugins/maven-site-plugin/ et d'autres.<br />
<br />
Pour la prochaine séance, regardez les exemples d'utilisation de cron4j dans cron4j-original/examples<br />
<br />
===Bonus Track===<br />
<br />
====Clone SVN -> Git====<br />
<br />
Source: http://www.yterium.net/Migrer-un-projet-SVN-vers-GIT<br />
<br />
<syntaxhighlight lang="bash"><br />
# Cloner le dépôt SVN en dépôt Git (conservation historique)<br />
$ git svn clone svn://svn.code.sf.net/p/cron4j/code/trunk cron4j-original<br />
$ cd cron4j-original<br />
# Test compilation<br />
$ ant jar<br />
$ cd ..<br />
</syntaxhighlight><br />
<br />
====Préparation TAGL====<br />
<br />
<syntaxhighlight lang="bash"><br />
# Clone du dépôt TAGL<br />
$ git clone git@github.com:donsez/tagl.git<br />
$ cd tagl<br />
# "Fetch" du dépôt local cloné précédemment<br />
$ git fetch file://$(pwd)/../cron4j-original<br />
# Fusion de ce qui vient d'être fetché<br />
$ git merge FETCH_HEAD<br />
# Envoi sur le serveur<br />
$ git push<br />
</syntaxhighlight><br />
<br />
<br />
====Cherry-picking: reprise des modifications d'un collègue====<br />
<br />
On considère que:<br />
<br />
* votre dépôt Git distant est à l'adresse URL_DEPOT<br />
* votre collègue a un dépôt Git à l'adresse URL_COLLEGUE<br />
<br />
<br />
<syntaxhighlight lang="bash"><br />
# Dossier temporaire<br />
cd /tmp<br />
<br />
# Clone de votre dépôt<br />
git clone URL_DEPOT mon_depot<br />
<br />
# Déplacement dans votre dépôt<br />
cd mon_depot<br />
<br />
# Définition du dépôt distant<br />
git remote add collegue URL_COLLEGUE<br />
<br />
# Récupération des infos du dépôt du collègue<br />
git fetch collegue<br />
<br />
# Maintenant, on peut voir les branches du collègue<br />
git branch -a<br />
<br />
# On peut fusionner avec une branche<br />
git merge collegue/master<br />
<br />
# Si vous avez des conflits, éditez les fichiers concernés,<br />
# et committez avec git commit<br />
<br />
# Push vers votre dépôt distant<br />
git push origin<br />
<br />
# Optionnel: supprimez la référence vers le dépôt du collègue<br />
git remote rm collegue<br />
</syntaxhighlight><br />
<br />
<br />
====Archetype webapp====<br />
L'archetype webapp (http://maven.apache.org/archetype/maven-archetype-bundles/maven-archetype-webapp/) permet de créer le squelette d'une webapp. Créez un simple webapp monsite en version 0.1.0. (add/commit/push). Vous pourrez tester cette webapp en ajoutant au pom.xml le [https://wiki.eclipse.org/Jetty/Feature/Jetty_Maven_Plugin plugin maven Jetty].<br />
<br />
<syntaxhighlight lang="bash"><br />
mvn -Djetty.port=9999 jetty:run<br />
</syntaxhighlight><br />
<br />
Naviguez sur http://localhost:9999/monsite<br />
<br />
====Scrum tools====<br />
Ces 3 services peuvent être couplé à votre dépôt GitHub pour votre gestion de projet agile avec [[Scrum]] :<br />
* http://www.acunote.com/<br />
* http://backlogtool.com/<br />
* http://www.scrumdo.com/<br />
<br />
L'activation se fait via ''Settings > Webhooks & Services > Configure services''.<br />
<br />
==Séance 2==<br />
AOP & AspectJ<br />
<br />
Ajouter le [http://mojo.codehaus.org/aspectj-maven-plugin/ plugin Maven pour AspectJ] au pom.xml<br />
<br />
Ajouter un aspect de trace à l'invocation des méthodes run() de l'interface java.lang.Runnable (uniquement pour les objets ''schedulé''s).<br />
<br />
===Contrôle continu===<br />
Compléter l'aspect de trace avec le positionnement du [http://docs.oracle.com/javase/7/docs/api/java/lang/ThreadLocal.html java.lang.ThreadLocal] pour passer 1) l'identifiant du job et 2) le compteur des appels de la méthode de l'objet.<br />
<br />
==Séance 3==<br />
@WIP<br />
<br />
Injection de dépendances avec [[Guice]] <br />
<br />
<br />
==Séance 4==<br />
[[Tutorial OSGi avec Apache Felix]]<br />
<br />
<br />
<br />
==Séance 5==<br />
Faire un projet PDE pour un bundle cron4j.gogo (indépendant de cron4j.bundle)<br />
<br />
Utilisation de https://eclipse.org/tycho/</div>Calmanthttps://air.imag.fr/index.php?title=TAGL/TP&diff=15657TAGL/TP2014-02-20T14:47:47Z<p>Calmant: /* Maven */</p>
<hr />
<div>Travaux pratiques de l'UE [[TAGL]].<br />
<br />
==Séance 1==<br />
===Git===<br />
<br />
Création d'un dépôt Git local<br />
<br />
====Méthode simple: init first====<br />
<br />
Via cette méthode, on crée un dépôt local, avec un répertoire de travail, puis on pousse ses modifications vers un dépôt "bare".<br />
Cette méthode est la plus simple, car on dispose immédiatement d'un répertoire de travail.<br />
<br />
<syntaxhighlight lang="bash"><br />
# Création d'un dépôt Git dans le dossier simple-repo<br />
git init simple-repo<br />
<br />
# Création d'un README<br />
cd simple-repo<br />
echo "Hello, World" > README<br />
<br />
# Ajout du versionnement du fichier README<br />
git add README<br />
<br />
# Commit<br />
git commit<br />
</syntaxhighlight><br />
<br />
À ce niveau, on a un dépôt Git complètement fonctionnel.<br />
Cependant, il est intéressant de pousser ses modifications vers un autre dépôt, sur une autre machine.<br />
On va donc créer un dépôt bare sur une autre machine (ou autre dossier pour l'exemple)<br />
<br />
<syntaxhighlight lang="bash"><br />
git init --bare server-repo<br />
</syntaxhighlight><br />
<br />
On considère que l'URL pour accéder à ce dépôt est URL_REPO.<br />
On va d'abord ajouter ce dépôt serveur à la liste des dépôts connu-repos de votre dépôt local.<br />
Étant donné qu'il s'agit du dépôt "principal" à utiliser, on l'appellera //origin//, par convention.<br />
<br />
<syntaxhighlight lang="bash"><br />
git remote add origin URL_REPO<br />
# Récupération de ses informations<br />
git fetch origin<br />
</syntaxhighlight><br />
<br />
Ce serveur distant est "vide": il n'a aucune branche. On va donc enregistrer notre branche sur le serveur<br />
<br />
<syntaxhighlight lang="bash"><br />
git push origin master<br />
</syntaxhighlight><br />
<br />
À partir de cette commande, la branche locale //master// sera liée à la branche distante //origin/master//.<br />
Lors des prochaines commandes ''git push'', grâce à cette liaison, tous les commits sur la branche locale //master// seront poussées sur le serveur distant.<br />
<br />
====Méthode moins simple: bare first====<br />
<br />
Si on commence dans par le serveur "vide", il faudra le cloner au lieu de le définir comme un dépôt distant.<br />
<br />
<syntaxhighlight lang="bash"><br />
# Création du dépôt vide<br />
git init --bare server-repo<br />
</syntaxhighlight><br />
<br />
On considère que ce dépôt est accessible à l'URL URL_REPO<br />
<br />
<syntaxhighlight lang="bash"><br />
# Clonage du dépôt<br />
git clone URL_REPO clone-repo<br />
</syntaxhighlight><br />
<br />
Un avertissement indique que l'on clone un dépôt vide: le dépôt local à donc une branche master, mais elle n'est pas liée au dépôt distant, car celui-ci n'a aucune branche.<br />
Le dépôt distant est automatiquement appelé //origin//.<br />
<br />
<syntaxhighlight lang="bash"><br />
# Commit dans le dépôt local<br />
cd clone-repo<br />
echo hello > readme.rst<br />
git add readme.rst<br />
git commit et ses dépendances<br />
</syntaxhighlight><br />
<br />
Comme dans la méthode simple, il faut pousser la branche master vers le dépôt distant:<br />
<br />
<syntaxhighlight lang="bash"><br />
git push origin master<br />
</syntaxhighlight><br />
<br />
===De l'importance des README===<br />
<br />
Il est très important d'avoir au moins 2 fichiers dans votre dépôt Git:<br />
<br />
* LICENSE: contenant le texte **complet** de la licence de votre projet<br />
* README: décrivant votre projet et comment l'utiliser. Ce fichier doit rappeler le nom de la licence de votre projet<br />
<br />
Il est aussi recommandé d'avoir les fichiers suivants:<br />
<br />
* AUTHORS: contenant la liste des noms/pseudos et e-mails des auteurs de commits ou de code inclus dans ce projet<br />
* INSTALL: contenant la liste des dépendances de ce projet et des commandes à utiliser pour le compiler et l'installer<br />
<br />
Les fichiers LICENSE sont des fichiers textes bruts.<br />
Les autres fichiers sont généralement dans un format offrant un peu plus de lisibilté, par exemple dans les formats [http://daringfireball.net/projects/markdown/ Markdown] (.md) ou [http://docutils.sourceforge.net/rst.html reStructuredText] (.rst)<br />
<br />
Un plug-in existe pour éditer des fichier reStructuredText dans Eclipse: ReST Editor, disponible sur le [https://marketplace.eclipse.org/content/rest-editor Marketplace Eclipse]<br />
<br />
===GitHub & Travis-CI===<br />
<br />
Travis-CI est un service permettant d'exécuter un script dans une machine virtuelle Ubuntu dès que vous effectuez un push sur un de vos dépôts GitHub.<br />
L'intérêt est de savoir si la version d'un projet que vous avez rendu publique peut être compilée et si ses tests passent.<br />
<br />
La machine virtuelle "offerte" par Travis est préconfigurée pour le language indiqué dans son fichier de configuration ('''.travis.yml'''), mais il est possible d'utiliser la commande '''sudo apt-get install ...''' pour ajouter vos dépendances.<br />
<br />
Pour utiliser Travis:<br />
<br />
# Créez compte individuel sur GitHub https://github.com<br />
# ''Fork''ez le projet TAGL '''cron4j''' depuis https://github.com/donsez/tagl<br />
# Ajoutez un collaborateur (i.e. votre binôme) au projet ''forké'', via les paramètres (''settings'') de ce projet<br />
# Pour l'exemple, activez le service (ou hook) ''Email'' depuis les paramètres du dépôt: à chaque fois que vous ou un de vos collaborateurs ferra un '''git push''', vous recevrez une notification par mail.<br />
# Activez le service Travis-CI: identifiez-vous (''sign in'') sur https://travis-ci.org/ avec votre compte GitHub<br />
# Activez le service pour les projets sur lesquels vous souhaitez appliquer les principes d'intégration continue<br />
<br />
Travis-CI utilise un fichier nommé '''.travis.yml''' (attention: fichier caché sous Unix) pour se configurer et choisir les opérations à effectuer.<br />
Ce fichier doit se trouver à la racine de votre dépôt Git.<br />
<br />
Faites un '''Commit''' puis un '''Push''' du fichier '''.travis.yml''' ci-dessous.<br />
<br />
<pre><br />
language: java<br />
<br />
jdk:<br />
- oraclejdk7<br />
- openjdk6<br />
- openjdk7<br />
<br />
script:<br />
- pushd cron4j-original && ant rel && popd<br />
</pre><br />
<br />
Ce fichier indique que le projet dans ce dépôt doit être testé sur 3 versions de Java (Oracle Java 7, Open JDK 6 et Open JDK 7), et que le script à exécuter pour lancer les tests est '''pushd cron4j-original && ant rel && popd'''.<br />
Travis-CI peut exécuter plusieurs commandes dans script, chacune d'entre elles devant démarrer par un '-' (élément dans une liste de 'scripts').<br />
<br />
Attention: il n'est pas possible d'utiliser '''cd''' pour changer de répertoire, il faut utiliser '''pushd''' (déplacement dans un dossier) et '''popd''' (retour au dossier précédent) à la place.<br />
<br />
Une fois ce fichier de configuration '''pushé''', Travis-CI se mettra en route dès le prochain '''push'''.<br />
<br />
===Maven===<br />
<br />
[http://maven.apache.org/download.cgi Charger et installer Maven 3].<br />
<br />
<pre><br />
mvn -version<br />
</pre><br />
<br />
Faites une copie du projet, basée sur Maven:<br />
<br />
# Dans votre dépôt Git, créez un dossier '''cron4j-mvn''': il contiendra le projet Cron4J avec la structure Maven<br />
# Dans ce dossier, utilisez l'[https://maven.apache.org/guides/introduction/introduction-to-archetypes.html archetype] Maven [http://maven.apache.org/archetype/maven-archetype-bundles/maven-archetype-quickstart/ maven-archetype-quickstart] (la version des sources de cron4j utilisés est la 2.5.5):<br />
#:<pre>mvn archetype:generate -DarchetypeGroupId=org.apache.maven.archetypes -DarchetypeArtifactId=maven-archetype-quickstart</pre><br />
# Cette commande crée un projet avec un fichier ''pom.xml'', et une classe et un test modèles: supprimez ces modèles<br />
# Copiez les sources de Cron4J depuis le dossier '''cron4j-original''' dans le dossier '''src/main/java''' de votre projet Maven<br />
# Faites un essai de compilation:<br />
#:<pre>mvn clean verify</pre><br />
# Enfin modifiez le fichier '''.travis.yml''' à la racine de votre dépôt Git afin que Travis exécute la commande '''mvn clean verify''' à chaque mise à jour du dépôt GitHub.<br />
<br />
===Tests Unitaires avec JUnit 4===<br />
Survoller le tutoriel [http://www.vogella.com/tutorials/JUnit/article.html Unit Testing with JUnit]<br />
<br />
Ajouter le test unitaire suivant au layout du projet<br />
<br />
<pre><br />
package it.sauronsoftware;<br />
<br />
import it.sauronsoftware.cron4j.SchedulingPattern;<br />
import it.sauronsoftware.cron4j.InvalidPatternException;<br />
<br />
import static org.junit.Assert.assertEquals;<br />
import static org.junit.Assert.assertTrue;<br />
<br />
import org.junit.AfterClass;<br />
import org.junit.BeforeClass;<br />
import org.junit.Test;<br />
<br />
public class SchedulingPatternTest {<br />
<br />
@BeforeClass<br />
public static void testSetup() {<br />
}<br />
<br />
@AfterClass<br />
public static void testCleanup() {<br />
// Teardown for data used by the unit tests<br />
}<br />
<br />
@Test(expected = InvalidPatternException.class)<br />
public void testExceptionIsThrown() {<br />
SchedulingPattern sp = new SchedulingPattern("0 5 * *");<br />
}<br />
<br />
@Test<br />
public void testPattern() {<br />
String pattern;<br />
pattern="0 5 * * *|8 10 * * *|22 17 * * *";<br />
assertTrue(pattern + "is correct", SchedulingPattern.validate(pattern));<br />
pattern="0 5 * *";<br />
assertTrue(pattern + "is correct", SchedulingPattern.validate(pattern));<br />
}<br />
}<br />
</pre><br />
<br />
<br />
Rechercher la dépendance JUnit 4 dans [http://search.maven.org/#search|ga|1|JUnit Maven Central]<br />
<br />
Ajouter la dépendance JUnit 4 au pom.xml<br />
<br />
<br />
<br />
Lancer le build mvn test<br />
<br />
Modifier '''.travis.yml''' pour ''mvn clean test'' (Commit/Push)<br />
<br />
Regarder votre mail box.<br />
<br />
Naviguer sur http://travis-ci.org pour vérifier les builds effectués.<br />
<br />
Créer des tests unitaires du i.s.c.CronParser<br />
<br />
===Git (suite)===<br />
# Forker le projet '''cron4j-mvn''' d'un autre binome (ie l'origine)<br />
# Ajouter une bannière de licence dans le pom.xml<br />
# Lancer mvn clean install (bonne pratique)<br />
# Commiter<br />
# Faire un Push request vers l'origine<br />
<br />
===Contrôle Continu===<br />
Ajoutez au pom.xml le plugin Covertura pour la couverture de code.<br />
<br />
Répondez aux questions : ''Mais qu'est ce que la couverture de code ? En quoi c'est utile ?''<br />
<br />
Ajoutez au pom.xml les plugins pour la gestion du site et des rapports (Javadoc, tests unitaires, tags list (FIXME, TODO, ...), ...): http://maven.apache.org/plugins/maven-site-plugin/ et d'autres.<br />
<br />
Pour la prochaine séance, regardez les exemples d'utilisation de cron4j dans cron4j-original/examples<br />
<br />
===Bonus Track===<br />
<br />
====Clone SVN -> Git====<br />
<br />
Source: http://www.yterium.net/Migrer-un-projet-SVN-vers-GIT<br />
<br />
<syntaxhighlight lang="bash"><br />
# Cloner le dépôt SVN en dépôt Git (conservation historique)<br />
$ git svn clone svn://svn.code.sf.net/p/cron4j/code/trunk cron4j-original<br />
$ cd cron4j-original<br />
# Test compilation<br />
$ ant jar<br />
$ cd ..<br />
</syntaxhighlight><br />
<br />
====Préparation TAGL====<br />
<br />
<syntaxhighlight lang="bash"><br />
# Clone du dépôt TAGL<br />
$ git clone git@github.com:donsez/tagl.git<br />
$ cd tagl<br />
# "Fetch" du dépôt local cloné précédemment<br />
$ git fetch file://$(pwd)/../cron4j-original<br />
# Fusion de ce qui vient d'être fetché<br />
$ git merge FETCH_HEAD<br />
# Envoi sur le serveur<br />
$ git push<br />
</syntaxhighlight><br />
<br />
<br />
====Cherry-picking: reprise des modifications d'un collègue====<br />
<br />
On considère que:<br />
<br />
* votre dépôt Git distant est à l'adresse URL_DEPOT<br />
* votre collègue a un dépôt Git à l'adresse URL_COLLEGUE<br />
<br />
<br />
<syntaxhighlight lang="bash"><br />
# Dossier temporaire<br />
cd /tmp<br />
<br />
# Clone de votre dépôt<br />
git clone URL_DEPOT mon_depot<br />
<br />
# Déplacement dans votre dépôt<br />
cd mon_depot<br />
<br />
# Définition du dépôt distant<br />
git remote add collegue URL_COLLEGUE<br />
<br />
# Récupération des infos du dépôt du collègue<br />
git fetch collegue<br />
<br />
# Maintenant, on peut voir les branches du collègue<br />
git branch -a<br />
<br />
# On peut fusionner avec une branche<br />
git merge collegue/master<br />
<br />
# Si vous avez des conflits, éditez les fichiers concernés,<br />
# et committez avec git commit<br />
<br />
# Push vers votre dépôt distant<br />
git push origin<br />
<br />
# Optionnel: supprimez la référence vers le dépôt du collègue<br />
git remote rm collegue<br />
</syntaxhighlight><br />
<br />
<br />
====Archetype webapp====<br />
L'archetype webapp (http://maven.apache.org/archetype/maven-archetype-bundles/maven-archetype-webapp/) permet de créer le squelette d'une webapp. Créez un simple webapp monsite en version 0.1.0. (add/commit/push). Vous pourrez tester cette webapp en ajoutant au pom.xml le [https://wiki.eclipse.org/Jetty/Feature/Jetty_Maven_Plugin plugin maven Jetty].<br />
<br />
<syntaxhighlight lang="bash"><br />
mvn -Djetty.port=9999 jetty:run<br />
</syntaxhighlight><br />
<br />
Naviguez sur http://localhost:9999/monsite<br />
<br />
====Scrum tools====<br />
Ces 3 services peuvent être couplé à votre dépôt GitHub pour votre gestion de projet agile avec [[Scrum]] :<br />
* http://www.acunote.com/<br />
* http://backlogtool.com/<br />
* http://www.scrumdo.com/<br />
<br />
L'activation se fait via ''Settings > Webhooks & Services > Configure services''.<br />
<br />
==Séance 2==<br />
AOP & AspectJ<br />
<br />
Ajouter le [http://mojo.codehaus.org/aspectj-maven-plugin/ plugin Maven pour AspectJ] au pom.xml<br />
<br />
Ajouter un aspect de trace à l'invocation des méthodes run() de l'interface java.lang.Runnable (uniquement pour les objets ''schedulé''s).<br />
<br />
===Contrôle continu===<br />
Compléter l'aspect de trace avec le positionnement du [http://docs.oracle.com/javase/7/docs/api/java/lang/ThreadLocal.html java.lang.ThreadLocal] pour passer 1) l'identifiant du job et 2) le compteur des appels de la méthode de l'objet.<br />
<br />
==Séance 3==<br />
@WIP<br />
<br />
Injection de dépendances avec [[Guice]] <br />
<br />
<br />
==Séance 4==<br />
[[Tutorial OSGi avec Apache Felix]]<br />
<br />
<br />
<br />
==Séance 5==<br />
Faire un projet PDE pour un bundle cron4j.gogo (indépendant de cron4j.bundle)<br />
<br />
Utilisation de https://eclipse.org/tycho/</div>Calmanthttps://air.imag.fr/index.php?title=TAGL/TP&diff=15639TAGL/TP2014-02-19T11:46:44Z<p>Calmant: /* Maven */</p>
<hr />
<div>Travaux pratiques de l'UE [[TAGL]].<br />
<br />
==Séance 1==<br />
===Git===<br />
<br />
Création d'un dépôt Git local<br />
<br />
====Méthode simple: init first====<br />
<br />
Via cette méthode, on crée un dépôt local, avec un répertoire de travail, puis on pousse ses modifications vers un dépôt "bare".<br />
Cette méthode est la plus simple, car on dispose immédiatement d'un répertoire de travail.<br />
<br />
<syntaxhighlight lang="bash"><br />
# Création d'un dépôt Git dans le dossier simple-repo<br />
git init simple-repo<br />
<br />
# Création d'un README<br />
cd simple-repo<br />
echo "Hello, World" > README<br />
<br />
# Ajout du versionnement du fichier README<br />
git add README<br />
<br />
# Commit<br />
git commit<br />
</syntaxhighlight><br />
<br />
À ce niveau, on a un dépôt Git complètement fonctionnel.<br />
Cependant, il est intéressant de pousser ses modifications vers un autre dépôt, sur une autre machine.<br />
On va donc créer un dépôt bare sur une autre machine (ou autre dossier pour l'exemple)<br />
<br />
<syntaxhighlight lang="bash"><br />
git init --bare server-repo<br />
</syntaxhighlight><br />
<br />
On considère que l'URL pour accéder à ce dépôt est URL_REPO.<br />
On va d'abord ajouter ce dépôt serveur à la liste des dépôts connu-repos de votre dépôt local.<br />
Étant donné qu'il s'agit du dépôt "principal" à utiliser, on l'appellera //origin//, par convention.<br />
<br />
<syntaxhighlight lang="bash"><br />
git remote add origin URL_REPO<br />
# Récupération de ses informations<br />
git fetch origin<br />
</syntaxhighlight><br />
<br />
Ce serveur distant est "vide": il n'a aucune branche. On va donc enregistrer notre branche sur le serveur<br />
<br />
<syntaxhighlight lang="bash"><br />
git push origin master<br />
</syntaxhighlight><br />
<br />
À partir de cette commande, la branche locale //master// sera liée à la branche distante //origin/master//.<br />
Lors des prochaines commandes ''git push'', grâce à cette liaison, tous les commits sur la branche locale //master// seront poussées sur le serveur distant.<br />
<br />
====Méthode moins simple: bare first====<br />
<br />
Si on commence dans par le serveur "vide", il faudra le cloner au lieu de le définir comme un dépôt distant.<br />
<br />
<syntaxhighlight lang="bash"><br />
# Création du dépôt vide<br />
git init --bare server-repo<br />
</syntaxhighlight><br />
<br />
On considère que ce dépôt est accessible à l'URL URL_REPO<br />
<br />
<syntaxhighlight lang="bash"><br />
# Clonage du dépôt<br />
git clone URL_REPO clone-repo<br />
</syntaxhighlight><br />
<br />
Un avertissement indique que l'on clone un dépôt vide: le dépôt local à donc une branche master, mais elle n'est pas liée au dépôt distant, car celui-ci n'a aucune branche.<br />
Le dépôt distant est automatiquement appelé //origin//.<br />
<br />
<syntaxhighlight lang="bash"><br />
# Commit dans le dépôt local<br />
cd clone-repo<br />
echo hello > readme.rst<br />
git add readme.rst<br />
git commit et ses dépendances<br />
</syntaxhighlight><br />
<br />
Comme dans la méthode simple, il faut pousser la branche master vers le dépôt distant:<br />
<br />
<syntaxhighlight lang="bash"><br />
git push origin master<br />
</syntaxhighlight><br />
<br />
===De l'importance des README===<br />
<br />
Il est très important d'avoir au moins 2 fichiers dans votre dépôt Git:<br />
<br />
* LICENSE: contenant le texte **complet** de la licence de votre projet<br />
* README: décrivant votre projet et comment l'utiliser. Ce fichier doit rappeler le nom de la licence de votre projet<br />
<br />
Il est aussi recommandé d'avoir les fichiers suivants:<br />
<br />
* AUTHORS: contenant la liste des noms/pseudos et e-mails des auteurs de commits ou de code inclus dans ce projet<br />
* INSTALL: contenant la liste des dépendances de ce projet et des commandes à utiliser pour le compiler et l'installer<br />
<br />
Les fichiers LICENSE sont des fichiers textes bruts.<br />
Les autres fichiers sont généralement dans un format offrant un peu plus de lisibilté, par exemple dans les formats [http://daringfireball.net/projects/markdown/ Markdown] (.md) ou [http://docutils.sourceforge.net/rst.html reStructuredText] (.rst)<br />
<br />
Un plug-in existe pour éditer des fichier reStructuredText dans Eclipse: ReST Editor, disponible sur le [https://marketplace.eclipse.org/content/rest-editor Marketplace Eclipse]<br />
<br />
===GitHub & Travis-CI===<br />
<br />
Travis-CI est un service permettant d'exécuter un script dans une machine virtuelle Ubuntu dès que vous effectuez un push sur un de vos dépôts GitHub.<br />
L'intérêt est de savoir si la version d'un projet que vous avez rendu publique peut être compilée et si ses tests passent.<br />
<br />
La machine virtuelle "offerte" par Travis est préconfigurée pour le language indiqué dans son fichier de configuration ('''.travis.yml'''), mais il est possible d'utiliser la commande '''sudo apt-get install ...''' pour ajouter vos dépendances.<br />
<br />
Pour utiliser Travis:<br />
<br />
# Créez compte individuel sur GitHub https://github.com<br />
# ''Fork''ez le projet TAGL '''cron4j''' depuis https://github.com/donsez/tagl<br />
# Ajoutez un collaborateur (i.e. votre binôme) au projet ''forké'', via les paramètres (''settings'') de ce projet<br />
# Pour l'exemple, activez le service (ou hook) ''Email'' depuis les paramètres du dépôt: à chaque fois que vous ou un de vos collaborateurs ferra un '''git push''', vous recevrez une notification par mail.<br />
# Activez le service Travis-CI: identifiez-vous (''sign in'') sur https://travis-ci.org/ avec votre compte GitHub<br />
# Activez le service pour les projets sur lesquels vous souhaitez appliquer les principes d'intégration continue<br />
<br />
Travis-CI utilise un fichier nommé '''.travis.yml''' (attention: fichier caché sous Unix) pour se configurer et choisir les opérations à effectuer.<br />
Ce fichier doit se trouver à la racine de votre dépôt Git.<br />
<br />
Faites un '''Commit''' puis un '''Push''' du fichier '''.travis.yml''' ci-dessous.<br />
<br />
<pre><br />
language: java<br />
<br />
jdk:<br />
- oraclejdk7<br />
- openjdk6<br />
- openjdk7<br />
<br />
script:<br />
- pushd cron4j-original && ant rel && popd<br />
</pre><br />
<br />
Ce fichier indique que le projet dans ce dépôt doit être testé sur 3 versions de Java (Oracle Java 7, Open JDK 6 et Open JDK 7), et que le script à exécuter pour lancer les tests est '''pushd cron4j-original && ant rel && popd'''.<br />
Travis-CI peut exécuter plusieurs commandes dans script, chacune d'entre elles devant démarrer par un '-' (élément dans une liste de 'scripts').<br />
<br />
Attention: il n'est pas possible d'utiliser '''cd''' pour changer de répertoire, il faut utiliser '''pushd''' (déplacement dans un dossier) et '''popd''' (retour au dossier précédent) à la place.<br />
<br />
Une fois ce fichier de configuration '''pushé''', Travis-CI se mettra en route dès le prochain '''push'''.<br />
<br />
===Maven===<br />
[http://maven.apache.org/download.cgi Changer et installer Maven 3].<br />
<br />
<pre><br />
mvn -version<br />
</pre><br />
<br />
Créer un dossier '''cron4j-mvn''': il contiendra le projet Cron4J avec le layout Maven, en réorganisant les sources de cron4j-original. Pour cela, vous utiliserez préalablement un [https://maven.apache.org/guides/introduction/introduction-to-archetypes.html archetype Maven] ''simple'' ou ''quickstart''. (la version de cron4j est la 2.5.5).<br />
<br />
Modifier .travis.yml pour ''mvn -DskipTests=true clean install'' (Commit/Push)<br />
<br />
===Tests Unitaires avec JUnit 4===<br />
Survoller le tutoriel [http://www.vogella.com/tutorials/JUnit/article.html Unit Testing with JUnit]<br />
<br />
Ajouter le test unitaire suivant au layout du projet<br />
<br />
<pre><br />
package it.sauronsoftware;<br />
<br />
import it.sauronsoftware.cron4j.SchedulingPattern;<br />
import it.sauronsoftware.cron4j.InvalidPatternException;<br />
<br />
import static org.junit.Assert.assertEquals;<br />
import static org.junit.Assert.assertTrue;<br />
<br />
import org.junit.AfterClass;<br />
import org.junit.BeforeClass;<br />
import org.junit.Test;<br />
<br />
public class SchedulingPatternTest {<br />
<br />
@BeforeClass<br />
public static void testSetup() {<br />
}<br />
<br />
@AfterClass<br />
public static void testCleanup() {<br />
// Teardown for data used by the unit tests<br />
}<br />
<br />
@Test(expected = InvalidPatternException.class)<br />
public void testExceptionIsThrown() {<br />
SchedulingPattern sp = new SchedulingPattern("0 5 * *");<br />
}<br />
<br />
@Test<br />
public void testPattern() {<br />
String pattern;<br />
pattern="0 5 * * *|8 10 * * *|22 17 * * *";<br />
assertTrue(pattern + "is correct", SchedulingPattern.validate(pattern));<br />
pattern="0 5 * *";<br />
assertTrue(pattern + "is correct", SchedulingPattern.validate(pattern));<br />
}<br />
}<br />
</pre><br />
<br />
<br />
Rechercher la dépendance JUnit 4 dans [http://search.maven.org/#search|ga|1|JUnit Maven Central]<br />
<br />
Ajouter la dépendance JUnit 4 au pom.xml<br />
<br />
<br />
<br />
Lancer le build mvn test<br />
<br />
Modifier '''.travis.yml''' pour ''mvn clean test'' (Commit/Push)<br />
<br />
Regarder votre mail box.<br />
<br />
Naviguer sur http://travis-ci.org pour vérifier les builds effectués.<br />
<br />
Créer des tests unitaires du i.s.c.CronParser<br />
<br />
===Git (suite)===<br />
# Forker le projet '''cron4j-mvn''' d'un autre binome (ie l'origine)<br />
# Ajouter une bannière de licence dans le pom.xml<br />
# Lancer mvn clean install (bonne pratique)<br />
# Commiter<br />
# Faire un Push request vers l'origine<br />
<br />
===Contrôle Continu===<br />
Ajoutez au pom.xml le plugin Covertura pour la couverture de code.<br />
<br />
Répondez aux questions : ''Mais qu'est ce que la couverture de code ? En quoi c'est utile ?''<br />
<br />
Ajoutez au pom.xml les plugins pour la gestion du site et des rapports (Javadoc, tests unitaires, tags list (FIXME, TODO, ...), ...): http://maven.apache.org/plugins/maven-site-plugin/ et d'autres.<br />
<br />
Pour la prochaine séance, regardez les exemples d'utilisation de cron4j dans cron4j-original/examples<br />
<br />
===Bonus Track===<br />
<br />
====Clone SVN -> Git====<br />
<br />
Source: http://www.yterium.net/Migrer-un-projet-SVN-vers-GIT<br />
<br />
<syntaxhighlight lang="bash"><br />
# Cloner le dépôt SVN en dépôt Git (conservation historique)<br />
$ git svn clone svn://svn.code.sf.net/p/cron4j/code/trunk cron4j-original<br />
$ cd cron4j-original<br />
# Test compilation<br />
$ ant jar<br />
$ cd ..<br />
</syntaxhighlight><br />
<br />
====Préparation TAGL====<br />
<br />
<syntaxhighlight lang="bash"><br />
# Clone du dépôt TAGL<br />
$ git clone git@github.com:donsez/tagl.git<br />
$ cd tagl<br />
# "Fetch" du dépôt local cloné précédemment<br />
$ git fetch file://$(pwd)/../cron4j-original<br />
# Fusion de ce qui vient d'être fetché<br />
$ git merge FETCH_HEAD<br />
# Envoi sur le serveur<br />
$ git push<br />
</syntaxhighlight><br />
<br />
<br />
====Cherry-picking: reprise des modifications d'un collègue====<br />
<br />
On considère que:<br />
<br />
* votre dépôt Git distant est à l'adresse URL_DEPOT<br />
* votre collègue a un dépôt Git à l'adresse URL_COLLEGUE<br />
<br />
<br />
<syntaxhighlight lang="bash"><br />
# Dossier temporaire<br />
cd /tmp<br />
<br />
# Clone de votre dépôt<br />
git clone URL_DEPOT mon_depot<br />
<br />
# Déplacement dans votre dépôt<br />
cd mon_depot<br />
<br />
# Définition du dépôt distant<br />
git remote add collegue URL_COLLEGUE<br />
<br />
# Récupération des infos du dépôt du collègue<br />
git fetch collegue<br />
<br />
# Maintenant, on peut voir les branches du collègue<br />
git branch -a<br />
<br />
# On peut fusionner avec une branche<br />
git merge collegue/master<br />
<br />
# Si vous avez des conflits, éditez les fichiers concernés,<br />
# et committez avec git commit<br />
<br />
# Push vers votre dépôt distant<br />
git push origin<br />
<br />
# Optionnel: supprimez la référence vers le dépôt du collègue<br />
git remote rm collegue<br />
</syntaxhighlight><br />
<br />
<br />
====Archetype webapp====<br />
L'archetype webapp (http://maven.apache.org/archetype/maven-archetype-bundles/maven-archetype-webapp/) permet de créer le squelette d'une webapp. Créez un simple webapp monsite en version 0.1.0. (add/commit/push). Vous pourrez tester cette webapp en ajoutant au pom.xml le [https://wiki.eclipse.org/Jetty/Feature/Jetty_Maven_Plugin plugin maven Jetty].<br />
<br />
<syntaxhighlight lang="bash"><br />
mvn -Djetty.port=9999 jetty:run<br />
</syntaxhighlight><br />
<br />
Naviguez sur http://localhost:9999/monsite<br />
<br />
====Scrum tools====<br />
Ces 3 services peuvent être couplé à votre dépôt GitHub pour votre gestion de projet agile avec [[Scrum]] :<br />
* http://www.acunote.com/<br />
* http://backlogtool.com/<br />
* http://www.scrumdo.com/<br />
<br />
L'activation se fait via ''Settings > Webhooks & Services > Configure services''.<br />
<br />
==Séance 2==<br />
AOP & AspectJ<br />
<br />
Ajouter le [http://mojo.codehaus.org/aspectj-maven-plugin/ plugin Maven pour AspectJ] au pom.xml<br />
<br />
Ajouter un aspect de trace à l'invocation des méthodes run() de l'interface java.lang.Runnable (uniquement pour les objets ''schedulé''s).<br />
<br />
===Contrôle continu===<br />
Compléter l'aspect de trace avec le positionnement du [http://docs.oracle.com/javase/7/docs/api/java/lang/ThreadLocal.html java.lang.ThreadLocal] pour passer 1) l'identifiant du job et 2) le compteur des appels de la méthode de l'objet.<br />
<br />
==Séance 3==<br />
@WIP<br />
<br />
Injection de dépendances avec [[Guice]] <br />
<br />
<br />
==Séance 4==<br />
[[Tutorial OSGi avec Apache Felix]]<br />
<br />
<br />
<br />
==Séance 5==<br />
Faire un projet PDE pour un bundle cron4j.gogo (indépendant de cron4j.bundle)<br />
<br />
Utilisation de https://eclipse.org/tycho/</div>Calmanthttps://air.imag.fr/index.php?title=TAGL/TP&diff=15638TAGL/TP2014-02-19T11:42:42Z<p>Calmant: /* GitHub & Travis-CI */</p>
<hr />
<div>Travaux pratiques de l'UE [[TAGL]].<br />
<br />
==Séance 1==<br />
===Git===<br />
<br />
Création d'un dépôt Git local<br />
<br />
====Méthode simple: init first====<br />
<br />
Via cette méthode, on crée un dépôt local, avec un répertoire de travail, puis on pousse ses modifications vers un dépôt "bare".<br />
Cette méthode est la plus simple, car on dispose immédiatement d'un répertoire de travail.<br />
<br />
<syntaxhighlight lang="bash"><br />
# Création d'un dépôt Git dans le dossier simple-repo<br />
git init simple-repo<br />
<br />
# Création d'un README<br />
cd simple-repo<br />
echo "Hello, World" > README<br />
<br />
# Ajout du versionnement du fichier README<br />
git add README<br />
<br />
# Commit<br />
git commit<br />
</syntaxhighlight><br />
<br />
À ce niveau, on a un dépôt Git complètement fonctionnel.<br />
Cependant, il est intéressant de pousser ses modifications vers un autre dépôt, sur une autre machine.<br />
On va donc créer un dépôt bare sur une autre machine (ou autre dossier pour l'exemple)<br />
<br />
<syntaxhighlight lang="bash"><br />
git init --bare server-repo<br />
</syntaxhighlight><br />
<br />
On considère que l'URL pour accéder à ce dépôt est URL_REPO.<br />
On va d'abord ajouter ce dépôt serveur à la liste des dépôts connu-repos de votre dépôt local.<br />
Étant donné qu'il s'agit du dépôt "principal" à utiliser, on l'appellera //origin//, par convention.<br />
<br />
<syntaxhighlight lang="bash"><br />
git remote add origin URL_REPO<br />
# Récupération de ses informations<br />
git fetch origin<br />
</syntaxhighlight><br />
<br />
Ce serveur distant est "vide": il n'a aucune branche. On va donc enregistrer notre branche sur le serveur<br />
<br />
<syntaxhighlight lang="bash"><br />
git push origin master<br />
</syntaxhighlight><br />
<br />
À partir de cette commande, la branche locale //master// sera liée à la branche distante //origin/master//.<br />
Lors des prochaines commandes ''git push'', grâce à cette liaison, tous les commits sur la branche locale //master// seront poussées sur le serveur distant.<br />
<br />
====Méthode moins simple: bare first====<br />
<br />
Si on commence dans par le serveur "vide", il faudra le cloner au lieu de le définir comme un dépôt distant.<br />
<br />
<syntaxhighlight lang="bash"><br />
# Création du dépôt vide<br />
git init --bare server-repo<br />
</syntaxhighlight><br />
<br />
On considère que ce dépôt est accessible à l'URL URL_REPO<br />
<br />
<syntaxhighlight lang="bash"><br />
# Clonage du dépôt<br />
git clone URL_REPO clone-repo<br />
</syntaxhighlight><br />
<br />
Un avertissement indique que l'on clone un dépôt vide: le dépôt local à donc une branche master, mais elle n'est pas liée au dépôt distant, car celui-ci n'a aucune branche.<br />
Le dépôt distant est automatiquement appelé //origin//.<br />
<br />
<syntaxhighlight lang="bash"><br />
# Commit dans le dépôt local<br />
cd clone-repo<br />
echo hello > readme.rst<br />
git add readme.rst<br />
git commit et ses dépendances<br />
</syntaxhighlight><br />
<br />
Comme dans la méthode simple, il faut pousser la branche master vers le dépôt distant:<br />
<br />
<syntaxhighlight lang="bash"><br />
git push origin master<br />
</syntaxhighlight><br />
<br />
===De l'importance des README===<br />
<br />
Il est très important d'avoir au moins 2 fichiers dans votre dépôt Git:<br />
<br />
* LICENSE: contenant le texte **complet** de la licence de votre projet<br />
* README: décrivant votre projet et comment l'utiliser. Ce fichier doit rappeler le nom de la licence de votre projet<br />
<br />
Il est aussi recommandé d'avoir les fichiers suivants:<br />
<br />
* AUTHORS: contenant la liste des noms/pseudos et e-mails des auteurs de commits ou de code inclus dans ce projet<br />
* INSTALL: contenant la liste des dépendances de ce projet et des commandes à utiliser pour le compiler et l'installer<br />
<br />
Les fichiers LICENSE sont des fichiers textes bruts.<br />
Les autres fichiers sont généralement dans un format offrant un peu plus de lisibilté, par exemple dans les formats [http://daringfireball.net/projects/markdown/ Markdown] (.md) ou [http://docutils.sourceforge.net/rst.html reStructuredText] (.rst)<br />
<br />
Un plug-in existe pour éditer des fichier reStructuredText dans Eclipse: ReST Editor, disponible sur le [https://marketplace.eclipse.org/content/rest-editor Marketplace Eclipse]<br />
<br />
===GitHub & Travis-CI===<br />
<br />
Travis-CI est un service permettant d'exécuter un script dans une machine virtuelle Ubuntu dès que vous effectuez un push sur un de vos dépôts GitHub.<br />
L'intérêt est de savoir si la version d'un projet que vous avez rendu publique peut être compilée et si ses tests passent.<br />
<br />
La machine virtuelle "offerte" par Travis est préconfigurée pour le language indiqué dans son fichier de configuration ('''.travis.yml'''), mais il est possible d'utiliser la commande '''sudo apt-get install ...''' pour ajouter vos dépendances.<br />
<br />
Pour utiliser Travis:<br />
<br />
# Créez compte individuel sur GitHub https://github.com<br />
# ''Fork''ez le projet TAGL '''cron4j''' depuis https://github.com/donsez/tagl<br />
# Ajoutez un collaborateur (i.e. votre binôme) au projet ''forké'', via les paramètres (''settings'') de ce projet<br />
# Pour l'exemple, activez le service (ou hook) ''Email'' depuis les paramètres du dépôt: à chaque fois que vous ou un de vos collaborateurs ferra un '''git push''', vous recevrez une notification par mail.<br />
# Activez le service Travis-CI: identifiez-vous (''sign in'') sur https://travis-ci.org/ avec votre compte GitHub<br />
# Activez le service pour les projets sur lesquels vous souhaitez appliquer les principes d'intégration continue<br />
<br />
Travis-CI utilise un fichier nommé '''.travis.yml''' (attention: fichier caché sous Unix) pour se configurer et choisir les opérations à effectuer.<br />
Ce fichier doit se trouver à la racine de votre dépôt Git.<br />
<br />
Faites un '''Commit''' puis un '''Push''' du fichier '''.travis.yml''' ci-dessous.<br />
<br />
<pre><br />
language: java<br />
<br />
jdk:<br />
- oraclejdk7<br />
- openjdk6<br />
- openjdk7<br />
<br />
script:<br />
- pushd cron4j-original && ant rel && popd<br />
</pre><br />
<br />
Ce fichier indique que le projet dans ce dépôt doit être testé sur 3 versions de Java (Oracle Java 7, Open JDK 6 et Open JDK 7), et que le script à exécuter pour lancer les tests est '''pushd cron4j-original && ant rel && popd'''.<br />
Travis-CI peut exécuter plusieurs commandes dans script, chacune d'entre elles devant démarrer par un '-' (élément dans une liste de 'scripts').<br />
<br />
Attention: il n'est pas possible d'utiliser '''cd''' pour changer de répertoire, il faut utiliser '''pushd''' (déplacement dans un dossier) et '''popd''' (retour au dossier précédent) à la place.<br />
<br />
Une fois ce fichier de configuration '''pushé''', Travis-CI se mettra en route dès le prochain '''push'''.<br />
<br />
===Maven===<br />
[http://maven.apache.org/download.cgi Changer et installer Maven 3].<br />
<br />
<pre><br />
mvn -version<br />
</pre><br />
<br />
Créer '''cron4j-mvn''' (layout + pom.xml) en réorganisant les sources de cron4j-original. Pour cela, vous utiliserez préalablement un [https://maven.apache.org/guides/introduction/introduction-to-archetypes.html archetype Maven] ''simple'' ou ''quickstart''. (la version de cron4j est la 2.5.5).<br />
<br />
Modifier .travis.yml pour ''mvn -DskipTests=true clean install'' (Commit/Push)<br />
<br />
<br />
===Tests Unitaires avec JUnit 4===<br />
Survoller le tutoriel [http://www.vogella.com/tutorials/JUnit/article.html Unit Testing with JUnit]<br />
<br />
Ajouter le test unitaire suivant au layout du projet<br />
<br />
<pre><br />
package it.sauronsoftware;<br />
<br />
import it.sauronsoftware.cron4j.SchedulingPattern;<br />
import it.sauronsoftware.cron4j.InvalidPatternException;<br />
<br />
import static org.junit.Assert.assertEquals;<br />
import static org.junit.Assert.assertTrue;<br />
<br />
import org.junit.AfterClass;<br />
import org.junit.BeforeClass;<br />
import org.junit.Test;<br />
<br />
public class SchedulingPatternTest {<br />
<br />
@BeforeClass<br />
public static void testSetup() {<br />
}<br />
<br />
@AfterClass<br />
public static void testCleanup() {<br />
// Teardown for data used by the unit tests<br />
}<br />
<br />
@Test(expected = InvalidPatternException.class)<br />
public void testExceptionIsThrown() {<br />
SchedulingPattern sp = new SchedulingPattern("0 5 * *");<br />
}<br />
<br />
@Test<br />
public void testPattern() {<br />
String pattern;<br />
pattern="0 5 * * *|8 10 * * *|22 17 * * *";<br />
assertTrue(pattern + "is correct", SchedulingPattern.validate(pattern));<br />
pattern="0 5 * *";<br />
assertTrue(pattern + "is correct", SchedulingPattern.validate(pattern));<br />
}<br />
}<br />
</pre><br />
<br />
<br />
Rechercher la dépendance JUnit 4 dans [http://search.maven.org/#search|ga|1|JUnit Maven Central]<br />
<br />
Ajouter la dépendance JUnit 4 au pom.xml<br />
<br />
<br />
<br />
Lancer le build mvn test<br />
<br />
Modifier '''.travis.yml''' pour ''mvn clean test'' (Commit/Push)<br />
<br />
Regarder votre mail box.<br />
<br />
Naviguer sur http://travis-ci.org pour vérifier les builds effectués.<br />
<br />
Créer des tests unitaires du i.s.c.CronParser<br />
<br />
===Git (suite)===<br />
# Forker le projet '''cron4j-mvn''' d'un autre binome (ie l'origine)<br />
# Ajouter une bannière de licence dans le pom.xml<br />
# Lancer mvn clean install (bonne pratique)<br />
# Commiter<br />
# Faire un Push request vers l'origine<br />
<br />
===Contrôle Continu===<br />
Ajoutez au pom.xml le plugin Covertura pour la couverture de code.<br />
<br />
Répondez aux questions : ''Mais qu'est ce que la couverture de code ? En quoi c'est utile ?''<br />
<br />
Ajoutez au pom.xml les plugins pour la gestion du site et des rapports (Javadoc, tests unitaires, tags list (FIXME, TODO, ...), ...): http://maven.apache.org/plugins/maven-site-plugin/ et d'autres.<br />
<br />
Pour la prochaine séance, regardez les exemples d'utilisation de cron4j dans cron4j-original/examples<br />
<br />
===Bonus Track===<br />
<br />
====Clone SVN -> Git====<br />
<br />
Source: http://www.yterium.net/Migrer-un-projet-SVN-vers-GIT<br />
<br />
<syntaxhighlight lang="bash"><br />
# Cloner le dépôt SVN en dépôt Git (conservation historique)<br />
$ git svn clone svn://svn.code.sf.net/p/cron4j/code/trunk cron4j-original<br />
$ cd cron4j-original<br />
# Test compilation<br />
$ ant jar<br />
$ cd ..<br />
</syntaxhighlight><br />
<br />
====Préparation TAGL====<br />
<br />
<syntaxhighlight lang="bash"><br />
# Clone du dépôt TAGL<br />
$ git clone git@github.com:donsez/tagl.git<br />
$ cd tagl<br />
# "Fetch" du dépôt local cloné précédemment<br />
$ git fetch file://$(pwd)/../cron4j-original<br />
# Fusion de ce qui vient d'être fetché<br />
$ git merge FETCH_HEAD<br />
# Envoi sur le serveur<br />
$ git push<br />
</syntaxhighlight><br />
<br />
<br />
====Cherry-picking: reprise des modifications d'un collègue====<br />
<br />
On considère que:<br />
<br />
* votre dépôt Git distant est à l'adresse URL_DEPOT<br />
* votre collègue a un dépôt Git à l'adresse URL_COLLEGUE<br />
<br />
<br />
<syntaxhighlight lang="bash"><br />
# Dossier temporaire<br />
cd /tmp<br />
<br />
# Clone de votre dépôt<br />
git clone URL_DEPOT mon_depot<br />
<br />
# Déplacement dans votre dépôt<br />
cd mon_depot<br />
<br />
# Définition du dépôt distant<br />
git remote add collegue URL_COLLEGUE<br />
<br />
# Récupération des infos du dépôt du collègue<br />
git fetch collegue<br />
<br />
# Maintenant, on peut voir les branches du collègue<br />
git branch -a<br />
<br />
# On peut fusionner avec une branche<br />
git merge collegue/master<br />
<br />
# Si vous avez des conflits, éditez les fichiers concernés,<br />
# et committez avec git commit<br />
<br />
# Push vers votre dépôt distant<br />
git push origin<br />
<br />
# Optionnel: supprimez la référence vers le dépôt du collègue<br />
git remote rm collegue<br />
</syntaxhighlight><br />
<br />
<br />
====Archetype webapp====<br />
L'archetype webapp (http://maven.apache.org/archetype/maven-archetype-bundles/maven-archetype-webapp/) permet de créer le squelette d'une webapp. Créez un simple webapp monsite en version 0.1.0. (add/commit/push). Vous pourrez tester cette webapp en ajoutant au pom.xml le [https://wiki.eclipse.org/Jetty/Feature/Jetty_Maven_Plugin plugin maven Jetty].<br />
<br />
<syntaxhighlight lang="bash"><br />
mvn -Djetty.port=9999 jetty:run<br />
</syntaxhighlight><br />
<br />
Naviguez sur http://localhost:9999/monsite<br />
<br />
====Scrum tools====<br />
Ces 3 services peuvent être couplé à votre dépôt GitHub pour votre gestion de projet agile avec [[Scrum]] :<br />
* http://www.acunote.com/<br />
* http://backlogtool.com/<br />
* http://www.scrumdo.com/<br />
<br />
L'activation se fait via ''Settings > Webhooks & Services > Configure services''.<br />
<br />
==Séance 2==<br />
AOP & AspectJ<br />
<br />
Ajouter le [http://mojo.codehaus.org/aspectj-maven-plugin/ plugin Maven pour AspectJ] au pom.xml<br />
<br />
Ajouter un aspect de trace à l'invocation des méthodes run() de l'interface java.lang.Runnable (uniquement pour les objets ''schedulé''s).<br />
<br />
===Contrôle continu===<br />
Compléter l'aspect de trace avec le positionnement du [http://docs.oracle.com/javase/7/docs/api/java/lang/ThreadLocal.html java.lang.ThreadLocal] pour passer 1) l'identifiant du job et 2) le compteur des appels de la méthode de l'objet.<br />
<br />
==Séance 3==<br />
@WIP<br />
<br />
Injection de dépendances avec [[Guice]] <br />
<br />
<br />
==Séance 4==<br />
[[Tutorial OSGi avec Apache Felix]]<br />
<br />
<br />
<br />
==Séance 5==<br />
Faire un projet PDE pour un bundle cron4j.gogo (indépendant de cron4j.bundle)<br />
<br />
Utilisation de https://eclipse.org/tycho/</div>Calmanthttps://air.imag.fr/index.php?title=TAGL/TP&diff=15637TAGL/TP2014-02-19T11:41:38Z<p>Calmant: /* GitHub & Travis-CI */</p>
<hr />
<div>Travaux pratiques de l'UE [[TAGL]].<br />
<br />
==Séance 1==<br />
===Git===<br />
<br />
Création d'un dépôt Git local<br />
<br />
====Méthode simple: init first====<br />
<br />
Via cette méthode, on crée un dépôt local, avec un répertoire de travail, puis on pousse ses modifications vers un dépôt "bare".<br />
Cette méthode est la plus simple, car on dispose immédiatement d'un répertoire de travail.<br />
<br />
<syntaxhighlight lang="bash"><br />
# Création d'un dépôt Git dans le dossier simple-repo<br />
git init simple-repo<br />
<br />
# Création d'un README<br />
cd simple-repo<br />
echo "Hello, World" > README<br />
<br />
# Ajout du versionnement du fichier README<br />
git add README<br />
<br />
# Commit<br />
git commit<br />
</syntaxhighlight><br />
<br />
À ce niveau, on a un dépôt Git complètement fonctionnel.<br />
Cependant, il est intéressant de pousser ses modifications vers un autre dépôt, sur une autre machine.<br />
On va donc créer un dépôt bare sur une autre machine (ou autre dossier pour l'exemple)<br />
<br />
<syntaxhighlight lang="bash"><br />
git init --bare server-repo<br />
</syntaxhighlight><br />
<br />
On considère que l'URL pour accéder à ce dépôt est URL_REPO.<br />
On va d'abord ajouter ce dépôt serveur à la liste des dépôts connu-repos de votre dépôt local.<br />
Étant donné qu'il s'agit du dépôt "principal" à utiliser, on l'appellera //origin//, par convention.<br />
<br />
<syntaxhighlight lang="bash"><br />
git remote add origin URL_REPO<br />
# Récupération de ses informations<br />
git fetch origin<br />
</syntaxhighlight><br />
<br />
Ce serveur distant est "vide": il n'a aucune branche. On va donc enregistrer notre branche sur le serveur<br />
<br />
<syntaxhighlight lang="bash"><br />
git push origin master<br />
</syntaxhighlight><br />
<br />
À partir de cette commande, la branche locale //master// sera liée à la branche distante //origin/master//.<br />
Lors des prochaines commandes ''git push'', grâce à cette liaison, tous les commits sur la branche locale //master// seront poussées sur le serveur distant.<br />
<br />
====Méthode moins simple: bare first====<br />
<br />
Si on commence dans par le serveur "vide", il faudra le cloner au lieu de le définir comme un dépôt distant.<br />
<br />
<syntaxhighlight lang="bash"><br />
# Création du dépôt vide<br />
git init --bare server-repo<br />
</syntaxhighlight><br />
<br />
On considère que ce dépôt est accessible à l'URL URL_REPO<br />
<br />
<syntaxhighlight lang="bash"><br />
# Clonage du dépôt<br />
git clone URL_REPO clone-repo<br />
</syntaxhighlight><br />
<br />
Un avertissement indique que l'on clone un dépôt vide: le dépôt local à donc une branche master, mais elle n'est pas liée au dépôt distant, car celui-ci n'a aucune branche.<br />
Le dépôt distant est automatiquement appelé //origin//.<br />
<br />
<syntaxhighlight lang="bash"><br />
# Commit dans le dépôt local<br />
cd clone-repo<br />
echo hello > readme.rst<br />
git add readme.rst<br />
git commit et ses dépendances<br />
</syntaxhighlight><br />
<br />
Comme dans la méthode simple, il faut pousser la branche master vers le dépôt distant:<br />
<br />
<syntaxhighlight lang="bash"><br />
git push origin master<br />
</syntaxhighlight><br />
<br />
===De l'importance des README===<br />
<br />
Il est très important d'avoir au moins 2 fichiers dans votre dépôt Git:<br />
<br />
* LICENSE: contenant le texte **complet** de la licence de votre projet<br />
* README: décrivant votre projet et comment l'utiliser. Ce fichier doit rappeler le nom de la licence de votre projet<br />
<br />
Il est aussi recommandé d'avoir les fichiers suivants:<br />
<br />
* AUTHORS: contenant la liste des noms/pseudos et e-mails des auteurs de commits ou de code inclus dans ce projet<br />
* INSTALL: contenant la liste des dépendances de ce projet et des commandes à utiliser pour le compiler et l'installer<br />
<br />
Les fichiers LICENSE sont des fichiers textes bruts.<br />
Les autres fichiers sont généralement dans un format offrant un peu plus de lisibilté, par exemple dans les formats [http://daringfireball.net/projects/markdown/ Markdown] (.md) ou [http://docutils.sourceforge.net/rst.html reStructuredText] (.rst)<br />
<br />
Un plug-in existe pour éditer des fichier reStructuredText dans Eclipse: ReST Editor, disponible sur le [https://marketplace.eclipse.org/content/rest-editor Marketplace Eclipse]<br />
<br />
===GitHub & Travis-CI===<br />
<br />
Travis-CI est un service permettant d'exécuter un script dans une machine virtuelle Ubuntu dès que vous effectuez un push sur un de vos dépôts GitHub.<br />
L'intérêt est de savoir si la version d'un projet que vous avez rendu publique peut être compilée et si ses tests passent.<br />
<br />
La machine virtuelle "offerte" par Travis est préconfigurée pour le language indiqué dans son fichier de configuration ('''.travis.yml'''), mais il est possible d'utiliser la commande '''sudo apt-get install ...''' pour ajouter vos dépendances.<br />
<br />
Pour utiliser Travis:<br />
<br />
#. Créez compte individuel sur GitHub https://github.com<br />
#. ''Fork''ez le projet TAGL '''cron4j''' depuis https://github.com/donsez/tagl<br />
#. Ajoutez un collaborateur (i.e. votre binôme) au projet ''forké'', via les paramètres (''settings'') de ce projet<br />
#. Pour l'exemple, activez le service (ou hook) ''Email'' depuis les paramètres du dépôt: à chaque fois que vous ou un de vos collaborateurs ferra un '''git push''', vous recevrez une notification par mail.<br />
#. Activez le service Travis-CI: identifiez-vous (''sign in'') sur https://travis-ci.org/ avec votre compte GitHub<br />
#. Activez le service pour les projets sur lesquels vous souhaitez appliquer les principes d'intégration continue<br />
<br />
Travis-CI utilise un fichier nommé '''.travis.yml''' (attention: fichier caché sous Unix) pour se configurer et choisir les opérations à effectuer.<br />
Ce fichier doit se trouver à la racine de votre dépôt Git.<br />
<br />
Faites un '''Commit''' puis un '''Push''' du fichier '''.travis.yml''' ci-dessous.<br />
<br />
<pre><br />
language: java<br />
<br />
jdk:<br />
- oraclejdk7<br />
- openjdk6<br />
- openjdk7<br />
<br />
script:<br />
- pushd cron4j-original && ant rel && popd<br />
</pre><br />
<br />
Ce fichier indique que le projet dans ce dépôt doit être testé sur 3 versions de Java (Oracle Java 7, Open JDK 6 et Open JDK 7), et que le script à exécuter pour lancer les tests est '''pushd cron4j-original && ant rel && popd'''.<br />
Travis-CI peut exécuter plusieurs commandes dans script, chacune d'entre elles devant démarrer par un '-' (élément dans une liste de 'scripts').<br />
<br />
Attention: il n'est pas possible d'utiliser '''cd''' pour changer de répertoire, il faut utiliser '''pushd''' (déplacement dans un dossier) et '''popd''' (retour au dossier précédent) à la place.<br />
<br />
Une fois ce fichier de configuration '''pushé''', Travis-CI se mettra en route dès le prochain '''push'''.<br />
<br />
===Maven===<br />
[http://maven.apache.org/download.cgi Changer et installer Maven 3].<br />
<br />
<pre><br />
mvn -version<br />
</pre><br />
<br />
Créer '''cron4j-mvn''' (layout + pom.xml) en réorganisant les sources de cron4j-original. Pour cela, vous utiliserez préalablement un [https://maven.apache.org/guides/introduction/introduction-to-archetypes.html archetype Maven] ''simple'' ou ''quickstart''. (la version de cron4j est la 2.5.5).<br />
<br />
Modifier .travis.yml pour ''mvn -DskipTests=true clean install'' (Commit/Push)<br />
<br />
<br />
===Tests Unitaires avec JUnit 4===<br />
Survoller le tutoriel [http://www.vogella.com/tutorials/JUnit/article.html Unit Testing with JUnit]<br />
<br />
Ajouter le test unitaire suivant au layout du projet<br />
<br />
<pre><br />
package it.sauronsoftware;<br />
<br />
import it.sauronsoftware.cron4j.SchedulingPattern;<br />
import it.sauronsoftware.cron4j.InvalidPatternException;<br />
<br />
import static org.junit.Assert.assertEquals;<br />
import static org.junit.Assert.assertTrue;<br />
<br />
import org.junit.AfterClass;<br />
import org.junit.BeforeClass;<br />
import org.junit.Test;<br />
<br />
public class SchedulingPatternTest {<br />
<br />
@BeforeClass<br />
public static void testSetup() {<br />
}<br />
<br />
@AfterClass<br />
public static void testCleanup() {<br />
// Teardown for data used by the unit tests<br />
}<br />
<br />
@Test(expected = InvalidPatternException.class)<br />
public void testExceptionIsThrown() {<br />
SchedulingPattern sp = new SchedulingPattern("0 5 * *");<br />
}<br />
<br />
@Test<br />
public void testPattern() {<br />
String pattern;<br />
pattern="0 5 * * *|8 10 * * *|22 17 * * *";<br />
assertTrue(pattern + "is correct", SchedulingPattern.validate(pattern));<br />
pattern="0 5 * *";<br />
assertTrue(pattern + "is correct", SchedulingPattern.validate(pattern));<br />
}<br />
}<br />
</pre><br />
<br />
<br />
Rechercher la dépendance JUnit 4 dans [http://search.maven.org/#search|ga|1|JUnit Maven Central]<br />
<br />
Ajouter la dépendance JUnit 4 au pom.xml<br />
<br />
<br />
<br />
Lancer le build mvn test<br />
<br />
Modifier '''.travis.yml''' pour ''mvn clean test'' (Commit/Push)<br />
<br />
Regarder votre mail box.<br />
<br />
Naviguer sur http://travis-ci.org pour vérifier les builds effectués.<br />
<br />
Créer des tests unitaires du i.s.c.CronParser<br />
<br />
===Git (suite)===<br />
# Forker le projet '''cron4j-mvn''' d'un autre binome (ie l'origine)<br />
# Ajouter une bannière de licence dans le pom.xml<br />
# Lancer mvn clean install (bonne pratique)<br />
# Commiter<br />
# Faire un Push request vers l'origine<br />
<br />
===Contrôle Continu===<br />
Ajoutez au pom.xml le plugin Covertura pour la couverture de code.<br />
<br />
Répondez aux questions : ''Mais qu'est ce que la couverture de code ? En quoi c'est utile ?''<br />
<br />
Ajoutez au pom.xml les plugins pour la gestion du site et des rapports (Javadoc, tests unitaires, tags list (FIXME, TODO, ...), ...): http://maven.apache.org/plugins/maven-site-plugin/ et d'autres.<br />
<br />
Pour la prochaine séance, regardez les exemples d'utilisation de cron4j dans cron4j-original/examples<br />
<br />
===Bonus Track===<br />
<br />
====Clone SVN -> Git====<br />
<br />
Source: http://www.yterium.net/Migrer-un-projet-SVN-vers-GIT<br />
<br />
<syntaxhighlight lang="bash"><br />
# Cloner le dépôt SVN en dépôt Git (conservation historique)<br />
$ git svn clone svn://svn.code.sf.net/p/cron4j/code/trunk cron4j-original<br />
$ cd cron4j-original<br />
# Test compilation<br />
$ ant jar<br />
$ cd ..<br />
</syntaxhighlight><br />
<br />
====Préparation TAGL====<br />
<br />
<syntaxhighlight lang="bash"><br />
# Clone du dépôt TAGL<br />
$ git clone git@github.com:donsez/tagl.git<br />
$ cd tagl<br />
# "Fetch" du dépôt local cloné précédemment<br />
$ git fetch file://$(pwd)/../cron4j-original<br />
# Fusion de ce qui vient d'être fetché<br />
$ git merge FETCH_HEAD<br />
# Envoi sur le serveur<br />
$ git push<br />
</syntaxhighlight><br />
<br />
<br />
====Cherry-picking: reprise des modifications d'un collègue====<br />
<br />
On considère que:<br />
<br />
* votre dépôt Git distant est à l'adresse URL_DEPOT<br />
* votre collègue a un dépôt Git à l'adresse URL_COLLEGUE<br />
<br />
<br />
<syntaxhighlight lang="bash"><br />
# Dossier temporaire<br />
cd /tmp<br />
<br />
# Clone de votre dépôt<br />
git clone URL_DEPOT mon_depot<br />
<br />
# Déplacement dans votre dépôt<br />
cd mon_depot<br />
<br />
# Définition du dépôt distant<br />
git remote add collegue URL_COLLEGUE<br />
<br />
# Récupération des infos du dépôt du collègue<br />
git fetch collegue<br />
<br />
# Maintenant, on peut voir les branches du collègue<br />
git branch -a<br />
<br />
# On peut fusionner avec une branche<br />
git merge collegue/master<br />
<br />
# Si vous avez des conflits, éditez les fichiers concernés,<br />
# et committez avec git commit<br />
<br />
# Push vers votre dépôt distant<br />
git push origin<br />
<br />
# Optionnel: supprimez la référence vers le dépôt du collègue<br />
git remote rm collegue<br />
</syntaxhighlight><br />
<br />
<br />
====Archetype webapp====<br />
L'archetype webapp (http://maven.apache.org/archetype/maven-archetype-bundles/maven-archetype-webapp/) permet de créer le squelette d'une webapp. Créez un simple webapp monsite en version 0.1.0. (add/commit/push). Vous pourrez tester cette webapp en ajoutant au pom.xml le [https://wiki.eclipse.org/Jetty/Feature/Jetty_Maven_Plugin plugin maven Jetty].<br />
<br />
<syntaxhighlight lang="bash"><br />
mvn -Djetty.port=9999 jetty:run<br />
</syntaxhighlight><br />
<br />
Naviguez sur http://localhost:9999/monsite<br />
<br />
====Scrum tools====<br />
Ces 3 services peuvent être couplé à votre dépôt GitHub pour votre gestion de projet agile avec [[Scrum]] :<br />
* http://www.acunote.com/<br />
* http://backlogtool.com/<br />
* http://www.scrumdo.com/<br />
<br />
L'activation se fait via ''Settings > Webhooks & Services > Configure services''.<br />
<br />
==Séance 2==<br />
AOP & AspectJ<br />
<br />
Ajouter le [http://mojo.codehaus.org/aspectj-maven-plugin/ plugin Maven pour AspectJ] au pom.xml<br />
<br />
Ajouter un aspect de trace à l'invocation des méthodes run() de l'interface java.lang.Runnable (uniquement pour les objets ''schedulé''s).<br />
<br />
===Contrôle continu===<br />
Compléter l'aspect de trace avec le positionnement du [http://docs.oracle.com/javase/7/docs/api/java/lang/ThreadLocal.html java.lang.ThreadLocal] pour passer 1) l'identifiant du job et 2) le compteur des appels de la méthode de l'objet.<br />
<br />
==Séance 3==<br />
@WIP<br />
<br />
Injection de dépendances avec [[Guice]] <br />
<br />
<br />
==Séance 4==<br />
[[Tutorial OSGi avec Apache Felix]]<br />
<br />
<br />
<br />
==Séance 5==<br />
Faire un projet PDE pour un bundle cron4j.gogo (indépendant de cron4j.bundle)<br />
<br />
Utilisation de https://eclipse.org/tycho/</div>Calmanthttps://air.imag.fr/index.php?title=TAGL/TP&diff=15636TAGL/TP2014-02-19T11:32:26Z<p>Calmant: /* GitHub & Travis-CI */</p>
<hr />
<div>Travaux pratiques de l'UE [[TAGL]].<br />
<br />
==Séance 1==<br />
===Git===<br />
<br />
Création d'un dépôt Git local<br />
<br />
====Méthode simple: init first====<br />
<br />
Via cette méthode, on crée un dépôt local, avec un répertoire de travail, puis on pousse ses modifications vers un dépôt "bare".<br />
Cette méthode est la plus simple, car on dispose immédiatement d'un répertoire de travail.<br />
<br />
<syntaxhighlight lang="bash"><br />
# Création d'un dépôt Git dans le dossier simple-repo<br />
git init simple-repo<br />
<br />
# Création d'un README<br />
cd simple-repo<br />
echo "Hello, World" > README<br />
<br />
# Ajout du versionnement du fichier README<br />
git add README<br />
<br />
# Commit<br />
git commit<br />
</syntaxhighlight><br />
<br />
À ce niveau, on a un dépôt Git complètement fonctionnel.<br />
Cependant, il est intéressant de pousser ses modifications vers un autre dépôt, sur une autre machine.<br />
On va donc créer un dépôt bare sur une autre machine (ou autre dossier pour l'exemple)<br />
<br />
<syntaxhighlight lang="bash"><br />
git init --bare server-repo<br />
</syntaxhighlight><br />
<br />
On considère que l'URL pour accéder à ce dépôt est URL_REPO.<br />
On va d'abord ajouter ce dépôt serveur à la liste des dépôts connu-repos de votre dépôt local.<br />
Étant donné qu'il s'agit du dépôt "principal" à utiliser, on l'appellera //origin//, par convention.<br />
<br />
<syntaxhighlight lang="bash"><br />
git remote add origin URL_REPO<br />
# Récupération de ses informations<br />
git fetch origin<br />
</syntaxhighlight><br />
<br />
Ce serveur distant est "vide": il n'a aucune branche. On va donc enregistrer notre branche sur le serveur<br />
<br />
<syntaxhighlight lang="bash"><br />
git push origin master<br />
</syntaxhighlight><br />
<br />
À partir de cette commande, la branche locale //master// sera liée à la branche distante //origin/master//.<br />
Lors des prochaines commandes ''git push'', grâce à cette liaison, tous les commits sur la branche locale //master// seront poussées sur le serveur distant.<br />
<br />
====Méthode moins simple: bare first====<br />
<br />
Si on commence dans par le serveur "vide", il faudra le cloner au lieu de le définir comme un dépôt distant.<br />
<br />
<syntaxhighlight lang="bash"><br />
# Création du dépôt vide<br />
git init --bare server-repo<br />
</syntaxhighlight><br />
<br />
On considère que ce dépôt est accessible à l'URL URL_REPO<br />
<br />
<syntaxhighlight lang="bash"><br />
# Clonage du dépôt<br />
git clone URL_REPO clone-repo<br />
</syntaxhighlight><br />
<br />
Un avertissement indique que l'on clone un dépôt vide: le dépôt local à donc une branche master, mais elle n'est pas liée au dépôt distant, car celui-ci n'a aucune branche.<br />
Le dépôt distant est automatiquement appelé //origin//.<br />
<br />
<syntaxhighlight lang="bash"><br />
# Commit dans le dépôt local<br />
cd clone-repo<br />
echo hello > readme.rst<br />
git add readme.rst<br />
git commit et ses dépendances<br />
</syntaxhighlight><br />
<br />
Comme dans la méthode simple, il faut pousser la branche master vers le dépôt distant:<br />
<br />
<syntaxhighlight lang="bash"><br />
git push origin master<br />
</syntaxhighlight><br />
<br />
===De l'importance des README===<br />
<br />
Il est très important d'avoir au moins 2 fichiers dans votre dépôt Git:<br />
<br />
* LICENSE: contenant le texte **complet** de la licence de votre projet<br />
* README: décrivant votre projet et comment l'utiliser. Ce fichier doit rappeler le nom de la licence de votre projet<br />
<br />
Il est aussi recommandé d'avoir les fichiers suivants:<br />
<br />
* AUTHORS: contenant la liste des noms/pseudos et e-mails des auteurs de commits ou de code inclus dans ce projet<br />
* INSTALL: contenant la liste des dépendances de ce projet et des commandes à utiliser pour le compiler et l'installer<br />
<br />
Les fichiers LICENSE sont des fichiers textes bruts.<br />
Les autres fichiers sont généralement dans un format offrant un peu plus de lisibilté, par exemple dans les formats [http://daringfireball.net/projects/markdown/ Markdown] (.md) ou [http://docutils.sourceforge.net/rst.html reStructuredText] (.rst)<br />
<br />
Un plug-in existe pour éditer des fichier reStructuredText dans Eclipse: ReST Editor, disponible sur le [https://marketplace.eclipse.org/content/rest-editor Marketplace Eclipse]<br />
<br />
===GitHub & Travis-CI===<br />
<br />
Travis-CI est un service permettant d'exécuter un script dans une machine virtuelle Ubuntu dès que vous effectuez un push sur un de vos dépôts GitHub.<br />
L'intérêt est de savoir si la version d'un projet que vous avez rendu publique peut être compilée et si ses tests passent.<br />
<br />
Pour utiliser Travis:<br />
<br />
#. Créez compte individuel sur GitHub https://github.com<br />
#. ''Fork''ez le projet TAGL '''cron4j''' depuis https://github.com/donsez/tagl<br />
#. Ajoutez un collaborateur (i.e. votre binôme) au projet ''forké'', via les paramètres (//settings//) de ce projet<br />
#. Pour l'exemple, activez le service (ou hook) //Email// depuis les paramètres du dépôt: à chaque fois que vous ou un de vos collaborateurs ferra un ''git push'', vous recevrez une notification par mail.<br />
#. Activez le service Travis-CI: identifiez-vous (//sign in//) sur https://travis-ci.org/ avec votre compte GitHub<br />
<br />
''Commit/Push'' '''.travis.yml''' pour Ant:<br />
<br />
<pre><br />
language: java<br />
<br />
jdk:<br />
- oraclejdk7<br />
- openjdk6<br />
- openjdk7<br />
<br />
script:<br />
- pushd cron4j-original && ant rel && popd<br />
</pre><br />
<br />
===Maven===<br />
[http://maven.apache.org/download.cgi Changer et installer Maven 3].<br />
<br />
<pre><br />
mvn -version<br />
</pre><br />
<br />
Créer '''cron4j-mvn''' (layout + pom.xml) en réorganisant les sources de cron4j-original. Pour cela, vous utiliserez préalablement un [https://maven.apache.org/guides/introduction/introduction-to-archetypes.html archetype Maven] ''simple'' ou ''quickstart''. (la version de cron4j est la 2.5.5).<br />
<br />
Modifier .travis.yml pour ''mvn -DskipTests=true clean install'' (Commit/Push)<br />
<br />
<br />
===Tests Unitaires avec JUnit 4===<br />
Survoller le tutoriel [http://www.vogella.com/tutorials/JUnit/article.html Unit Testing with JUnit]<br />
<br />
Ajouter le test unitaire suivant au layout du projet<br />
<br />
<pre><br />
package it.sauronsoftware;<br />
<br />
import it.sauronsoftware.cron4j.SchedulingPattern;<br />
import it.sauronsoftware.cron4j.InvalidPatternException;<br />
<br />
import static org.junit.Assert.assertEquals;<br />
import static org.junit.Assert.assertTrue;<br />
<br />
import org.junit.AfterClass;<br />
import org.junit.BeforeClass;<br />
import org.junit.Test;<br />
<br />
public class SchedulingPatternTest {<br />
<br />
@BeforeClass<br />
public static void testSetup() {<br />
}<br />
<br />
@AfterClass<br />
public static void testCleanup() {<br />
// Teardown for data used by the unit tests<br />
}<br />
<br />
@Test(expected = InvalidPatternException.class)<br />
public void testExceptionIsThrown() {<br />
SchedulingPattern sp = new SchedulingPattern("0 5 * *");<br />
}<br />
<br />
@Test<br />
public void testPattern() {<br />
String pattern;<br />
pattern="0 5 * * *|8 10 * * *|22 17 * * *";<br />
assertTrue(pattern + "is correct", SchedulingPattern.validate(pattern));<br />
pattern="0 5 * *";<br />
assertTrue(pattern + "is correct", SchedulingPattern.validate(pattern));<br />
}<br />
}<br />
</pre><br />
<br />
<br />
Rechercher la dépendance JUnit 4 dans [http://search.maven.org/#search|ga|1|JUnit Maven Central]<br />
<br />
Ajouter la dépendance JUnit 4 au pom.xml<br />
<br />
<br />
<br />
Lancer le build mvn test<br />
<br />
Modifier '''.travis.yml''' pour ''mvn clean test'' (Commit/Push)<br />
<br />
Regarder votre mail box.<br />
<br />
Naviguer sur http://travis-ci.org pour vérifier les builds effectués.<br />
<br />
Créer des tests unitaires du i.s.c.CronParser<br />
<br />
===Git (suite)===<br />
# Forker le projet '''cron4j-mvn''' d'un autre binome (ie l'origine)<br />
# Ajouter une bannière de licence dans le pom.xml<br />
# Lancer mvn clean install (bonne pratique)<br />
# Commiter<br />
# Faire un Push request vers l'origine<br />
<br />
===Contrôle Continu===<br />
Ajoutez au pom.xml le plugin Covertura pour la couverture de code.<br />
<br />
Répondez aux questions : ''Mais qu'est ce que la couverture de code ? En quoi c'est utile ?''<br />
<br />
Ajoutez au pom.xml les plugins pour la gestion du site et des rapports (Javadoc, tests unitaires, tags list (FIXME, TODO, ...), ...): http://maven.apache.org/plugins/maven-site-plugin/ et d'autres.<br />
<br />
Pour la prochaine séance, regardez les exemples d'utilisation de cron4j dans cron4j-original/examples<br />
<br />
===Bonus Track===<br />
<br />
====Clone SVN -> Git====<br />
<br />
Source: http://www.yterium.net/Migrer-un-projet-SVN-vers-GIT<br />
<br />
<syntaxhighlight lang="bash"><br />
# Cloner le dépôt SVN en dépôt Git (conservation historique)<br />
$ git svn clone svn://svn.code.sf.net/p/cron4j/code/trunk cron4j-original<br />
$ cd cron4j-original<br />
# Test compilation<br />
$ ant jar<br />
$ cd ..<br />
</syntaxhighlight><br />
<br />
====Préparation TAGL====<br />
<br />
<syntaxhighlight lang="bash"><br />
# Clone du dépôt TAGL<br />
$ git clone git@github.com:donsez/tagl.git<br />
$ cd tagl<br />
# "Fetch" du dépôt local cloné précédemment<br />
$ git fetch file://$(pwd)/../cron4j-original<br />
# Fusion de ce qui vient d'être fetché<br />
$ git merge FETCH_HEAD<br />
# Envoi sur le serveur<br />
$ git push<br />
</syntaxhighlight><br />
<br />
<br />
====Cherry-picking: reprise des modifications d'un collègue====<br />
<br />
On considère que:<br />
<br />
* votre dépôt Git distant est à l'adresse URL_DEPOT<br />
* votre collègue a un dépôt Git à l'adresse URL_COLLEGUE<br />
<br />
<br />
<syntaxhighlight lang="bash"><br />
# Dossier temporaire<br />
cd /tmp<br />
<br />
# Clone de votre dépôt<br />
git clone URL_DEPOT mon_depot<br />
<br />
# Déplacement dans votre dépôt<br />
cd mon_depot<br />
<br />
# Définition du dépôt distant<br />
git remote add collegue URL_COLLEGUE<br />
<br />
# Récupération des infos du dépôt du collègue<br />
git fetch collegue<br />
<br />
# Maintenant, on peut voir les branches du collègue<br />
git branch -a<br />
<br />
# On peut fusionner avec une branche<br />
git merge collegue/master<br />
<br />
# Si vous avez des conflits, éditez les fichiers concernés,<br />
# et committez avec git commit<br />
<br />
# Push vers votre dépôt distant<br />
git push origin<br />
<br />
# Optionnel: supprimez la référence vers le dépôt du collègue<br />
git remote rm collegue<br />
</syntaxhighlight><br />
<br />
<br />
====Archetype webapp====<br />
L'archetype webapp (http://maven.apache.org/archetype/maven-archetype-bundles/maven-archetype-webapp/) permet de créer le squelette d'une webapp. Créez un simple webapp monsite en version 0.1.0. (add/commit/push). Vous pourrez tester cette webapp en ajoutant au pom.xml le [https://wiki.eclipse.org/Jetty/Feature/Jetty_Maven_Plugin plugin maven Jetty].<br />
<br />
<syntaxhighlight lang="bash"><br />
mvn -Djetty.port=9999 jetty:run<br />
</syntaxhighlight><br />
<br />
Naviguez sur http://localhost:9999/monsite<br />
<br />
====Scrum tools====<br />
Ces 3 services peuvent être couplé à votre dépôt GitHub pour votre gestion de projet agile avec [[Scrum]] :<br />
* http://www.acunote.com/<br />
* http://backlogtool.com/<br />
* http://www.scrumdo.com/<br />
<br />
L'activation se fait via ''Settings > Webhooks & Services > Configure services''.<br />
<br />
==Séance 2==<br />
AOP & AspectJ<br />
<br />
Ajouter le [http://mojo.codehaus.org/aspectj-maven-plugin/ plugin Maven pour AspectJ] au pom.xml<br />
<br />
Ajouter un aspect de trace à l'invocation des méthodes run() de l'interface java.lang.Runnable (uniquement pour les objets ''schedulé''s).<br />
<br />
===Contrôle continu===<br />
Compléter l'aspect de trace avec le positionnement du [http://docs.oracle.com/javase/7/docs/api/java/lang/ThreadLocal.html java.lang.ThreadLocal] pour passer 1) l'identifiant du job et 2) le compteur des appels de la méthode de l'objet.<br />
<br />
==Séance 3==<br />
@WIP<br />
<br />
Injection de dépendances avec [[Guice]] <br />
<br />
<br />
==Séance 4==<br />
[[Tutorial OSGi avec Apache Felix]]<br />
<br />
<br />
<br />
==Séance 5==<br />
Faire un projet PDE pour un bundle cron4j.gogo (indépendant de cron4j.bundle)<br />
<br />
Utilisation de https://eclipse.org/tycho/</div>Calmanthttps://air.imag.fr/index.php?title=TAGL/TP&diff=15635TAGL/TP2014-02-19T11:25:27Z<p>Calmant: /* Méthode moins simple: bare first */</p>
<hr />
<div>Travaux pratiques de l'UE [[TAGL]].<br />
<br />
==Séance 1==<br />
===Git===<br />
<br />
Création d'un dépôt Git local<br />
<br />
====Méthode simple: init first====<br />
<br />
Via cette méthode, on crée un dépôt local, avec un répertoire de travail, puis on pousse ses modifications vers un dépôt "bare".<br />
Cette méthode est la plus simple, car on dispose immédiatement d'un répertoire de travail.<br />
<br />
<syntaxhighlight lang="bash"><br />
# Création d'un dépôt Git dans le dossier simple-repo<br />
git init simple-repo<br />
<br />
# Création d'un README<br />
cd simple-repo<br />
echo "Hello, World" > README<br />
<br />
# Ajout du versionnement du fichier README<br />
git add README<br />
<br />
# Commit<br />
git commit<br />
</syntaxhighlight><br />
<br />
À ce niveau, on a un dépôt Git complètement fonctionnel.<br />
Cependant, il est intéressant de pousser ses modifications vers un autre dépôt, sur une autre machine.<br />
On va donc créer un dépôt bare sur une autre machine (ou autre dossier pour l'exemple)<br />
<br />
<syntaxhighlight lang="bash"><br />
git init --bare server-repo<br />
</syntaxhighlight><br />
<br />
On considère que l'URL pour accéder à ce dépôt est URL_REPO.<br />
On va d'abord ajouter ce dépôt serveur à la liste des dépôts connu-repos de votre dépôt local.<br />
Étant donné qu'il s'agit du dépôt "principal" à utiliser, on l'appellera //origin//, par convention.<br />
<br />
<syntaxhighlight lang="bash"><br />
git remote add origin URL_REPO<br />
# Récupération de ses informations<br />
git fetch origin<br />
</syntaxhighlight><br />
<br />
Ce serveur distant est "vide": il n'a aucune branche. On va donc enregistrer notre branche sur le serveur<br />
<br />
<syntaxhighlight lang="bash"><br />
git push origin master<br />
</syntaxhighlight><br />
<br />
À partir de cette commande, la branche locale //master// sera liée à la branche distante //origin/master//.<br />
Lors des prochaines commandes ''git push'', grâce à cette liaison, tous les commits sur la branche locale //master// seront poussées sur le serveur distant.<br />
<br />
====Méthode moins simple: bare first====<br />
<br />
Si on commence dans par le serveur "vide", il faudra le cloner au lieu de le définir comme un dépôt distant.<br />
<br />
<syntaxhighlight lang="bash"><br />
# Création du dépôt vide<br />
git init --bare server-repo<br />
</syntaxhighlight><br />
<br />
On considère que ce dépôt est accessible à l'URL URL_REPO<br />
<br />
<syntaxhighlight lang="bash"><br />
# Clonage du dépôt<br />
git clone URL_REPO clone-repo<br />
</syntaxhighlight><br />
<br />
Un avertissement indique que l'on clone un dépôt vide: le dépôt local à donc une branche master, mais elle n'est pas liée au dépôt distant, car celui-ci n'a aucune branche.<br />
Le dépôt distant est automatiquement appelé //origin//.<br />
<br />
<syntaxhighlight lang="bash"><br />
# Commit dans le dépôt local<br />
cd clone-repo<br />
echo hello > readme.rst<br />
git add readme.rst<br />
git commit et ses dépendances<br />
</syntaxhighlight><br />
<br />
Comme dans la méthode simple, il faut pousser la branche master vers le dépôt distant:<br />
<br />
<syntaxhighlight lang="bash"><br />
git push origin master<br />
</syntaxhighlight><br />
<br />
===De l'importance des README===<br />
<br />
Il est très important d'avoir au moins 2 fichiers dans votre dépôt Git:<br />
<br />
* LICENSE: contenant le texte **complet** de la licence de votre projet<br />
* README: décrivant votre projet et comment l'utiliser. Ce fichier doit rappeler le nom de la licence de votre projet<br />
<br />
Il est aussi recommandé d'avoir les fichiers suivants:<br />
<br />
* AUTHORS: contenant la liste des noms/pseudos et e-mails des auteurs de commits ou de code inclus dans ce projet<br />
* INSTALL: contenant la liste des dépendances de ce projet et des commandes à utiliser pour le compiler et l'installer<br />
<br />
Les fichiers LICENSE sont des fichiers textes bruts.<br />
Les autres fichiers sont généralement dans un format offrant un peu plus de lisibilté, par exemple dans les formats [http://daringfireball.net/projects/markdown/ Markdown] (.md) ou [http://docutils.sourceforge.net/rst.html reStructuredText] (.rst)<br />
<br />
Un plug-in existe pour éditer des fichier reStructuredText dans Eclipse: ReST Editor, disponible sur le [https://marketplace.eclipse.org/content/rest-editor Marketplace Eclipse]<br />
<br />
===GitHub & Travis-CI===<br />
Créer compte individuel sur GitHub https://github.com<br />
<br />
''Fork''er le projet TAGL '''cron4j''' depuis https://github.com/donsez/tagl<br />
<br />
Ajouter un collaborateur (ie votre binome) au projet ''forké''<br />
<br />
Activer le Email hook depuis les paramètres (settings) du dépôt.<br />
<br />
Activer le Travis-CI ''hook' depuis https://travis-ci.org/ (sign in avec le compte GitHub)<br />
<br />
''Commit/Push'' '''.travis.yml''' pour Ant:<br />
<br />
<pre><br />
language: java<br />
<br />
jdk:<br />
- oraclejdk7<br />
- openjdk6<br />
- openjdk7<br />
<br />
script:<br />
- pushd cron4j-original && ant rel && popd<br />
</pre><br />
<br />
===Maven===<br />
[http://maven.apache.org/download.cgi Changer et installer Maven 3].<br />
<br />
<pre><br />
mvn -version<br />
</pre><br />
<br />
Créer '''cron4j-mvn''' (layout + pom.xml) en réorganisant les sources de cron4j-original. Pour cela, vous utiliserez préalablement un [https://maven.apache.org/guides/introduction/introduction-to-archetypes.html archetype Maven] ''simple'' ou ''quickstart''. (la version de cron4j est la 2.5.5).<br />
<br />
Modifier .travis.yml pour ''mvn -DskipTests=true clean install'' (Commit/Push)<br />
<br />
<br />
===Tests Unitaires avec JUnit 4===<br />
Survoller le tutoriel [http://www.vogella.com/tutorials/JUnit/article.html Unit Testing with JUnit]<br />
<br />
Ajouter le test unitaire suivant au layout du projet<br />
<br />
<pre><br />
package it.sauronsoftware;<br />
<br />
import it.sauronsoftware.cron4j.SchedulingPattern;<br />
import it.sauronsoftware.cron4j.InvalidPatternException;<br />
<br />
import static org.junit.Assert.assertEquals;<br />
import static org.junit.Assert.assertTrue;<br />
<br />
import org.junit.AfterClass;<br />
import org.junit.BeforeClass;<br />
import org.junit.Test;<br />
<br />
public class SchedulingPatternTest {<br />
<br />
@BeforeClass<br />
public static void testSetup() {<br />
}<br />
<br />
@AfterClass<br />
public static void testCleanup() {<br />
// Teardown for data used by the unit tests<br />
}<br />
<br />
@Test(expected = InvalidPatternException.class)<br />
public void testExceptionIsThrown() {<br />
SchedulingPattern sp = new SchedulingPattern("0 5 * *");<br />
}<br />
<br />
@Test<br />
public void testPattern() {<br />
String pattern;<br />
pattern="0 5 * * *|8 10 * * *|22 17 * * *";<br />
assertTrue(pattern + "is correct", SchedulingPattern.validate(pattern));<br />
pattern="0 5 * *";<br />
assertTrue(pattern + "is correct", SchedulingPattern.validate(pattern));<br />
}<br />
}<br />
</pre><br />
<br />
<br />
Rechercher la dépendance JUnit 4 dans [http://search.maven.org/#search|ga|1|JUnit Maven Central]<br />
<br />
Ajouter la dépendance JUnit 4 au pom.xml<br />
<br />
<br />
<br />
Lancer le build mvn test<br />
<br />
Modifier '''.travis.yml''' pour ''mvn clean test'' (Commit/Push)<br />
<br />
Regarder votre mail box.<br />
<br />
Naviguer sur http://travis-ci.org pour vérifier les builds effectués.<br />
<br />
Créer des tests unitaires du i.s.c.CronParser<br />
<br />
===Git (suite)===<br />
# Forker le projet '''cron4j-mvn''' d'un autre binome (ie l'origine)<br />
# Ajouter une bannière de licence dans le pom.xml<br />
# Lancer mvn clean install (bonne pratique)<br />
# Commiter<br />
# Faire un Push request vers l'origine<br />
<br />
===Contrôle Continu===<br />
Ajoutez au pom.xml le plugin Covertura pour la couverture de code.<br />
<br />
Répondez aux questions : ''Mais qu'est ce que la couverture de code ? En quoi c'est utile ?''<br />
<br />
Ajoutez au pom.xml les plugins pour la gestion du site et des rapports (Javadoc, tests unitaires, tags list (FIXME, TODO, ...), ...): http://maven.apache.org/plugins/maven-site-plugin/ et d'autres.<br />
<br />
Pour la prochaine séance, regardez les exemples d'utilisation de cron4j dans cron4j-original/examples<br />
<br />
===Bonus Track===<br />
<br />
====Clone SVN -> Git====<br />
<br />
Source: http://www.yterium.net/Migrer-un-projet-SVN-vers-GIT<br />
<br />
<syntaxhighlight lang="bash"><br />
# Cloner le dépôt SVN en dépôt Git (conservation historique)<br />
$ git svn clone svn://svn.code.sf.net/p/cron4j/code/trunk cron4j-original<br />
$ cd cron4j-original<br />
# Test compilation<br />
$ ant jar<br />
$ cd ..<br />
</syntaxhighlight><br />
<br />
====Préparation TAGL====<br />
<br />
<syntaxhighlight lang="bash"><br />
# Clone du dépôt TAGL<br />
$ git clone git@github.com:donsez/tagl.git<br />
$ cd tagl<br />
# "Fetch" du dépôt local cloné précédemment<br />
$ git fetch file://$(pwd)/../cron4j-original<br />
# Fusion de ce qui vient d'être fetché<br />
$ git merge FETCH_HEAD<br />
# Envoi sur le serveur<br />
$ git push<br />
</syntaxhighlight><br />
<br />
<br />
====Cherry-picking: reprise des modifications d'un collègue====<br />
<br />
On considère que:<br />
<br />
* votre dépôt Git distant est à l'adresse URL_DEPOT<br />
* votre collègue a un dépôt Git à l'adresse URL_COLLEGUE<br />
<br />
<br />
<syntaxhighlight lang="bash"><br />
# Dossier temporaire<br />
cd /tmp<br />
<br />
# Clone de votre dépôt<br />
git clone URL_DEPOT mon_depot<br />
<br />
# Déplacement dans votre dépôt<br />
cd mon_depot<br />
<br />
# Définition du dépôt distant<br />
git remote add collegue URL_COLLEGUE<br />
<br />
# Récupération des infos du dépôt du collègue<br />
git fetch collegue<br />
<br />
# Maintenant, on peut voir les branches du collègue<br />
git branch -a<br />
<br />
# On peut fusionner avec une branche<br />
git merge collegue/master<br />
<br />
# Si vous avez des conflits, éditez les fichiers concernés,<br />
# et committez avec git commit<br />
<br />
# Push vers votre dépôt distant<br />
git push origin<br />
<br />
# Optionnel: supprimez la référence vers le dépôt du collègue<br />
git remote rm collegue<br />
</syntaxhighlight><br />
<br />
<br />
====Archetype webapp====<br />
L'archetype webapp (http://maven.apache.org/archetype/maven-archetype-bundles/maven-archetype-webapp/) permet de créer le squelette d'une webapp. Créez un simple webapp monsite en version 0.1.0. (add/commit/push). Vous pourrez tester cette webapp en ajoutant au pom.xml le [https://wiki.eclipse.org/Jetty/Feature/Jetty_Maven_Plugin plugin maven Jetty].<br />
<br />
<syntaxhighlight lang="bash"><br />
mvn -Djetty.port=9999 jetty:run<br />
</syntaxhighlight><br />
<br />
Naviguez sur http://localhost:9999/monsite<br />
<br />
====Scrum tools====<br />
Ces 3 services peuvent être couplé à votre dépôt GitHub pour votre gestion de projet agile avec [[Scrum]] :<br />
* http://www.acunote.com/<br />
* http://backlogtool.com/<br />
* http://www.scrumdo.com/<br />
<br />
L'activation se fait via ''Settings > Webhooks & Services > Configure services''.<br />
<br />
==Séance 2==<br />
AOP & AspectJ<br />
<br />
Ajouter le [http://mojo.codehaus.org/aspectj-maven-plugin/ plugin Maven pour AspectJ] au pom.xml<br />
<br />
Ajouter un aspect de trace à l'invocation des méthodes run() de l'interface java.lang.Runnable (uniquement pour les objets ''schedulé''s).<br />
<br />
===Contrôle continu===<br />
Compléter l'aspect de trace avec le positionnement du [http://docs.oracle.com/javase/7/docs/api/java/lang/ThreadLocal.html java.lang.ThreadLocal] pour passer 1) l'identifiant du job et 2) le compteur des appels de la méthode de l'objet.<br />
<br />
==Séance 3==<br />
@WIP<br />
<br />
Injection de dépendances avec [[Guice]] <br />
<br />
<br />
==Séance 4==<br />
[[Tutorial OSGi avec Apache Felix]]<br />
<br />
<br />
<br />
==Séance 5==<br />
Faire un projet PDE pour un bundle cron4j.gogo (indépendant de cron4j.bundle)<br />
<br />
Utilisation de https://eclipse.org/tycho/</div>Calmanthttps://air.imag.fr/index.php?title=TAGL/TP&diff=15634TAGL/TP2014-02-19T11:19:29Z<p>Calmant: /* Git */</p>
<hr />
<div>Travaux pratiques de l'UE [[TAGL]].<br />
<br />
==Séance 1==<br />
===Git===<br />
<br />
Création d'un dépôt Git local<br />
<br />
====Méthode simple: init first====<br />
<br />
Via cette méthode, on crée un dépôt local, avec un répertoire de travail, puis on pousse ses modifications vers un dépôt "bare".<br />
Cette méthode est la plus simple, car on dispose immédiatement d'un répertoire de travail.<br />
<br />
<syntaxhighlight lang="bash"><br />
# Création d'un dépôt Git dans le dossier simple-repo<br />
git init simple-repo<br />
<br />
# Création d'un README<br />
cd simple-repo<br />
echo "Hello, World" > README<br />
<br />
# Ajout du versionnement du fichier README<br />
git add README<br />
<br />
# Commit<br />
git commit<br />
</syntaxhighlight><br />
<br />
À ce niveau, on a un dépôt Git complètement fonctionnel.<br />
Cependant, il est intéressant de pousser ses modifications vers un autre dépôt, sur une autre machine.<br />
On va donc créer un dépôt bare sur une autre machine (ou autre dossier pour l'exemple)<br />
<br />
<syntaxhighlight lang="bash"><br />
git init --bare server-repo<br />
</syntaxhighlight><br />
<br />
On considère que l'URL pour accéder à ce dépôt est URL_REPO.<br />
On va d'abord ajouter ce dépôt serveur à la liste des dépôts connu-repos de votre dépôt local.<br />
Étant donné qu'il s'agit du dépôt "principal" à utiliser, on l'appellera //origin//, par convention.<br />
<br />
<syntaxhighlight lang="bash"><br />
git remote add origin URL_REPO<br />
# Récupération de ses informations<br />
git fetch origin<br />
</syntaxhighlight><br />
<br />
Ce serveur distant est "vide": il n'a aucune branche. On va donc enregistrer notre branche sur le serveur<br />
<br />
<syntaxhighlight lang="bash"><br />
git push origin master<br />
</syntaxhighlight><br />
<br />
À partir de cette commande, la branche locale //master// sera liée à la branche distante //origin/master//.<br />
Lors des prochaines commandes ''git push'', grâce à cette liaison, tous les commits sur la branche locale //master// seront poussées sur le serveur distant.<br />
<br />
====Méthode moins simple: bare first====<br />
<br />
Si on commence dans par le serveur "vide", il faudra le cloner au lieu de le définir comme un dépôt distant.<br />
<br />
<syntaxhighlight lang="bash"><br />
# Création du dépôt vide<br />
git init --bare server-repo<br />
</syntaxhighlight><br />
<br />
On considère que ce dépôt est accessible à l'URL URL_REPO<br />
<br />
<syntaxhighlight lang="bash"><br />
# Clonage du dépôt<br />
git clone URL_REPO clone-repo<br />
</syntaxhighlight><br />
<br />
Un avertissement indique que l'on clone un dépôt vide: le dépôt local à donc une branche master, mais elle n'est pas liée au dépôt distant, car celui-ci n'a aucune branche.<br />
Le dépôt distant est automatiquement appelé //origin//.<br />
<br />
<syntaxhighlight lang="bash"><br />
# Commit dans le dépôt local<br />
cd clone-repo<br />
echo hello > readme.rst<br />
git add readme.rst<br />
git commit<br />
</syntaxhighlight><br />
<br />
Comme dans la méthode simple, il faut pousser la branche master vers le dépôt distant:<br />
<br />
<syntaxhighlight lang="bash"><br />
git push origin master<br />
</syntaxhighlight><br />
<br />
En parallèle : Installer dans votre Eclipse le plugin ReST Editor depuis le [https://marketplace.eclipse.org/content/rest-editor Marketplace Eclipse]<br />
<br />
===GitHub & Travis-CI===<br />
Créer compte individuel sur GitHub https://github.com<br />
<br />
''Fork''er le projet TAGL '''cron4j''' depuis https://github.com/donsez/tagl<br />
<br />
Ajouter un collaborateur (ie votre binome) au projet ''forké''<br />
<br />
Activer le Email hook depuis les paramètres (settings) du dépôt.<br />
<br />
Activer le Travis-CI ''hook' depuis https://travis-ci.org/ (sign in avec le compte GitHub)<br />
<br />
''Commit/Push'' '''.travis.yml''' pour Ant:<br />
<br />
<pre><br />
language: java<br />
<br />
jdk:<br />
- oraclejdk7<br />
- openjdk6<br />
- openjdk7<br />
<br />
script:<br />
- pushd cron4j-original && ant rel && popd<br />
</pre><br />
<br />
===Maven===<br />
[http://maven.apache.org/download.cgi Changer et installer Maven 3].<br />
<br />
<pre><br />
mvn -version<br />
</pre><br />
<br />
Créer '''cron4j-mvn''' (layout + pom.xml) en réorganisant les sources de cron4j-original. Pour cela, vous utiliserez préalablement un [https://maven.apache.org/guides/introduction/introduction-to-archetypes.html archetype Maven] ''simple'' ou ''quickstart''. (la version de cron4j est la 2.5.5).<br />
<br />
Modifier .travis.yml pour ''mvn -DskipTests=true clean install'' (Commit/Push)<br />
<br />
<br />
===Tests Unitaires avec JUnit 4===<br />
Survoller le tutoriel [http://www.vogella.com/tutorials/JUnit/article.html Unit Testing with JUnit]<br />
<br />
Ajouter le test unitaire suivant au layout du projet<br />
<br />
<pre><br />
package it.sauronsoftware;<br />
<br />
import it.sauronsoftware.cron4j.SchedulingPattern;<br />
import it.sauronsoftware.cron4j.InvalidPatternException;<br />
<br />
import static org.junit.Assert.assertEquals;<br />
import static org.junit.Assert.assertTrue;<br />
<br />
import org.junit.AfterClass;<br />
import org.junit.BeforeClass;<br />
import org.junit.Test;<br />
<br />
public class SchedulingPatternTest {<br />
<br />
@BeforeClass<br />
public static void testSetup() {<br />
}<br />
<br />
@AfterClass<br />
public static void testCleanup() {<br />
// Teardown for data used by the unit tests<br />
}<br />
<br />
@Test(expected = InvalidPatternException.class)<br />
public void testExceptionIsThrown() {<br />
SchedulingPattern sp = new SchedulingPattern("0 5 * *");<br />
}<br />
<br />
@Test<br />
public void testPattern() {<br />
String pattern;<br />
pattern="0 5 * * *|8 10 * * *|22 17 * * *";<br />
assertTrue(pattern + "is correct", SchedulingPattern.validate(pattern));<br />
pattern="0 5 * *";<br />
assertTrue(pattern + "is correct", SchedulingPattern.validate(pattern));<br />
}<br />
}<br />
</pre><br />
<br />
<br />
Rechercher la dépendance JUnit 4 dans [http://search.maven.org/#search|ga|1|JUnit Maven Central]<br />
<br />
Ajouter la dépendance JUnit 4 au pom.xml<br />
<br />
<br />
<br />
Lancer le build mvn test<br />
<br />
Modifier '''.travis.yml''' pour ''mvn clean test'' (Commit/Push)<br />
<br />
Regarder votre mail box.<br />
<br />
Naviguer sur http://travis-ci.org pour vérifier les builds effectués.<br />
<br />
Créer des tests unitaires du i.s.c.CronParser<br />
<br />
===Git (suite)===<br />
# Forker le projet '''cron4j-mvn''' d'un autre binome (ie l'origine)<br />
# Ajouter une bannière de licence dans le pom.xml<br />
# Lancer mvn clean install (bonne pratique)<br />
# Commiter<br />
# Faire un Push request vers l'origine<br />
<br />
===Contrôle Continu===<br />
Ajoutez au pom.xml le plugin Covertura pour la couverture de code.<br />
<br />
Répondez aux questions : ''Mais qu'est ce que la couverture de code ? En quoi c'est utile ?''<br />
<br />
Ajoutez au pom.xml les plugins pour la gestion du site et des rapports (Javadoc, tests unitaires, tags list (FIXME, TODO, ...), ...): http://maven.apache.org/plugins/maven-site-plugin/ et d'autres.<br />
<br />
Pour la prochaine séance, regardez les exemples d'utilisation de cron4j dans cron4j-original/examples<br />
<br />
===Bonus Track===<br />
<br />
====Clone SVN -> Git====<br />
<br />
Source: http://www.yterium.net/Migrer-un-projet-SVN-vers-GIT<br />
<br />
<syntaxhighlight lang="bash"><br />
# Cloner le dépôt SVN en dépôt Git (conservation historique)<br />
$ git svn clone svn://svn.code.sf.net/p/cron4j/code/trunk cron4j-original<br />
$ cd cron4j-original<br />
# Test compilation<br />
$ ant jar<br />
$ cd ..<br />
</syntaxhighlight><br />
<br />
====Préparation TAGL====<br />
<br />
<syntaxhighlight lang="bash"><br />
# Clone du dépôt TAGL<br />
$ git clone git@github.com:donsez/tagl.git<br />
$ cd tagl<br />
# "Fetch" du dépôt local cloné précédemment<br />
$ git fetch file://$(pwd)/../cron4j-original<br />
# Fusion de ce qui vient d'être fetché<br />
$ git merge FETCH_HEAD<br />
# Envoi sur le serveur<br />
$ git push<br />
</syntaxhighlight><br />
<br />
<br />
====Cherry-picking: reprise des modifications d'un collègue====<br />
<br />
On considère que:<br />
<br />
* votre dépôt Git distant est à l'adresse URL_DEPOT<br />
* votre collègue a un dépôt Git à l'adresse URL_COLLEGUE<br />
<br />
<br />
<syntaxhighlight lang="bash"><br />
# Dossier temporaire<br />
cd /tmp<br />
<br />
# Clone de votre dépôt<br />
git clone URL_DEPOT mon_depot<br />
<br />
# Déplacement dans votre dépôt<br />
cd mon_depot<br />
<br />
# Définition du dépôt distant<br />
git remote add collegue URL_COLLEGUE<br />
<br />
# Récupération des infos du dépôt du collègue<br />
git fetch collegue<br />
<br />
# Maintenant, on peut voir les branches du collègue<br />
git branch -a<br />
<br />
# On peut fusionner avec une branche<br />
git merge collegue/master<br />
<br />
# Si vous avez des conflits, éditez les fichiers concernés,<br />
# et committez avec git commit<br />
<br />
# Push vers votre dépôt distant<br />
git push origin<br />
<br />
# Optionnel: supprimez la référence vers le dépôt du collègue<br />
git remote rm collegue<br />
</syntaxhighlight><br />
<br />
<br />
====Archetype webapp====<br />
L'archetype webapp (http://maven.apache.org/archetype/maven-archetype-bundles/maven-archetype-webapp/) permet de créer le squelette d'une webapp. Créez un simple webapp monsite en version 0.1.0. (add/commit/push). Vous pourrez tester cette webapp en ajoutant au pom.xml le [https://wiki.eclipse.org/Jetty/Feature/Jetty_Maven_Plugin plugin maven Jetty].<br />
<br />
<syntaxhighlight lang="bash"><br />
mvn -Djetty.port=9999 jetty:run<br />
</syntaxhighlight><br />
<br />
Naviguez sur http://localhost:9999/monsite<br />
<br />
====Scrum tools====<br />
Ces 3 services peuvent être couplé à votre dépôt GitHub pour votre gestion de projet agile avec [[Scrum]] :<br />
* http://www.acunote.com/<br />
* http://backlogtool.com/<br />
* http://www.scrumdo.com/<br />
<br />
L'activation se fait via ''Settings > Webhooks & Services > Configure services''.<br />
<br />
==Séance 2==<br />
AOP & AspectJ<br />
<br />
Ajouter le [http://mojo.codehaus.org/aspectj-maven-plugin/ plugin Maven pour AspectJ] au pom.xml<br />
<br />
Ajouter un aspect de trace à l'invocation des méthodes run() de l'interface java.lang.Runnable (uniquement pour les objets ''schedulé''s).<br />
<br />
===Contrôle continu===<br />
Compléter l'aspect de trace avec le positionnement du [http://docs.oracle.com/javase/7/docs/api/java/lang/ThreadLocal.html java.lang.ThreadLocal] pour passer 1) l'identifiant du job et 2) le compteur des appels de la méthode de l'objet.<br />
<br />
==Séance 3==<br />
@WIP<br />
<br />
Injection de dépendances avec [[Guice]] <br />
<br />
<br />
==Séance 4==<br />
[[Tutorial OSGi avec Apache Felix]]<br />
<br />
<br />
<br />
==Séance 5==<br />
Faire un projet PDE pour un bundle cron4j.gogo (indépendant de cron4j.bundle)<br />
<br />
Utilisation de https://eclipse.org/tycho/</div>Calmanthttps://air.imag.fr/index.php?title=TAGL/TP&diff=15633TAGL/TP2014-02-19T11:03:04Z<p>Calmant: /* Cherry-picking: reprise des modifications d'un collègue */</p>
<hr />
<div>Travaux pratiques de l'UE [[TAGL]].<br />
<br />
==Séance 1==<br />
===Git===<br />
Créer un dépôt Git local (bare)<br />
<pre><br />
mkdir tagl<br />
cd tagl<br />
mkdir testgit<br />
cd testgit<br />
git init --bare<br />
cd ..<br />
git clone testgit testgit-work<br />
cd testgit-work<br />
echo hello > readme.rst<br />
git add readme.rst<br />
git commit<br />
git push origin master<br />
</pre><br />
<br />
En parallèle : Installer dans votre Eclipse le plugin ReST Editor depuis le [https://marketplace.eclipse.org/content/rest-editor Marketplace Eclipse]<br />
<br />
===GitHub & Travis-CI===<br />
Créer compte individuel sur GitHub https://github.com<br />
<br />
''Fork''er le projet TAGL '''cron4j''' depuis https://github.com/donsez/tagl<br />
<br />
Ajouter un collaborateur (ie votre binome) au projet ''forké''<br />
<br />
Activer le Email hook depuis les paramètres (settings) du dépôt.<br />
<br />
Activer le Travis-CI ''hook' depuis https://travis-ci.org/ (sign in avec le compte GitHub)<br />
<br />
''Commit/Push'' '''.travis.yml''' pour Ant:<br />
<br />
<pre><br />
language: java<br />
<br />
jdk:<br />
- oraclejdk7<br />
- openjdk6<br />
- openjdk7<br />
<br />
script:<br />
- pushd cron4j-original && ant rel && popd<br />
</pre><br />
<br />
===Maven===<br />
[http://maven.apache.org/download.cgi Changer et installer Maven 3].<br />
<br />
<pre><br />
mvn -version<br />
</pre><br />
<br />
Créer '''cron4j-mvn''' (layout + pom.xml) en réorganisant les sources de cron4j-original. Pour cela, vous utiliserez préalablement un [https://maven.apache.org/guides/introduction/introduction-to-archetypes.html archetype Maven] ''simple'' ou ''quickstart''. (la version de cron4j est la 2.5.5).<br />
<br />
Modifier .travis.yml pour ''mvn -DskipTests=true clean install'' (Commit/Push)<br />
<br />
<br />
===Tests Unitaires avec JUnit 4===<br />
Survoller le tutoriel [http://www.vogella.com/tutorials/JUnit/article.html Unit Testing with JUnit]<br />
<br />
Ajouter le test unitaire suivant au layout du projet<br />
<br />
<pre><br />
package it.sauronsoftware;<br />
<br />
import it.sauronsoftware.cron4j.SchedulingPattern;<br />
import it.sauronsoftware.cron4j.InvalidPatternException;<br />
<br />
import static org.junit.Assert.assertEquals;<br />
import static org.junit.Assert.assertTrue;<br />
<br />
import org.junit.AfterClass;<br />
import org.junit.BeforeClass;<br />
import org.junit.Test;<br />
<br />
public class SchedulingPatternTest {<br />
<br />
@BeforeClass<br />
public static void testSetup() {<br />
}<br />
<br />
@AfterClass<br />
public static void testCleanup() {<br />
// Teardown for data used by the unit tests<br />
}<br />
<br />
@Test(expected = InvalidPatternException.class)<br />
public void testExceptionIsThrown() {<br />
SchedulingPattern sp = new SchedulingPattern("0 5 * *");<br />
}<br />
<br />
@Test<br />
public void testPattern() {<br />
String pattern;<br />
pattern="0 5 * * *|8 10 * * *|22 17 * * *";<br />
assertTrue(pattern + "is correct", SchedulingPattern.validate(pattern));<br />
pattern="0 5 * *";<br />
assertTrue(pattern + "is correct", SchedulingPattern.validate(pattern));<br />
}<br />
}<br />
</pre><br />
<br />
<br />
Rechercher la dépendance JUnit 4 dans [http://search.maven.org/#search|ga|1|JUnit Maven Central]<br />
<br />
Ajouter la dépendance JUnit 4 au pom.xml<br />
<br />
<br />
<br />
Lancer le build mvn test<br />
<br />
Modifier '''.travis.yml''' pour ''mvn clean test'' (Commit/Push)<br />
<br />
Regarder votre mail box.<br />
<br />
Naviguer sur http://travis-ci.org pour vérifier les builds effectués.<br />
<br />
Créer des tests unitaires du i.s.c.CronParser<br />
<br />
===Git (suite)===<br />
# Forker le projet '''cron4j-mvn''' d'un autre binome (ie l'origine)<br />
# Ajouter une bannière de licence dans le pom.xml<br />
# Lancer mvn clean install (bonne pratique)<br />
# Commiter<br />
# Faire un Push request vers l'origine<br />
<br />
===Contrôle Continu===<br />
Ajoutez au pom.xml le plugin Covertura pour la couverture de code.<br />
<br />
Répondez aux questions : ''Mais qu'est ce que la couverture de code ? En quoi c'est utile ?''<br />
<br />
Ajoutez au pom.xml les plugins pour la gestion du site et des rapports (Javadoc, tests unitaires, tags list (FIXME, TODO, ...), ...): http://maven.apache.org/plugins/maven-site-plugin/ et d'autres.<br />
<br />
Pour la prochaine séance, regardez les exemples d'utilisation de cron4j dans cron4j-original/examples<br />
<br />
===Bonus Track===<br />
<br />
====Clone SVN -> Git====<br />
<br />
Source: http://www.yterium.net/Migrer-un-projet-SVN-vers-GIT<br />
<br />
<syntaxhighlight lang="bash"><br />
# Cloner le dépôt SVN en dépôt Git (conservation historique)<br />
$ git svn clone svn://svn.code.sf.net/p/cron4j/code/trunk cron4j-original<br />
$ cd cron4j-original<br />
# Test compilation<br />
$ ant jar<br />
$ cd ..<br />
</syntaxhighlight><br />
<br />
====Préparation TAGL====<br />
<br />
<syntaxhighlight lang="bash"><br />
# Clone du dépôt TAGL<br />
$ git clone git@github.com:donsez/tagl.git<br />
$ cd tagl<br />
# "Fetch" du dépôt local cloné précédemment<br />
$ git fetch file://$(pwd)/../cron4j-original<br />
# Fusion de ce qui vient d'être fetché<br />
$ git merge FETCH_HEAD<br />
# Envoi sur le serveur<br />
$ git push<br />
</syntaxhighlight><br />
<br />
<br />
====Cherry-picking: reprise des modifications d'un collègue====<br />
<br />
On considère que:<br />
<br />
* votre dépôt Git distant est à l'adresse URL_DEPOT<br />
* votre collègue a un dépôt Git à l'adresse URL_COLLEGUE<br />
<br />
<br />
<syntaxhighlight lang="bash"><br />
# Dossier temporaire<br />
cd /tmp<br />
<br />
# Clone de votre dépôt<br />
git clone URL_DEPOT mon_depot<br />
<br />
# Déplacement dans votre dépôt<br />
cd mon_depot<br />
<br />
# Définition du dépôt distant<br />
git remote add collegue URL_COLLEGUE<br />
<br />
# Récupération des infos du dépôt du collègue<br />
git fetch collegue<br />
<br />
# Maintenant, on peut voir les branches du collègue<br />
git branch -a<br />
<br />
# On peut fusionner avec une branche<br />
git merge collegue/master<br />
<br />
# Si vous avez des conflits, éditez les fichiers concernés,<br />
# et committez avec git commit<br />
<br />
# Push vers votre dépôt distant<br />
git push origin<br />
<br />
# Optionnel: supprimez la référence vers le dépôt du collègue<br />
git remote rm collegue<br />
</syntaxhighlight><br />
<br />
<br />
====Archetype webapp====<br />
L'archetype webapp (http://maven.apache.org/archetype/maven-archetype-bundles/maven-archetype-webapp/) permet de créer le squelette d'une webapp. Créez un simple webapp monsite en version 0.1.0. (add/commit/push). Vous pourrez tester cette webapp en ajoutant au pom.xml le [https://wiki.eclipse.org/Jetty/Feature/Jetty_Maven_Plugin plugin maven Jetty].<br />
<br />
<syntaxhighlight lang="bash"><br />
mvn -Djetty.port=9999 jetty:run<br />
</syntaxhighlight><br />
<br />
Naviguez sur http://localhost:9999/monsite<br />
<br />
====Scrum tools====<br />
Ces 3 services peuvent être couplé à votre dépôt GitHub pour votre gestion de projet agile avec [[Scrum]] :<br />
* http://www.acunote.com/<br />
* http://backlogtool.com/<br />
* http://www.scrumdo.com/<br />
<br />
L'activation se fait via ''Settings > Webhooks & Services > Configure services''.<br />
<br />
==Séance 2==<br />
AOP & AspectJ<br />
<br />
Ajouter le [http://mojo.codehaus.org/aspectj-maven-plugin/ plugin Maven pour AspectJ] au pom.xml<br />
<br />
Ajouter un aspect de trace à l'invocation des méthodes run() de l'interface java.lang.Runnable (uniquement pour les objets ''schedulé''s).<br />
<br />
===Contrôle continu===<br />
Compléter l'aspect de trace avec le positionnement du [http://docs.oracle.com/javase/7/docs/api/java/lang/ThreadLocal.html java.lang.ThreadLocal] pour passer 1) l'identifiant du job et 2) le compteur des appels de la méthode de l'objet.<br />
<br />
==Séance 3==<br />
@WIP<br />
<br />
Injection de dépendances avec [[Guice]] <br />
<br />
<br />
==Séance 4==<br />
[[Tutorial OSGi avec Apache Felix]]<br />
<br />
<br />
<br />
==Séance 5==<br />
Faire un projet PDE pour un bundle cron4j.gogo (indépendant de cron4j.bundle)<br />
<br />
Utilisation de https://eclipse.org/tycho/</div>Calmanthttps://air.imag.fr/index.php?title=TAGL/TP&diff=15632TAGL/TP2014-02-19T11:00:38Z<p>Calmant: /* Bonus Track */</p>
<hr />
<div>Travaux pratiques de l'UE [[TAGL]].<br />
<br />
==Séance 1==<br />
===Git===<br />
Créer un dépôt Git local (bare)<br />
<pre><br />
mkdir tagl<br />
cd tagl<br />
mkdir testgit<br />
cd testgit<br />
git init --bare<br />
cd ..<br />
git clone testgit testgit-work<br />
cd testgit-work<br />
echo hello > readme.rst<br />
git add readme.rst<br />
git commit<br />
git push origin master<br />
</pre><br />
<br />
En parallèle : Installer dans votre Eclipse le plugin ReST Editor depuis le [https://marketplace.eclipse.org/content/rest-editor Marketplace Eclipse]<br />
<br />
===GitHub & Travis-CI===<br />
Créer compte individuel sur GitHub https://github.com<br />
<br />
''Fork''er le projet TAGL '''cron4j''' depuis https://github.com/donsez/tagl<br />
<br />
Ajouter un collaborateur (ie votre binome) au projet ''forké''<br />
<br />
Activer le Email hook depuis les paramètres (settings) du dépôt.<br />
<br />
Activer le Travis-CI ''hook' depuis https://travis-ci.org/ (sign in avec le compte GitHub)<br />
<br />
''Commit/Push'' '''.travis.yml''' pour Ant:<br />
<br />
<pre><br />
language: java<br />
<br />
jdk:<br />
- oraclejdk7<br />
- openjdk6<br />
- openjdk7<br />
<br />
script:<br />
- pushd cron4j-original && ant rel && popd<br />
</pre><br />
<br />
===Maven===<br />
[http://maven.apache.org/download.cgi Changer et installer Maven 3].<br />
<br />
<pre><br />
mvn -version<br />
</pre><br />
<br />
Créer '''cron4j-mvn''' (layout + pom.xml) en réorganisant les sources de cron4j-original. Pour cela, vous utiliserez préalablement un [https://maven.apache.org/guides/introduction/introduction-to-archetypes.html archetype Maven] ''simple'' ou ''quickstart''. (la version de cron4j est la 2.5.5).<br />
<br />
Modifier .travis.yml pour ''mvn -DskipTests=true clean install'' (Commit/Push)<br />
<br />
<br />
===Tests Unitaires avec JUnit 4===<br />
Survoller le tutoriel [http://www.vogella.com/tutorials/JUnit/article.html Unit Testing with JUnit]<br />
<br />
Ajouter le test unitaire suivant au layout du projet<br />
<br />
<pre><br />
package it.sauronsoftware;<br />
<br />
import it.sauronsoftware.cron4j.SchedulingPattern;<br />
import it.sauronsoftware.cron4j.InvalidPatternException;<br />
<br />
import static org.junit.Assert.assertEquals;<br />
import static org.junit.Assert.assertTrue;<br />
<br />
import org.junit.AfterClass;<br />
import org.junit.BeforeClass;<br />
import org.junit.Test;<br />
<br />
public class SchedulingPatternTest {<br />
<br />
@BeforeClass<br />
public static void testSetup() {<br />
}<br />
<br />
@AfterClass<br />
public static void testCleanup() {<br />
// Teardown for data used by the unit tests<br />
}<br />
<br />
@Test(expected = InvalidPatternException.class)<br />
public void testExceptionIsThrown() {<br />
SchedulingPattern sp = new SchedulingPattern("0 5 * *");<br />
}<br />
<br />
@Test<br />
public void testPattern() {<br />
String pattern;<br />
pattern="0 5 * * *|8 10 * * *|22 17 * * *";<br />
assertTrue(pattern + "is correct", SchedulingPattern.validate(pattern));<br />
pattern="0 5 * *";<br />
assertTrue(pattern + "is correct", SchedulingPattern.validate(pattern));<br />
}<br />
}<br />
</pre><br />
<br />
<br />
Rechercher la dépendance JUnit 4 dans [http://search.maven.org/#search|ga|1|JUnit Maven Central]<br />
<br />
Ajouter la dépendance JUnit 4 au pom.xml<br />
<br />
<br />
<br />
Lancer le build mvn test<br />
<br />
Modifier '''.travis.yml''' pour ''mvn clean test'' (Commit/Push)<br />
<br />
Regarder votre mail box.<br />
<br />
Naviguer sur http://travis-ci.org pour vérifier les builds effectués.<br />
<br />
Créer des tests unitaires du i.s.c.CronParser<br />
<br />
===Git (suite)===<br />
# Forker le projet '''cron4j-mvn''' d'un autre binome (ie l'origine)<br />
# Ajouter une bannière de licence dans le pom.xml<br />
# Lancer mvn clean install (bonne pratique)<br />
# Commiter<br />
# Faire un Push request vers l'origine<br />
<br />
===Contrôle Continu===<br />
Ajoutez au pom.xml le plugin Covertura pour la couverture de code.<br />
<br />
Répondez aux questions : ''Mais qu'est ce que la couverture de code ? En quoi c'est utile ?''<br />
<br />
Ajoutez au pom.xml les plugins pour la gestion du site et des rapports (Javadoc, tests unitaires, tags list (FIXME, TODO, ...), ...): http://maven.apache.org/plugins/maven-site-plugin/ et d'autres.<br />
<br />
Pour la prochaine séance, regardez les exemples d'utilisation de cron4j dans cron4j-original/examples<br />
<br />
===Bonus Track===<br />
<br />
====Clone SVN -> Git====<br />
<br />
Source: http://www.yterium.net/Migrer-un-projet-SVN-vers-GIT<br />
<br />
<syntaxhighlight lang="bash"><br />
# Cloner le dépôt SVN en dépôt Git (conservation historique)<br />
$ git svn clone svn://svn.code.sf.net/p/cron4j/code/trunk cron4j-original<br />
$ cd cron4j-original<br />
# Test compilation<br />
$ ant jar<br />
$ cd ..<br />
</syntaxhighlight><br />
<br />
====Préparation TAGL====<br />
<br />
<syntaxhighlight lang="bash"><br />
# Clone du dépôt TAGL<br />
$ git clone git@github.com:donsez/tagl.git<br />
$ cd tagl<br />
# "Fetch" du dépôt local cloné précédemment<br />
$ git fetch file://$(pwd)/../cron4j-original<br />
# Fusion de ce qui vient d'être fetché<br />
$ git merge FETCH_HEAD<br />
# Envoi sur le serveur<br />
$ git push<br />
</syntaxhighlight><br />
<br />
<br />
===Cherry-picking: reprise des modifications d'un collègue===<br />
<br />
On considère:<br />
<br />
* votre dépôt Git distant est à l'adresse URL_DEPOT<br />
* votre collègue a un dépôt Git à l'adresse URL_COLLEGUE<br />
<br />
<syntaxhighlight lang="bash"><br />
# Dossier temporaire<br />
cd /tmp<br />
<br />
# Clone de votre dépôt<br />
git clone URL_DEPOT mon_depot<br />
<br />
# Déplacement dans votre dépôt<br />
cd mon_depot<br />
<br />
# Définition du dépôt distant<br />
git remote add collegue URL_COLLEGUE<br />
<br />
# Récupération des infos du dépôt du collègue<br />
git fetch collegue<br />
<br />
# Maintenant, on peut voir les branches du collègue<br />
git branch -a<br />
<br />
# On peut fusionner avec une branche<br />
git merge collegue/master<br />
<br />
# Si vous avez des conflits, éditez les fichiers concernés,<br />
# et committez avec git commit<br />
<br />
# Push vers votre dépôt distant<br />
git push origin<br />
<br />
# Optionnel: supprimez la référence vers le dépôt du collègue<br />
git remote rm collegue<br />
</syntaxhighlight><br />
<br />
<br />
====Archetype webapp====<br />
L'archetype webapp (http://maven.apache.org/archetype/maven-archetype-bundles/maven-archetype-webapp/) permet de créer le squelette d'une webapp. Créez un simple webapp monsite en version 0.1.0. (add/commit/push). Vous pourrez tester cette webapp en ajoutant au pom.xml le [https://wiki.eclipse.org/Jetty/Feature/Jetty_Maven_Plugin plugin maven Jetty].<br />
<br />
<syntaxhighlight lang="bash"><br />
mvn -Djetty.port=9999 jetty:run<br />
</syntaxhighlight><br />
<br />
Naviguez sur http://localhost:9999/monsite<br />
<br />
====Scrum tools====<br />
Ces 3 services peuvent être couplé à votre dépôt GitHub pour votre gestion de projet agile avec [[Scrum]] :<br />
* http://www.acunote.com/<br />
* http://backlogtool.com/<br />
* http://www.scrumdo.com/<br />
<br />
L'activation se fait via ''Settings > Webhooks & Services > Configure services''.<br />
<br />
==Séance 2==<br />
AOP & AspectJ<br />
<br />
Ajouter le [http://mojo.codehaus.org/aspectj-maven-plugin/ plugin Maven pour AspectJ] au pom.xml<br />
<br />
Ajouter un aspect de trace à l'invocation des méthodes run() de l'interface java.lang.Runnable (uniquement pour les objets ''schedulé''s).<br />
<br />
===Contrôle continu===<br />
Compléter l'aspect de trace avec le positionnement du [http://docs.oracle.com/javase/7/docs/api/java/lang/ThreadLocal.html java.lang.ThreadLocal] pour passer 1) l'identifiant du job et 2) le compteur des appels de la méthode de l'objet.<br />
<br />
==Séance 3==<br />
@WIP<br />
<br />
Injection de dépendances avec [[Guice]] <br />
<br />
<br />
==Séance 4==<br />
[[Tutorial OSGi avec Apache Felix]]<br />
<br />
<br />
<br />
==Séance 5==<br />
Faire un projet PDE pour un bundle cron4j.gogo (indépendant de cron4j.bundle)<br />
<br />
Utilisation de https://eclipse.org/tycho/</div>Calmanthttps://air.imag.fr/index.php?title=TAGL/TP&diff=15477TAGL/TP2014-02-14T09:25:58Z<p>Calmant: /* Git */</p>
<hr />
<div>Travaux pratiques de l'UE [[TAGL]].<br />
<br />
==Séance 1==<br />
===Git===<br />
Créer un dépôt Git local (bare)<br />
<pre><br />
mkdir tagl<br />
cd tagl<br />
mkdir testgit<br />
cd testgit<br />
git init --bare<br />
cd ..<br />
git clone testgit testgit-work<br />
cd testgit-work<br />
echo hello > readme.rst<br />
git add readme.rst<br />
git commit<br />
git push origin master<br />
</pre><br />
<br />
En parallèle : Installer dans votre Eclipse le plugin ReST Editor depuis le [https://marketplace.eclipse.org/content/rest-editor Marketplace Eclipse]<br />
<br />
===GitHub & Travis-CI===<br />
Créer compte individuel sur GitHub https://github.com<br />
<br />
''Fork''er le projet TAGL '''cron4j''' depuis https://github.com/donsez/tagl<br />
<br />
Ajouter un collaborateur (ie votre binome) au projet ''forké''<br />
<br />
Activer le Email hook depuis les paramètres (settings) du dépôt.<br />
<br />
Activer le Travis-CI ''hook' depuis https://travis-ci.org/ (sign in avec le compte GitHub)<br />
<br />
''Commit/Push'' '''.travis.yml''' pour Ant:<br />
<br />
<pre><br />
language: java<br />
<br />
jdk:<br />
- oraclejdk7<br />
- openjdk6<br />
- openjdk7<br />
<br />
script:<br />
- pushd cron4j-original && ant rel && popd<br />
</pre><br />
<br />
===Maven===<br />
[http://maven.apache.org/download.cgi Changer et installer Maven 3].<br />
<br />
<pre><br />
mvn -version<br />
</pre><br />
<br />
Créer '''cron4j-mvn''' (layout + pom.xml) en réorganisant les sources de cron4j-original. Pour cela, vous utiliserez préalablement un [https://maven.apache.org/guides/introduction/introduction-to-archetypes.html archetype Maven] ''simple'' ou ''quickstart''. (la version de cron4j est la 2.5.5).<br />
<br />
Modifier .travis.yml pour ''mvn -DskipTests=true clean install'' (Commit/Push)<br />
<br />
<br />
===Tests Unitaires avec JUnit 4===<br />
Survoller le tutoriel [http://www.vogella.com/tutorials/JUnit/article.html Unit Testing with JUnit]<br />
<br />
Ajouter le test unitaire suivant au layout du projet<br />
<br />
<pre><br />
package it.sauronsoftware;<br />
<br />
import it.sauronsoftware.cron4j.SchedulingPattern;<br />
import it.sauronsoftware.cron4j.InvalidPatternException;<br />
<br />
import static org.junit.Assert.assertEquals;<br />
import static org.junit.Assert.assertTrue;<br />
<br />
import org.junit.AfterClass;<br />
import org.junit.BeforeClass;<br />
import org.junit.Test;<br />
<br />
public class SchedulingPatternTest {<br />
<br />
@BeforeClass<br />
public static void testSetup() {<br />
}<br />
<br />
@AfterClass<br />
public static void testCleanup() {<br />
// Teardown for data used by the unit tests<br />
}<br />
<br />
@Test(expected = InvalidPatternException.class)<br />
public void testExceptionIsThrown() {<br />
SchedulingPattern sp = new SchedulingPattern("0 5 * *");<br />
}<br />
<br />
@Test<br />
public void testPattern() {<br />
String pattern;<br />
pattern="0 5 * * *|8 10 * * *|22 17 * * *";<br />
assertTrue(pattern + "is correct", SchedulingPattern.validate(pattern));<br />
pattern="0 5 * *";<br />
assertTrue(pattern + "is correct", SchedulingPattern.validate(pattern));<br />
}<br />
}<br />
</pre><br />
<br />
<br />
Rechercher la dépendance JUnit 4 dans [http://search.maven.org/#search|ga|1|JUnit Maven Central]<br />
<br />
Ajouter la dépendance JUnit 4 au pom.xml<br />
<br />
<br />
<br />
Lancer le build mvn test<br />
<br />
Modifier '''.travis.yml''' pour ''mvn clean test'' (Commit/Push)<br />
<br />
Regarder votre mail box.<br />
<br />
Naviguer sur http://travis-ci.org pour vérifier les builds effectués.<br />
<br />
Créer des tests unitaires du i.s.c.CronParser<br />
<br />
===Git (suite)===<br />
# Forker le projet '''cron4j-mvn''' d'un autre binome (ie l'origine)<br />
# Ajouter une bannière de licence dans le pom.xml<br />
# Lancer mvn clean install (bonne pratique)<br />
# Commiter<br />
# Faire un Push request vers l'origine<br />
<br />
===Contrôle Continu===<br />
Ajoutez au pom.xml le plugin Covertura pour la couverture de code.<br />
<br />
Répondez aux questions : ''Mais qu'est ce que la couverture de code ? En quoi c'est utile ?''<br />
<br />
Ajoutez au pom.xml les plugins pour la gestion du site et des rapports (Javadoc, tests unitaires, tags list (FIXME, TODO, ...), ...): http://maven.apache.org/plugins/maven-site-plugin/ et d'autres.<br />
<br />
Pour la prochaine séance, regardez les exemples d'utilisation de cron4j dans cron4j-original/examples<br />
<br />
===Bonus Track===<br />
<br />
====Clone SVN -> Git====<br />
<br />
Source: http://www.yterium.net/Migrer-un-projet-SVN-vers-GIT<br />
<br />
<syntaxhighlight lang="bash"><br />
# Cloner le dépôt SVN en dépôt Git (conservation historique)<br />
$ git svn clone svn://svn.code.sf.net/p/cron4j/code/trunk cron4j-original<br />
$ cd cron4j-original<br />
# Test compilation<br />
$ ant jar<br />
$ cd ..<br />
</syntaxhighlight><br />
<br />
====Préparation TAGL====<br />
<br />
<syntaxhighlight lang="bash"><br />
# Clone du dépôt TAGL<br />
$ git clone git@github.com:donsez/tagl.git<br />
$ cd tagl<br />
# "Fetch" du dépôt local cloné précédemment<br />
$ git fetch file://$(pwd)/../cron4j-original<br />
# Fusion de ce qui vient d'être fetché<br />
$ git merge FETCH_HEAD<br />
# Envoi sur le serveur<br />
$ git push<br />
</syntaxhighlight><br />
<br />
<br />
====Archetype webapp====<br />
L'archetype webapp (http://maven.apache.org/archetype/maven-archetype-bundles/maven-archetype-webapp/) permet de créer le squelette d'une webapp. Créez un simple webapp monsite en version 0.1.0. (add/commit/push). Vous pourrez tester cette webapp en ajoutant au pom.xml le [https://wiki.eclipse.org/Jetty/Feature/Jetty_Maven_Plugin plugin maven Jetty].<br />
<br />
<syntaxhighlight lang="bash"><br />
mvn -Djetty.port=9999 jetty:run<br />
</syntaxhighlight><br />
<br />
Naviguez sur http://localhost:9999/monsite<br />
<br />
==Séance 2==<br />
AOP & AspectJ<br />
<br />
Ajouter le [http://mojo.codehaus.org/aspectj-maven-plugin/ plugin Maven pour AspectJ] au pom.xml<br />
<br />
Ajouter un aspect de trace à l'invocation des méthodes run() de l'interface java.lang.Runnable (uniquement pour les objets ''schedulé''s).<br />
<br />
===Contrôle continu===<br />
Compléter l'aspect de trace avec le positionnement du [http://docs.oracle.com/javase/7/docs/api/java/lang/ThreadLocal.html java.lang.ThreadLocal] pour passer 1) l'identifiant du job et 2) le compteur des appels de la méthode de l'objet.<br />
<br />
==Séance 3==<br />
@WIP<br />
<br />
Injection de dépendances avec [[Guice]] <br />
<br />
<br />
==Séance 4==<br />
[[Tutorial OSGi avec Apache Felix]]<br />
<br />
<br />
<br />
==Séance 5==<br />
Faire un projet PDE pour un bundle cron4j.gogo (indépendant de cron4j.bundle)<br />
<br />
Utilisation de https://eclipse.org/tycho/</div>Calmanthttps://air.imag.fr/index.php?title=TAGL/TP&diff=15205TAGL/TP2014-02-07T08:01:23Z<p>Calmant: /* Tests Unitaires avec JUnit 4 */</p>
<hr />
<div>Travaux pratiques de l'UE [[TAGL]].<br />
<br />
==Séance 1==<br />
===Git===<br />
Créer un dépôt Git local (bare)<br />
<pre><br />
mkdir tagl<br />
cd tagl<br />
mkdir testgit<br />
cd testgit<br />
git init --bare<br />
cd ..<br />
git clone testgit testgit-work<br />
cd testgit-work<br />
echo hello > readme.rst<br />
git add readme.rst<br />
git commit<br />
git push<br />
</pre><br />
<br />
En parallèle : Installer dans votre Eclipse le plugin ReST Editor depuis le [https://marketplace.eclipse.org/content/rest-editor Marketplace Eclipse]<br />
<br />
===GitHub & Travis-CI===<br />
Créer compte individuel sur GitHub https://github.com<br />
<br />
''Fork''er le projet TAGL '''cron4j''' depuis https://github.com/donsez/tagl<br />
<br />
Ajouter un collaborateur (ie votre binome) au projet ''forké''<br />
<br />
Activer le Email hook depuis les paramètres (settings) du dépôt.<br />
<br />
Activer le Travis-CI ''hook' depuis https://travis-ci.org/ (sign in avec le compte GitHub)<br />
<br />
''Commit/Push'' '''.travis.yml''' pour Ant:<br />
<br />
<pre><br />
language: java<br />
<br />
jdk:<br />
- oraclejdk7<br />
- openjdk6<br />
- openjdk7<br />
<br />
script:<br />
- pushd cron4j-original && ant rel && popd<br />
</pre><br />
<br />
===Maven===<br />
[http://maven.apache.org/download.cgi Changer et installer Maven 3].<br />
<br />
<pre><br />
mvn -version<br />
</pre><br />
<br />
Créer '''cron4j-mvn''' (layout + pom.xml) en réorganisant les sources de cron4j-original. Pour cela, vous utiliserez préalablement un [https://maven.apache.org/guides/introduction/introduction-to-archetypes.html archetype Maven] ''simple'' ou ''quickstart''. (la version de cron4j est la 2.5.5).<br />
<br />
Modifier .travis.yml pour ''mvn -DskipTests=true clean install'' (Commit/Push)<br />
<br />
<br />
===Tests Unitaires avec JUnit 4===<br />
Survoller le tutoriel [http://www.vogella.com/tutorials/JUnit/article.html Unit Testing with JUnit]<br />
<br />
Ajouter le test unitaire suivant au layout du projet<br />
<br />
<pre><br />
package it.sauronsoftware;<br />
<br />
import it.sauronsoftware.cron4j.SchedulingPattern;<br />
import it.sauronsoftware.cron4j.InvalidPatternException;<br />
<br />
import static org.junit.Assert.assertEquals;<br />
import static org.junit.Assert.assertTrue;<br />
<br />
import org.junit.AfterClass;<br />
import org.junit.BeforeClass;<br />
import org.junit.Test;<br />
<br />
public class SchedulingPatternTest {<br />
<br />
@BeforeClass<br />
public static void testSetup() {<br />
}<br />
<br />
@AfterClass<br />
public static void testCleanup() {<br />
// Teardown for data used by the unit tests<br />
}<br />
<br />
@Test(expected = InvalidPatternException.class)<br />
public void testExceptionIsThrown() {<br />
SchedulingPattern sp = new SchedulingPattern("0 5 * *");<br />
}<br />
<br />
@Test<br />
public void testPattern() {<br />
String pattern;<br />
pattern="0 5 * * *|8 10 * * *|22 17 * * *";<br />
assertTrue(pattern + "is correct", SchedulingPattern.validate(pattern));<br />
pattern="0 5 * *";<br />
assertTrue(pattern + "is correct", SchedulingPattern.validate(pattern));<br />
}<br />
}<br />
</pre><br />
<br />
<br />
Rechercher la dépendance JUnit 4 dans [http://search.maven.org/#search|ga|1|JUnit Maven Central]<br />
<br />
Ajouter la dépendance JUnit 4 au pom.xml<br />
<br />
<br />
<br />
Lancer le build mvn test<br />
<br />
Modifier '''.travis.yml''' pour ''mvn clean test'' (Commit/Push)<br />
<br />
Regarder votre mail box.<br />
<br />
Naviguer sur http://travis-ci.org pour vérifier les builds effectués.<br />
<br />
Créer des tests unitaires du i.s.c.CronParser<br />
<br />
===Git (suite)===<br />
# Forker le projet '''cron4j-mvn''' d'un autre binome (ie l'origine)<br />
# Ajouter une bannière de licence dans le pom.xml<br />
# Lancer mvn clean install (bonne pratique)<br />
# Commiter<br />
# Faire un Push request vers l'origine<br />
<br />
===Contrôle Continu===<br />
Ajoutez au pom.xml le plugin Covertura pour la couverture de code.<br />
<br />
Répondez aux questions : ''Mais qu'est ce que la couverture de code ? En quoi c'est utile ?''<br />
<br />
Ajoutez au pom.xml les plugins pour la gestion du site et des rapports (Javadoc, tests unitaires, tags list (FIXME, TODO, ...), ...): http://maven.apache.org/plugins/maven-site-plugin/ et d'autres.<br />
<br />
Pour la prochaine séance, regardez les exemples d'utilisation de cron4j dans cron4j-original/examples<br />
<br />
===Bonus Track===<br />
<br />
====Clone SVN -> Git====<br />
<br />
Source: http://www.yterium.net/Migrer-un-projet-SVN-vers-GIT<br />
<br />
<syntaxhighlight lang="bash"><br />
# Cloner le dépôt SVN en dépôt Git (conservation historique)<br />
$ git svn clone svn://svn.code.sf.net/p/cron4j/code/trunk cron4j-original<br />
$ cd cron4j-original<br />
# Test compilation<br />
$ ant jar<br />
$ cd ..<br />
</syntaxhighlight><br />
<br />
====Préparation TAGL====<br />
<br />
<syntaxhighlight lang="bash"><br />
# Clone du dépôt TAGL<br />
$ git clone git@github.com:donsez/tagl.git<br />
$ cd tagl<br />
# "Fetch" du dépôt local cloné précédemment<br />
$ git fetch file://$(pwd)/../cron4j-original<br />
# Fusion de ce qui vient d'être fetché<br />
$ git merge FETCH_HEAD<br />
# Envoi sur le serveur<br />
$ git push<br />
</syntaxhighlight><br />
<br />
<br />
====Archetype webapp====<br />
L'archetype webapp (http://maven.apache.org/archetype/maven-archetype-bundles/maven-archetype-webapp/) permet de créer le squelette d'une webapp. Créez un simple webapp monsite en version 0.1.0. (add/commit/push). Vous pourrez tester cette webapp en ajoutant au pom.xml le [https://wiki.eclipse.org/Jetty/Feature/Jetty_Maven_Plugin plugin maven Jetty].<br />
<br />
<syntaxhighlight lang="bash"><br />
mvn -Djetty.port=9999 jetty:run<br />
</syntaxhighlight><br />
<br />
Naviguez sur http://localhost:9999/monsite<br />
<br />
==Séance 2==<br />
AOP & AspectJ<br />
<br />
Ajouter le [http://mojo.codehaus.org/aspectj-maven-plugin/ plugin Maven pour AspectJ] au pom.xml<br />
<br />
Ajouter un aspect de trace à l'invocation des méthodes run() de l'interface java.lang.Runnable (uniquement pour les objets ''schedulé''s).<br />
<br />
===Contrôle continu===<br />
Compléter l'aspect de trace avec le positionnement du [http://docs.oracle.com/javase/7/docs/api/java/lang/ThreadLocal.html java.lang.ThreadLocal] pour passer 1) l'identifiant du job et 2) le compteur des appels de la méthode de l'objet.<br />
<br />
==Séance 3==<br />
@WIP<br />
<br />
Injection de dépendances avec [[Guice]] <br />
<br />
<br />
==Séance 4==<br />
[[Tutorial OSGi avec Apache Felix]]<br />
<br />
<br />
<br />
==Séance 5==<br />
Faire un projet PDE pour un bundle cron4j.gogo (indépendant de cron4j.bundle)<br />
<br />
Utilisation de https://eclipse.org/tycho/</div>Calmanthttps://air.imag.fr/index.php?title=TAGL/TP&diff=15189TAGL/TP2014-02-06T16:36:00Z<p>Calmant: /* Séance 1 */</p>
<hr />
<div>==Séance 1==<br />
Créer un dépôt Git local (bare)<br />
<pre><br />
mkdir tagl<br />
cd tagl<br />
mkdir testgit<br />
cd testgit<br />
git init --bare<br />
cd ..<br />
git clone testgit testgit-work<br />
cd testgit-work<br />
echo hello > readme.rst<br />
git add readme.rst<br />
git commit<br />
git push<br />
</pre><br />
<br />
En parallèle : Installer dans votre Eclipse le plugin ReST Editor depuis le [https://marketplace.eclipse.org/content/rest-editor Marketplace Eclipse]<br />
<br />
<br />
Créer compte individuel sur GitHub https://github.com<br />
<br />
''Fork''er le projet TAGL '''cron4j''' depuis https://github.com/donsez/tagl<br />
<br />
Ajouter un collaborateur au projet ''forké''<br />
<br />
Activer le Email hook depuis les paramètres (settings) du dépôt.<br />
<br />
Activer le Travis-CI ''hook' depuis https://travis-ci.org/ (sign in avec le compte GitHub)<br />
<br />
''Commit/Push'' '''.travis.yml''' pour Ant:<br />
<br />
<pre><br />
language: java<br />
<br />
jdk:<br />
- oraclejdk7<br />
- openjdk6<br />
- openjdk7<br />
<br />
script:<br />
- pushd cron4j-original && ant rel && popd<br />
</pre><br />
<br />
<br />
Créer '''cron4j-mvn''' (layout + pom.xml)<br />
<br />
Modifier .travis.yml pour ''mvn -DskipTests=true clean install'' (Commit/Push)<br />
<br />
Créer des tests unitaires du i.s.c.CronParser (Ajouter la dépendance JUnit 4 au pom.xml)<br />
<br />
Modifier '''.travis.yml''' pour ''mvn clean test'' (Commit/Push)<br />
<br />
===Contrôle Continu===<br />
# Ajoutez au pom.xml le plugin Covertura pour la couverture de code.<br />
# Répondez aux questions : ''Mais qu'est ce que la couverture de code ? En quoi c'est utile ?''<br />
# Ajoutez au pom.xml les plugins pour la gestion du site et des rapports (Javadoc, tests unitaires, tags list (FIXME, TODO, ...), ...): http://maven.apache.org/plugins/maven-site-plugin/ et d'autres.<br />
# Pour la prochaine séance, regardez les exemples d'utilisation de cron4j dans cron4j-original/examples<br />
<br />
===Bonus Track===<br />
<br />
====Clone SVN -> Git====<br />
<br />
Source: http://www.yterium.net/Migrer-un-projet-SVN-vers-GIT<br />
<br />
<syntaxhighlight lang="bash"><br />
# Cloner le dépôt SVN en dépôt Git (conservation historique)<br />
$ git svn clone svn://svn.code.sf.net/p/cron4j/code/trunk cron4j-original<br />
$ cd cron4j-original<br />
# Test compilation<br />
$ ant jar<br />
$ cd ..<br />
</syntaxhighlight><br />
<br />
====Préparation TAGL====<br />
<br />
<syntaxhighlight lang="bash"><br />
# Clone du dépôt TAGL<br />
$ git clone git@github.com:donsez/tagl.git<br />
$ cd tagl<br />
# "Fetch" du dépôt local cloné précédemment<br />
$ git fetch file://$(pwd)/../cron4j-original<br />
# Fusion de ce qui vient d'être fetché<br />
$ git merge FETCH_HEAD<br />
# Envoi sur le serveur<br />
$ git push<br />
</syntaxhighlight><br />
<br />
==Séance 2==<br />
AOP & AspectJ<br />
<br />
Ajouter le [http://mojo.codehaus.org/aspectj-maven-plugin/ plugin Maven pour AspectJ] au pom.xml<br />
<br />
Ajouter un aspect de trace à l'invocation des méthodes run() de l'interface java.lang.Runnable (uniquement pour les objets ''schedulé''s).<br />
<br />
===Contrôle continu===<br />
Compléter l'aspect de trace avec le positionnement du [http://docs.oracle.com/javase/7/docs/api/java/lang/ThreadLocal.html java.lang.ThreadLocal] pour passer 1) l'identifiant du job et 2) le compteur des appels de la méthode de l'objet.<br />
<br />
==Séance 3==<br />
@TODO<br />
<br />
[[Tutorial OSGi avec Apache Felix]]<br />
<br />
==Séance 4==<br />
@TODO<br />
<br />
<br />
==Séance 5==<br />
Faire un projet PDE pour un bundle cron4j.gogo (indépendant de cron4j.bundle)<br />
<br />
Utilisation de https://eclipse.org/tycho/</div>Calmanthttps://air.imag.fr/index.php?title=TAGL/TP&diff=15188TAGL/TP2014-02-06T16:35:11Z<p>Calmant: /* Séance 1 */</p>
<hr />
<div>==Séance 1==<br />
Créer un dépôt Git local (bare)<br />
<pre><br />
mkdir tagl<br />
cd tagl<br />
mkdir testgit<br />
cd testgit<br />
git init --bare<br />
cd ..<br />
git clone testgit testgit-work<br />
cd testgit-work<br />
echo hello > readme.rst<br />
git add readme.rst<br />
git commit<br />
git push<br />
</pre><br />
<br />
En parallèle : Installer dans votre Eclipse le plugin ReST Editor depuis le [https://marketplace.eclipse.org/content/rest-editor Marketplace Eclipse]<br />
<br />
<br />
Créer compte individuel sur GitHub https://github.com<br />
<br />
''Fork''er le projet TAGL '''cron4j''' depuis https://github.com/donsez/tagl<br />
<br />
Ajouter un collaborateur au projet ''forké''<br />
<br />
Activer le Email hook depuis les paramètres (settings) du dépôt.<br />
<br />
Activer le Travis-CI ''hook' depuis https://travis-ci.org/ (sign in avec le compte GitHub)<br />
<br />
''Commit/Push'' '''.travis.yml''' pour Ant:<br />
<br />
<pre><br />
language: java<br />
<br />
jdk:<br />
- oraclejdk7<br />
- openjdk6<br />
- openjdk7<br />
<br />
script:<br />
- pushd cron4j-original && ant rel && popd<br />
</pre><br />
<br />
<br />
Créer '''cron4j-mvn''' (layout + pom.xml)<br />
<br />
Modifier .travis.yml pour ''mvn -DskipTests=true clean install'' (Commit/Push)<br />
<br />
Tests unitaires du i.s.c.CronParser (Ajouter la dépendance JUnit 4 au pom.xml)<br />
<br />
Modifier '''.travis.yml''' pour ''mvn clean install'' (Commit/Push)<br />
<br />
===Contrôle Continu===<br />
# Ajoutez au pom.xml le plugin Covertura pour la couverture de code.<br />
# Répondez aux questions : ''Mais qu'est ce que la couverture de code ? En quoi c'est utile ?''<br />
# Ajoutez au pom.xml les plugins pour la gestion du site et des rapports (Javadoc, tests unitaires, tags list (FIXME, TODO, ...), ...): http://maven.apache.org/plugins/maven-site-plugin/ et d'autres.<br />
# Pour la prochaine séance, regardez les exemples d'utilisation de cron4j dans cron4j-original/examples<br />
<br />
===Bonus Track===<br />
<br />
====Clone SVN -> Git====<br />
<br />
Source: http://www.yterium.net/Migrer-un-projet-SVN-vers-GIT<br />
<br />
<syntaxhighlight lang="bash"><br />
# Cloner le dépôt SVN en dépôt Git (conservation historique)<br />
$ git svn clone svn://svn.code.sf.net/p/cron4j/code/trunk cron4j-original<br />
$ cd cron4j-original<br />
# Test compilation<br />
$ ant jar<br />
$ cd ..<br />
</syntaxhighlight><br />
<br />
====Préparation TAGL====<br />
<br />
<syntaxhighlight lang="bash"><br />
# Clone du dépôt TAGL<br />
$ git clone git@github.com:donsez/tagl.git<br />
$ cd tagl<br />
# "Fetch" du dépôt local cloné précédemment<br />
$ git fetch file://$(pwd)/../cron4j-original<br />
# Fusion de ce qui vient d'être fetché<br />
$ git merge FETCH_HEAD<br />
# Envoi sur le serveur<br />
$ git push<br />
</syntaxhighlight><br />
<br />
==Séance 2==<br />
AOP & AspectJ<br />
<br />
Ajouter le [http://mojo.codehaus.org/aspectj-maven-plugin/ plugin Maven pour AspectJ] au pom.xml<br />
<br />
Ajouter un aspect de trace à l'invocation des méthodes run() de l'interface java.lang.Runnable (uniquement pour les objets ''schedulé''s).<br />
<br />
===Contrôle continu===<br />
Compléter l'aspect de trace avec le positionnement du [http://docs.oracle.com/javase/7/docs/api/java/lang/ThreadLocal.html java.lang.ThreadLocal] pour passer 1) l'identifiant du job et 2) le compteur des appels de la méthode de l'objet.<br />
<br />
==Séance 3==<br />
@TODO<br />
<br />
[[Tutorial OSGi avec Apache Felix]]<br />
<br />
==Séance 4==<br />
@TODO<br />
<br />
<br />
==Séance 5==<br />
Faire un projet PDE pour un bundle cron4j.gogo (indépendant de cron4j.bundle)<br />
<br />
Utilisation de https://eclipse.org/tycho/</div>Calmanthttps://air.imag.fr/index.php?title=TAGL/TP&diff=15187TAGL/TP2014-02-06T16:34:30Z<p>Calmant: /* Séance 1 */</p>
<hr />
<div>==Séance 1==<br />
Créer un dépôt Git local (bare)<br />
<pre><br />
mkdir tagl<br />
cd tagl<br />
mkdir testgit<br />
cd testgit<br />
git init --bare<br />
cd ..<br />
git clone testgit testgit-work<br />
cd testgit-work<br />
echo hello > readme.rst<br />
git add readme.rst<br />
git commit<br />
git push<br />
</pre><br />
<br />
En parallèle : Installer dans votre Eclipse le plugin ReST Editor depuis le [https://marketplace.eclipse.org/content/rest-editor Marketplace Eclipse]<br />
<br />
<br />
Créer compte individuel sur GitHub https://github.com<br />
<br />
''Fork''er le projet TAGL (url) '''cron4j''' (2.5.5)<br />
<br />
Ajouter un collaborateur au projet ''forké''<br />
<br />
Activer le Email hook depuis les paramètres (settings) du dépôt.<br />
<br />
Activer le Travis-CI ''hook' depuis https://travis-ci.org/ (sign in avec le compte GitHub)<br />
<br />
''Commit/Push'' '''.travis.yml''' pour Ant:<br />
<br />
<pre><br />
language: java<br />
<br />
jdk:<br />
- oraclejdk7<br />
- openjdk6<br />
- openjdk7<br />
<br />
script:<br />
- pushd cron4j-original && ant rel && popd<br />
</pre><br />
<br />
<br />
Créer '''cron4j-mvn''' (layout + pom.xml)<br />
<br />
Modifier .travis.yml pour ''mvn -DskipTests=true clean install'' (Commit/Push)<br />
<br />
Tests unitaires du i.s.c.CronParser (Ajouter la dépendance JUnit 4 au pom.xml)<br />
<br />
Modifier '''.travis.yml''' pour ''mvn clean install'' (Commit/Push)<br />
<br />
===Contrôle Continu===<br />
# Ajoutez au pom.xml le plugin Covertura pour la couverture de code.<br />
# Répondez aux questions : ''Mais qu'est ce que la couverture de code ? En quoi c'est utile ?''<br />
# Ajoutez au pom.xml les plugins pour la gestion du site et des rapports (Javadoc, tests unitaires, tags list (FIXME, TODO, ...), ...): http://maven.apache.org/plugins/maven-site-plugin/ et d'autres.<br />
# Pour la prochaine séance, regardez les exemples d'utilisation de cron4j dans cron4j-original/examples<br />
<br />
===Bonus Track===<br />
<br />
====Clone SVN -> Git====<br />
<br />
Source: http://www.yterium.net/Migrer-un-projet-SVN-vers-GIT<br />
<br />
<syntaxhighlight lang="bash"><br />
# Cloner le dépôt SVN en dépôt Git (conservation historique)<br />
$ git svn clone svn://svn.code.sf.net/p/cron4j/code/trunk cron4j-original<br />
$ cd cron4j-original<br />
# Test compilation<br />
$ ant jar<br />
$ cd ..<br />
</syntaxhighlight><br />
<br />
====Préparation TAGL====<br />
<br />
<syntaxhighlight lang="bash"><br />
# Clone du dépôt TAGL<br />
$ git clone git@github.com:donsez/tagl.git<br />
$ cd tagl<br />
# "Fetch" du dépôt local cloné précédemment<br />
$ git fetch file://$(pwd)/../cron4j-original<br />
# Fusion de ce qui vient d'être fetché<br />
$ git merge FETCH_HEAD<br />
# Envoi sur le serveur<br />
$ git push<br />
</syntaxhighlight><br />
<br />
==Séance 2==<br />
AOP & AspectJ<br />
<br />
Ajouter le [http://mojo.codehaus.org/aspectj-maven-plugin/ plugin Maven pour AspectJ] au pom.xml<br />
<br />
Ajouter un aspect de trace à l'invocation des méthodes run() de l'interface java.lang.Runnable (uniquement pour les objets ''schedulé''s).<br />
<br />
===Contrôle continu===<br />
Compléter l'aspect de trace avec le positionnement du [http://docs.oracle.com/javase/7/docs/api/java/lang/ThreadLocal.html java.lang.ThreadLocal] pour passer 1) l'identifiant du job et 2) le compteur des appels de la méthode de l'objet.<br />
<br />
==Séance 3==<br />
@TODO<br />
<br />
[[Tutorial OSGi avec Apache Felix]]<br />
<br />
==Séance 4==<br />
@TODO<br />
<br />
<br />
==Séance 5==<br />
Faire un projet PDE pour un bundle cron4j.gogo (indépendant de cron4j.bundle)<br />
<br />
Utilisation de https://eclipse.org/tycho/</div>Calmanthttps://air.imag.fr/index.php?title=TAGL/TP&diff=15186TAGL/TP2014-02-06T16:14:58Z<p>Calmant: /* Séance 1 */</p>
<hr />
<div>==Séance 1==<br />
Créer un dépôt Git local (bare)<br />
<pre><br />
mkdir tagl<br />
cd tagl<br />
mkdir testgit<br />
cd testgit<br />
git init --bare<br />
cd ..<br />
git clone testgit testgit-work<br />
cd testgit-work<br />
echo hello > readme.rst<br />
git add readme.rst<br />
git commit<br />
git push<br />
</pre><br />
<br />
En parallèle : Installer dans votre Eclipse le plugin ReST Editor depuis le [https://marketplace.eclipse.org/content/rest-editor Marketplace Eclipse]<br />
<br />
<br />
Créer compte individuel sur GitHub https://github.com<br />
<br />
''Fork''er le projet TAGL (url) '''cron4j''' (2.5.5)<br />
<br />
Ajouter un collaborateur au projet ''forké''<br />
<br />
Activer le Email hook depuis les paramètres (settings) du dépôt.<br />
<br />
Activer le Travis-CI ''hook' depuis https://travis-ci.org/ (sign in avec le compte GitHub)<br />
<br />
Committer un fichier ''ci_run.sh'' exécutant les étapes de compilation (nécessaire afin de se placer dans le bon dossier)<br />
<br />
<pre><br />
#!/bin/bash<br />
echo "Original (Ant)"<br />
pushd cron4j-original<br />
ant rel<br />
popd<br />
</pre><br />
<br />
''Commit/Push'' '''.travis.yml''' pour Ant (depuis un gist)<br />
<br />
<pre><br />
language: java<br />
<br />
jdk:<br />
- oraclejdk7<br />
- openjdk6<br />
- openjdk7<br />
<br />
before_script:<br />
chmod +x ci_run.sh<br />
<br />
script:<br />
./ci_run.sh<br />
</pre><br />
<br />
<br />
Créer '''cron4j-mvn''' (layout + pom.xml)<br />
<br />
Modifier .travis.yml pour ''mvn -DskipTests=true clean install'' (Commit/Push)<br />
<br />
Tests unitaires du i.s.c.CronParser (Ajouter la dépendance JUnit 4 au pom.xml)<br />
<br />
Modifier '''.travis.yml''' pour ''mvn clean install'' (Commit/Push)<br />
<br />
===Contrôle Continu===<br />
# Ajoutez au pom.xml le plugin Covertura pour la couverture de code.<br />
# Répondez aux questions : ''Mais qu'est ce que la couverture de code ? En quoi c'est utile ?''<br />
# Ajoutez au pom.xml les plugins pour la gestion du site et des rapports (Javadoc, tests unitaires, tags list (FIXME, TODO, ...), ...): http://maven.apache.org/plugins/maven-site-plugin/ et d'autres.<br />
# Pour la prochaine séance, regardez les exemples d'utilisation de cron4j dans cron4j-original/examples<br />
<br />
===Bonus Track===<br />
<br />
====Clone SVN -> Git====<br />
<br />
Source: http://www.yterium.net/Migrer-un-projet-SVN-vers-GIT<br />
<br />
<syntaxhighlight lang="bash"><br />
# Cloner le dépôt SVN en dépôt Git (conservation historique)<br />
$ git svn clone svn://svn.code.sf.net/p/cron4j/code/trunk cron4j-original<br />
$ cd cron4j-original<br />
# Test compilation<br />
$ ant jar<br />
$ cd ..<br />
</syntaxhighlight><br />
<br />
====Préparation TAGL====<br />
<br />
<syntaxhighlight lang="bash"><br />
# Clone du dépôt TAGL<br />
$ git clone git@github.com:donsez/tagl.git<br />
$ cd tagl<br />
# "Fetch" du dépôt local cloné précédemment<br />
$ git fetch file://$(pwd)/../cron4j-original<br />
# Fusion de ce qui vient d'être fetché<br />
$ git merge FETCH_HEAD<br />
# Envoi sur le serveur<br />
$ git push<br />
</syntaxhighlight><br />
<br />
==Séance 2==<br />
AOP & AspectJ<br />
<br />
Ajouter le [http://mojo.codehaus.org/aspectj-maven-plugin/ plugin Maven pour AspectJ] au pom.xml<br />
<br />
Ajouter un aspect de trace à l'invocation des méthodes run() de l'interface java.lang.Runnable (uniquement pour les objets ''schedulé''s).<br />
<br />
===Contrôle continu===<br />
Compléter l'aspect de trace avec le positionnement du [http://docs.oracle.com/javase/7/docs/api/java/lang/ThreadLocal.html java.lang.ThreadLocal] pour passer 1) l'identifiant du job et 2) le compteur des appels de la méthode de l'objet.<br />
<br />
==Séance 3==<br />
@TODO<br />
<br />
[[Tutorial OSGi avec Apache Felix]]<br />
<br />
==Séance 4==<br />
@TODO<br />
<br />
<br />
==Séance 5==<br />
Faire un projet PDE pour un bundle cron4j.gogo (indépendant de cron4j.bundle)<br />
<br />
Utilisation de https://eclipse.org/tycho/</div>Calmanthttps://air.imag.fr/index.php?title=TAGL/TP&diff=15185TAGL/TP2014-02-06T16:12:50Z<p>Calmant: /* Clone SVN -> Git */</p>
<hr />
<div>==Séance 1==<br />
Créer un dépôt Git local (bare)<br />
<pre><br />
mkdir tagl<br />
cd tagl<br />
mkdir testgit<br />
cd testgit<br />
git init --bare<br />
cd ..<br />
git clone testgit testgit-work<br />
cd testgit-work<br />
echo hello > readme.rst<br />
git add readme.rst<br />
git commit<br />
git push<br />
</pre><br />
<br />
En parallèle : Installer dans votre Eclipse le plugin ReST Editor depuis le [https://marketplace.eclipse.org/content/rest-editor Marketplace Eclipse]<br />
<br />
<br />
Créer compte individuel sur GitHub https://github.com<br />
<br />
''Fork''er le projet TAGL (url) '''cron4j''' (2.5.5)<br />
<br />
Ajouter un collaborateur au projet ''forké''<br />
<br />
Activer le Email hook depuis les paramètres (settings) du dépôt.<br />
<br />
Activer le Travis-CI ''hook' depuis https://travis-ci.org/ (sign in avec le compte GitHub)<br />
<br />
Créer un fichier ''ci_run.sh'' exécutant les étapes de compilation (nécessaire afin de se placer dans le bon dossier)<br />
<br />
<pre><br />
#!/bin/bash<br />
echo "Original (Ant)"<br />
pushd cron4j-original<br />
ant rel<br />
popd<br />
</pre><br />
<br />
''Commit/Push'' '''.travis.yml''' pour Ant (depuis un gist)<br />
<br />
<pre><br />
language: java<br />
<br />
jdk:<br />
- oraclejdk7<br />
- openjdk6<br />
- openjdk7<br />
<br />
before_script:<br />
chmod +x ci_run.sh<br />
<br />
script:<br />
./ci_run.sh<br />
</pre><br />
<br />
<br />
Créer '''cron4j-mvn''' (layout + pom.xml)<br />
<br />
Modifier .travis.yml pour ''mvn -DskipTests=true clean install'' (Commit/Push)<br />
<br />
Tests unitaires du i.s.c.CronParser (Ajouter la dépendance JUnit 4 au pom.xml)<br />
<br />
Modifier '''.travis.yml''' pour ''mvn clean install'' (Commit/Push)<br />
<br />
===Contrôle Continu===<br />
# Ajoutez au pom.xml le plugin Covertura pour la couverture de code.<br />
# Répondez aux questions : ''Mais qu'est ce que la couverture de code ? En quoi c'est utile ?''<br />
# Ajoutez au pom.xml les plugins pour la gestion du site et des rapports (Javadoc, tests unitaires, tags list (FIXME, TODO, ...), ...): http://maven.apache.org/plugins/maven-site-plugin/ et d'autres.<br />
# Pour la prochaine séance, regardez les exemples d'utilisation de cron4j dans cron4j-original/examples<br />
<br />
===Bonus Track===<br />
<br />
====Clone SVN -> Git====<br />
<br />
Source: http://www.yterium.net/Migrer-un-projet-SVN-vers-GIT<br />
<br />
<syntaxhighlight lang="bash"><br />
# Cloner le dépôt SVN en dépôt Git (conservation historique)<br />
$ git svn clone svn://svn.code.sf.net/p/cron4j/code/trunk cron4j-original<br />
$ cd cron4j-original<br />
# Test compilation<br />
$ ant jar<br />
$ cd ..<br />
</syntaxhighlight><br />
<br />
====Préparation TAGL====<br />
<br />
<syntaxhighlight lang="bash"><br />
# Clone du dépôt TAGL<br />
$ git clone git@github.com:donsez/tagl.git<br />
$ cd tagl<br />
# "Fetch" du dépôt local cloné précédemment<br />
$ git fetch file://$(pwd)/../cron4j-original<br />
# Fusion de ce qui vient d'être fetché<br />
$ git merge FETCH_HEAD<br />
# Envoi sur le serveur<br />
$ git push<br />
</syntaxhighlight><br />
<br />
==Séance 2==<br />
AOP & AspectJ<br />
<br />
Ajouter le [http://mojo.codehaus.org/aspectj-maven-plugin/ plugin Maven pour AspectJ] au pom.xml<br />
<br />
Ajouter un aspect de trace à l'invocation des méthodes run() de l'interface java.lang.Runnable (uniquement pour les objets ''schedulé''s).<br />
<br />
===Contrôle continu===<br />
Compléter l'aspect de trace avec le positionnement du [http://docs.oracle.com/javase/7/docs/api/java/lang/ThreadLocal.html java.lang.ThreadLocal] pour passer 1) l'identifiant du job et 2) le compteur des appels de la méthode de l'objet.<br />
<br />
==Séance 3==<br />
@TODO<br />
<br />
[[Tutorial OSGi avec Apache Felix]]<br />
<br />
==Séance 4==<br />
@TODO<br />
<br />
<br />
==Séance 5==<br />
Faire un projet PDE pour un bundle cron4j.gogo (indépendant de cron4j.bundle)<br />
<br />
Utilisation de https://eclipse.org/tycho/</div>Calmanthttps://air.imag.fr/index.php?title=TAGL/TP&diff=15184TAGL/TP2014-02-06T16:12:37Z<p>Calmant: /* Préparation TAGL */</p>
<hr />
<div>==Séance 1==<br />
Créer un dépôt Git local (bare)<br />
<pre><br />
mkdir tagl<br />
cd tagl<br />
mkdir testgit<br />
cd testgit<br />
git init --bare<br />
cd ..<br />
git clone testgit testgit-work<br />
cd testgit-work<br />
echo hello > readme.rst<br />
git add readme.rst<br />
git commit<br />
git push<br />
</pre><br />
<br />
En parallèle : Installer dans votre Eclipse le plugin ReST Editor depuis le [https://marketplace.eclipse.org/content/rest-editor Marketplace Eclipse]<br />
<br />
<br />
Créer compte individuel sur GitHub https://github.com<br />
<br />
''Fork''er le projet TAGL (url) '''cron4j''' (2.5.5)<br />
<br />
Ajouter un collaborateur au projet ''forké''<br />
<br />
Activer le Email hook depuis les paramètres (settings) du dépôt.<br />
<br />
Activer le Travis-CI ''hook' depuis https://travis-ci.org/ (sign in avec le compte GitHub)<br />
<br />
Créer un fichier ''ci_run.sh'' exécutant les étapes de compilation (nécessaire afin de se placer dans le bon dossier)<br />
<br />
<pre><br />
#!/bin/bash<br />
echo "Original (Ant)"<br />
pushd cron4j-original<br />
ant rel<br />
popd<br />
</pre><br />
<br />
''Commit/Push'' '''.travis.yml''' pour Ant (depuis un gist)<br />
<br />
<pre><br />
language: java<br />
<br />
jdk:<br />
- oraclejdk7<br />
- openjdk6<br />
- openjdk7<br />
<br />
before_script:<br />
chmod +x ci_run.sh<br />
<br />
script:<br />
./ci_run.sh<br />
</pre><br />
<br />
<br />
Créer '''cron4j-mvn''' (layout + pom.xml)<br />
<br />
Modifier .travis.yml pour ''mvn -DskipTests=true clean install'' (Commit/Push)<br />
<br />
Tests unitaires du i.s.c.CronParser (Ajouter la dépendance JUnit 4 au pom.xml)<br />
<br />
Modifier '''.travis.yml''' pour ''mvn clean install'' (Commit/Push)<br />
<br />
===Contrôle Continu===<br />
# Ajoutez au pom.xml le plugin Covertura pour la couverture de code.<br />
# Répondez aux questions : ''Mais qu'est ce que la couverture de code ? En quoi c'est utile ?''<br />
# Ajoutez au pom.xml les plugins pour la gestion du site et des rapports (Javadoc, tests unitaires, tags list (FIXME, TODO, ...), ...): http://maven.apache.org/plugins/maven-site-plugin/ et d'autres.<br />
# Pour la prochaine séance, regardez les exemples d'utilisation de cron4j dans cron4j-original/examples<br />
<br />
===Bonus Track===<br />
<br />
====Clone SVN -> Git====<br />
<br />
Source: http://www.yterium.net/Migrer-un-projet-SVN-vers-GIT<br />
<br />
<pre><br />
# Cloner le dépôt SVN en dépôt Git (conservation historique)<br />
$ git svn clone svn://svn.code.sf.net/p/cron4j/code/trunk cron4j-original<br />
$ cd cron4j-original<br />
# Test compilation<br />
$ ant jar<br />
$ cd ..<br />
</pre><br />
<br />
====Préparation TAGL====<br />
<br />
<syntaxhighlight lang="bash"><br />
# Clone du dépôt TAGL<br />
$ git clone git@github.com:donsez/tagl.git<br />
$ cd tagl<br />
# "Fetch" du dépôt local cloné précédemment<br />
$ git fetch file://$(pwd)/../cron4j-original<br />
# Fusion de ce qui vient d'être fetché<br />
$ git merge FETCH_HEAD<br />
# Envoi sur le serveur<br />
$ git push<br />
</syntaxhighlight><br />
<br />
==Séance 2==<br />
AOP & AspectJ<br />
<br />
Ajouter le [http://mojo.codehaus.org/aspectj-maven-plugin/ plugin Maven pour AspectJ] au pom.xml<br />
<br />
Ajouter un aspect de trace à l'invocation des méthodes run() de l'interface java.lang.Runnable (uniquement pour les objets ''schedulé''s).<br />
<br />
===Contrôle continu===<br />
Compléter l'aspect de trace avec le positionnement du [http://docs.oracle.com/javase/7/docs/api/java/lang/ThreadLocal.html java.lang.ThreadLocal] pour passer 1) l'identifiant du job et 2) le compteur des appels de la méthode de l'objet.<br />
<br />
==Séance 3==<br />
@TODO<br />
<br />
[[Tutorial OSGi avec Apache Felix]]<br />
<br />
==Séance 4==<br />
@TODO<br />
<br />
<br />
==Séance 5==<br />
Faire un projet PDE pour un bundle cron4j.gogo (indépendant de cron4j.bundle)<br />
<br />
Utilisation de https://eclipse.org/tycho/</div>Calmanthttps://air.imag.fr/index.php?title=TAGL/TP&diff=15183TAGL/TP2014-02-06T16:07:42Z<p>Calmant: /* Séance 1 */</p>
<hr />
<div>==Séance 1==<br />
Créer un dépôt Git local (bare)<br />
<pre><br />
mkdir tagl<br />
cd tagl<br />
mkdir testgit<br />
cd testgit<br />
git init --bare<br />
cd ..<br />
git clone testgit testgit-work<br />
cd testgit-work<br />
echo hello > readme.rst<br />
git add readme.rst<br />
git commit<br />
git push<br />
</pre><br />
<br />
En parallèle : Installer dans votre Eclipse le plugin ReST Editor depuis le [https://marketplace.eclipse.org/content/rest-editor Marketplace Eclipse]<br />
<br />
<br />
Créer compte individuel sur GitHub https://github.com<br />
<br />
''Fork''er le projet TAGL (url) '''cron4j''' (2.5.5)<br />
<br />
Ajouter un collaborateur au projet ''forké''<br />
<br />
Activer le Email hook depuis les paramètres (settings) du dépôt.<br />
<br />
Activer le Travis-CI ''hook' depuis https://travis-ci.org/ (sign in avec le compte GitHub)<br />
<br />
Créer un fichier ''ci_run.sh'' exécutant les étapes de compilation (nécessaire afin de se placer dans le bon dossier)<br />
<br />
<pre><br />
#!/bin/bash<br />
echo "Original (Ant)"<br />
pushd cron4j-original<br />
ant rel<br />
popd<br />
</pre><br />
<br />
''Commit/Push'' '''.travis.yml''' pour Ant (depuis un gist)<br />
<br />
<pre><br />
language: java<br />
<br />
jdk:<br />
- oraclejdk7<br />
- openjdk6<br />
- openjdk7<br />
<br />
before_script:<br />
chmod +x ci_run.sh<br />
<br />
script:<br />
./ci_run.sh<br />
</pre><br />
<br />
<br />
Créer '''cron4j-mvn''' (layout + pom.xml)<br />
<br />
Modifier .travis.yml pour ''mvn -DskipTests=true clean install'' (Commit/Push)<br />
<br />
Tests unitaires du i.s.c.CronParser (Ajouter la dépendance JUnit 4 au pom.xml)<br />
<br />
Modifier '''.travis.yml''' pour ''mvn clean install'' (Commit/Push)<br />
<br />
===Contrôle Continu===<br />
# Ajoutez au pom.xml le plugin Covertura pour la couverture de code.<br />
# Répondez aux questions : ''Mais qu'est ce que la couverture de code ? En quoi c'est utile ?''<br />
# Ajoutez au pom.xml les plugins pour la gestion du site et des rapports (Javadoc, tests unitaires, tags list (FIXME, TODO, ...), ...): http://maven.apache.org/plugins/maven-site-plugin/ et d'autres.<br />
# Pour la prochaine séance, regardez les exemples d'utilisation de cron4j dans cron4j-original/examples<br />
<br />
===Bonus Track===<br />
<br />
====Clone SVN -> Git====<br />
<br />
Source: http://www.yterium.net/Migrer-un-projet-SVN-vers-GIT<br />
<br />
<pre><br />
# Cloner le dépôt SVN en dépôt Git (conservation historique)<br />
$ git svn clone svn://svn.code.sf.net/p/cron4j/code/trunk cron4j-original<br />
$ cd cron4j-original<br />
# Test compilation<br />
$ ant jar<br />
$ cd ..<br />
</pre><br />
<br />
====Préparation TAGL====<br />
<br />
<pre><br />
# Clone du dépôt TAGL<br />
$ git clone git@github.com:donsez/tagl.git<br />
$ cd tagl<br />
# "Fetch" du dépôt local cloné précédemment<br />
$ git fetch file://$(pwd)/../cron4j-original<br />
# Fusion de ce qui vient d'être fetché<br />
$ git merge FETCH_HEAD<br />
# Envoi sur le serveur<br />
$ git push<br />
</pre><br />
<br />
==Séance 2==<br />
AOP & AspectJ<br />
<br />
Ajouter le [http://mojo.codehaus.org/aspectj-maven-plugin/ plugin Maven pour AspectJ] au pom.xml<br />
<br />
Ajouter un aspect de trace à l'invocation des méthodes run() de l'interface java.lang.Runnable (uniquement pour les objets ''schedulé''s).<br />
<br />
===Contrôle continu===<br />
Compléter l'aspect de trace avec le positionnement du [http://docs.oracle.com/javase/7/docs/api/java/lang/ThreadLocal.html java.lang.ThreadLocal] pour passer 1) l'identifiant du job et 2) le compteur des appels de la méthode de l'objet.<br />
<br />
==Séance 3==<br />
@TODO<br />
<br />
[[Tutorial OSGi avec Apache Felix]]<br />
<br />
==Séance 4==<br />
@TODO<br />
<br />
<br />
==Séance 5==<br />
Faire un projet PDE pour un bundle cron4j.gogo (indépendant de cron4j.bundle)<br />
<br />
Utilisation de https://eclipse.org/tycho/</div>Calmanthttps://air.imag.fr/index.php?title=TAGL/TP&diff=15160TAGL/TP2014-02-06T11:04:55Z<p>Calmant: /* Clone SVN -> Git */</p>
<hr />
<div>==Séance 1==<br />
Créer un dépôt Git local (bare)<br />
<pre><br />
mkdir tagl<br />
cd tagl<br />
mkdir testgit<br />
cd testgit<br />
git init --bare<br />
cd ..<br />
git clone testgit testgit-work<br />
cd testgit-work<br />
echo hello > readme.rst<br />
git add readme.rst<br />
git commit<br />
git push<br />
</pre><br />
<br />
En parallèle : Installer dans votre Eclipse le plugin ReST Editor depuis le [https://marketplace.eclipse.org/content/rest-editor Marketplace Eclipse]<br />
<br />
<br />
Créer compte individuel sur GitHub https://github.com<br />
<br />
''Fork''er le projet TAGL (url) '''cron4j''' (2.5.5)<br />
<br />
Ajouter un collaborateur au projet ''forké''<br />
<br />
Activer le Email hook depuis les paramètres (settings) du dépôt.<br />
<br />
Activer le Travis-CI ''hook' depuis https://travis-ci.org/ (sign in avec le compte GitHub)<br />
<br />
''Commit/Push'' '''.travis.yml''' pour Ant (depuis un gist)<br />
<br />
<pre><br />
<br />
<br />
</pre><br />
<br />
<br />
Créer '''cron4j-mvn''' (layout + pom.xml)<br />
<br />
Modifier .travis.yml pour ''mvn -DskipTests=true clean install'' (Commit/Push)<br />
<br />
Tests unitaires du i.s.c.CronParser (Ajouter la dépendance JUnit 4 au pom.xml)<br />
<br />
Modifier '''.travis.yml''' pour ''mvn clean install'' (Commit/Push)<br />
<br />
===Contrôle Continu===<br />
# Ajouter au pom.xml le plugin Covertura pour la couverture de code. Répondre aux questions : ''Mais qu'est ce que la couverture de code ? En quoi c'est utile ?''<br />
# Ajouter au pom.xml les plugins pour la gestion du site et des rapports (Javadoc, tests unitaires, tags list (FIXME, TODO, ...), ...): http://maven.apache.org/plugins/maven-site-plugin/ et d'autres.<br />
<br />
===Bonus Track===<br />
<br />
====Clone SVN -> Git====<br />
<br />
Source: http://www.yterium.net/Migrer-un-projet-SVN-vers-GIT<br />
<br />
<pre><br />
# Cloner le dépôt SVN en dépôt Git (conservation historique)<br />
$ git svn clone svn://svn.code.sf.net/p/cron4j/code/trunk cron4j-original<br />
$ cd cron4j-original<br />
# Test compilation<br />
$ ant jar<br />
$ cd ..<br />
</pre><br />
<br />
====Préparation TAGL====<br />
<br />
<pre><br />
# Clone du dépôt TAGL<br />
$ git clone git@github.com:donsez/tagl.git<br />
$ cd tagl<br />
# "Fetch" du dépôt local cloné précédemment<br />
$ git fetch file://$(pwd)/../cron4j-original<br />
# Fusion de ce qui vient d'être fetché<br />
$ git merge FETCH_HEAD<br />
# Envoi sur le serveur<br />
$ git push<br />
</pre><br />
<br />
==Séance 2==<br />
@TODO<br />
<br />
==Séance 3==<br />
@TODO<br />
<br />
==Séance 4==<br />
@TODO</div>Calmanthttps://air.imag.fr/index.php?title=TAGL/TP&diff=15159TAGL/TP2014-02-06T11:04:35Z<p>Calmant: Ajout du Bonus Track</p>
<hr />
<div>==Séance 1==<br />
Créer un dépôt Git local (bare)<br />
<pre><br />
mkdir tagl<br />
cd tagl<br />
mkdir testgit<br />
cd testgit<br />
git init --bare<br />
cd ..<br />
git clone testgit testgit-work<br />
cd testgit-work<br />
echo hello > readme.rst<br />
git add readme.rst<br />
git commit<br />
git push<br />
</pre><br />
<br />
En parallèle : Installer dans votre Eclipse le plugin ReST Editor depuis le [https://marketplace.eclipse.org/content/rest-editor Marketplace Eclipse]<br />
<br />
<br />
Créer compte individuel sur GitHub https://github.com<br />
<br />
''Fork''er le projet TAGL (url) '''cron4j''' (2.5.5)<br />
<br />
Ajouter un collaborateur au projet ''forké''<br />
<br />
Activer le Email hook depuis les paramètres (settings) du dépôt.<br />
<br />
Activer le Travis-CI ''hook' depuis https://travis-ci.org/ (sign in avec le compte GitHub)<br />
<br />
''Commit/Push'' '''.travis.yml''' pour Ant (depuis un gist)<br />
<br />
<pre><br />
<br />
<br />
</pre><br />
<br />
<br />
Créer '''cron4j-mvn''' (layout + pom.xml)<br />
<br />
Modifier .travis.yml pour ''mvn -DskipTests=true clean install'' (Commit/Push)<br />
<br />
Tests unitaires du i.s.c.CronParser (Ajouter la dépendance JUnit 4 au pom.xml)<br />
<br />
Modifier '''.travis.yml''' pour ''mvn clean install'' (Commit/Push)<br />
<br />
===Contrôle Continu===<br />
# Ajouter au pom.xml le plugin Covertura pour la couverture de code. Répondre aux questions : ''Mais qu'est ce que la couverture de code ? En quoi c'est utile ?''<br />
# Ajouter au pom.xml les plugins pour la gestion du site et des rapports (Javadoc, tests unitaires, tags list (FIXME, TODO, ...), ...): http://maven.apache.org/plugins/maven-site-plugin/ et d'autres.<br />
<br />
===Bonus Track===<br />
<br />
====Clone SVN -> Git====<br />
<br />
Source: http://www.yterium.net/Migrer-un-projet-SVN-vers-GIT<br />
<br />
<pre><br />
# Cloner le dépôt SVN en dépôt Git (conservation historique)<br />
$ git svn clone svn://svn.code.sf.net/p/cron4j/code/trunk cron4j-original<br />
$ cd cron4j-original<br />
# Test compilation<br />
$ ant jar<br />
$ cd ..<br />
</pre><br />
<br />
Préparation TAGL<br />
================<br />
<br />
<pre><br />
# Clone du dépôt TAGL<br />
$ git clone git@github.com:donsez/tagl.git<br />
$ cd tagl<br />
# "Fetch" du dépôt local cloné précédemment<br />
$ git fetch file://$(pwd)/../cron4j-original<br />
# Fusion de ce qui vient d'être fetché<br />
$ git merge FETCH_HEAD<br />
# Envoi sur le serveur<br />
$ git push<br />
</pre><br />
<br />
==Séance 2==<br />
@TODO<br />
<br />
==Séance 3==<br />
@TODO<br />
<br />
==Séance 4==<br />
@TODO</div>Calmanthttps://air.imag.fr/index.php?title=Tutorial_OSGi_avec_Apache_Felix_-_Partie_2&diff=11328Tutorial OSGi avec Apache Felix - Partie 22013-04-19T08:59:25Z<p>Calmant: </p>
<hr />
<div>[[Tutorial OSGi avec Apache Felix|Revenir au sommaire]]<br />
<br />
=Sources du TP=<br />
<br />
[https://dl.dropboxusercontent.com/u/66952950/tposgi.zip sources du TP]<br />
<br />
=TP OSGi Partie 2 : Composants OSGi=<br />
<br />
Vous manipulerez [http://felix.apache.org/site/apache-felix-ipojo.html Apache iPOJO] le modèle de composant orienté service Java pour OSGi utilisé industrielement<br />
<br />
==Installation==<br />
<br />
* Dézipper les sources du TP<br />
* Changez '''EVENTUELLEMENT''' les valeurs du proxy dans le fichier tposgi\felix-framework\run.bat<br />
* <strike>Installez EVENTUELLEMENT osgi-part2\settings.xml dans C:\Documents and Settings\VotreUsername\.m2</strike><br />
* Demarrez Felix : <pre>cd felix<br />
run.bat</pre><br />
<br />
* Lancez les commandes du shell Gogo:<br />
** help<br />
** lb<br />
** obr:list<br />
** obr:deploy -s "Apache Felix Log Service"<br />
** felix:log debug<br />
** obr:deploy -s "Apache Felix iPOJO"<br />
** obr:deploy -s "Apache Felix iPOJO Gogo Command"<br />
** obr:deploy -s "Apache Felix File Install"<br />
** inspect requirement service<br />
** inspect r service<br />
** inspect capability service<br />
** inspect c service <br />
<br />
==Cron4j==<br />
<br />
<pre><br />
---------------<br />
Cron4J http://www.sauronsoftware.it/projects/cron4j/ est une bibliotheque java pour dÈclencher pÈriodiquement des taches.<br />
Elle est inspirée du cron Unix http://fr.wikipedia.org/wiki/Crontab.<br />
Les taches doivent implémenter l'interface java.lang.Runnable.<br />
Regardez les exemples fournis dans osgi-part2\cron4j\cron4j-orig\examples<br />
<br />
Votre travail est d'utiliser cette bibliotheque pour dÈclencher pÈriodiquement des services OSGi dont l'interface est java.lang.Runnable et la propriÈtÈ cron4j.pattern contient le pattern cron<br />
Voir le schÈma d'architecture osgi-part2\architecture.ppt<br />
<br />
1) Deployez les bundles Cron4J depuis le repository via FileInstall en les dÈposant dans le rÈpertoire .\load de l'installation de Felix<br />
cron4j-bundle-0.2.0-SNAPSHOT.jar<br />
cron4j-bundle.example-0.1.0.jar<br />
<br />
Que se passe t'il ?<br />
lb<br />
inspect c service<br />
inspect r service<br />
<br />
<br />
ipojo:factories<br />
ipojo:factory<br />
ipojo:handlers<br />
ipojo:instance<br />
ipojo:instances<br />
<br />
<br />
2) completer le code du projet cron4j-bundle pour qu'il schedule des services java.lang.Runnable<br />
Moins de 20 lignes de Java<br />
<br />
3) ajouter au composant iPOJO un requires http://felix.apache.org/site/service-requirement-handler.html vers un LogService et completer le code du composant pour journaliser les enreisgrements et desenregistrement de services <br />
(ie utiliser le LogService)<br />
<br />
inspect c service<br />
inspect r service<br />
<br />
4) transformez ce Requires en TemporalRequires<br />
Observez ce qu'il se passe quand le LogService disparait !<br />
<br />
inspect c service<br />
inspect r service<br />
<br />
5) Completez le composant iPOJO pour fournir une commande Gogo Shell listant les "schedules" en cours et leurs statitisques (nombre d'invocations, temps restant jusqu'a la prochaine invocation, nombre d'invocation restante, ...)<br />
Ce complement est livrÈe dans la version cron4j-bundle-0.3.0-SNAPSHOT.jar<br />
<br />
inspect c service<br />
inspect r service<br />
<br />
Inspirez vous du code de la commande Arch d'iPOJO (voir le repertoire cron4j-cmd)<br />
http://svn.apache.org/viewvc/felix/trunk/ipojo/arch-gogo/<br />
http://svn.apache.org/viewvc/felix/trunk/ipojo/arch-gogo/pom.xml?view=co<br />
http://svn.apache.org/viewvc/felix/trunk/ipojo/arch-gogo/src/main/java/org/apache/felix/ipojo/arch/gogo/Arch.java?view=co <br />
http://felix.apache.org/site/rfc-147-overview.html<br />
<br />
<br />
inspect c service<br />
inspect r service<br />
<br />
----------------<br />
Extra 1<br />
obr:deploy -s "Apache Felix iPOJO White Board Pattern Handler"<br />
obr:deploy -s "Apache Felix iPOJO Temporal Service Dependency Handler"<br />
<br />
obr:deploy -s "Apache Felix iPOJO WebConsole Plugins"<br />
browse http://localhost:8080/system/console/bundles<br />
Username=admin Password=admin<br />
<br />
----------------<br />
Extra 2<br />
Ajouter les metadonnÈes du handler JMX au composant TransientCronDeamon<br />
http://felix.apache.org/site/ipojo-jmx-handler.html<br />
<br />
Redeployez le bundle<br />
Lancez jconsole dans un shell/cmd<br />
Changez les propriÈtÈs du composant via la JConsole <br />
<br />
<br />
<br />
<br />
Minimal Gogo Command with iPOJO<br />
<br />
<br />
import org.apache.felix.ipojo.annotations.Component;<br />
import org.apache.felix.ipojo.annotations.Instantiate;<br />
import org.apache.felix.ipojo.annotations.Provides;<br />
import org.apache.felix.ipojo.annotations.ServiceProperty;<br />
import org.apache.felix.service.command.Descriptor;<br />
<br />
@Component(immediate = true)<br />
@Instantiate<br />
@Provides(specifications = ListComponentsCommand.class)<br />
public class ListComponentsCommand {<br />
<br />
@ServiceProperty(name = "osgi.command.scope", value = "test")<br />
String scope;<br />
<br />
@ServiceProperty(name = "osgi.command.function", value = "{}")<br />
String[] function = new String[] { "test" };<br />
<br />
@Descriptor("test")<br />
public void test() {<br />
System.out.println("test!");<br />
}<br />
<br />
<br />
<br />
<br />
<br />
</pre></div>Calmanthttps://air.imag.fr/index.php?title=Tutorial_OSGi_avec_Apache_Felix_-_Partie_1&diff=11327Tutorial OSGi avec Apache Felix - Partie 12013-04-19T08:50:44Z<p>Calmant: /* FileInstall */</p>
<hr />
<div>[[Tutorial OSGi avec Apache Felix|Revenir au sommaire]]<br />
<br />
<br />
<br />
=Installation et configuration=<br />
Telechargez la derniËre distribution de Felix depuis<br />
http://felix.apache.org/site/downloads.cgi<br />
<br />
DÈzippez la distribution dans le repertoire du TP<br />
<br />
Configurez les variables JAVA_HOME et PATH<br />
<br />
<pre><br />
set FELIX_VER=4.0.2<br />
set FELIX_HOME=felix-framework-%FELIX_VER%<br />
set JAVA_HOME=c:\Progra~1\Java\jre6<br />
set PATH=%JAVA_HOME%\bin;%PATH%<br />
java -version<br />
</pre><br />
<br />
<br />
<br />
creez les repertoires dans %FELIX_HOME%<br />
<pre><br />
mkdir %FELIX_HOME%\load<br />
mkdir %FELIX_HOME%\repository<br />
<br />
copy repository\*.* %FELIX_HOME%\repository<br />
copy run.bat %FELIX_HOME%<br />
</pre><br />
<br />
le fichier run.bat permet de lancer Felix avec le proxy HTTP configurÈ avec celui de l'UJF (www-cache.ujf-grenoble.fr:3128)<br />
<br />
Positionnez <br />
<pre><br />
cd %FELIX_HOME%<br />
</pre><br />
<br />
<br />
== Préparation pour HTTP Service ==<br />
<br />
Plus loin dans le TP, le service HTTP sera installé est devra utiliser un port réseau, par défaut 8080.<br />
Si ce port est déjà occupé par une autre application (tester avec un navigateur: http://localhost:8080/), il faut modifier le fichier <pre>conf/config.properties</pre> dans le dossier <pre>%FELIX_HOME%</pre>.<br />
<br />
À la fin du fichier, remplacer la ligne<br />
<pre><br />
org.osgi.service.http.port=8080<br />
</pre><br />
<br />
par<br />
<br />
<pre><br />
org.osgi.service.http.port=<numéro de port><br />
org.apache.felix.http.jettyEnabled=true<br />
</pre><br />
<br />
=Lancement de Felix=<br />
<br />
Si le proxy campus est actif:<br />
<br />
<pre><br />
run.bat<br />
</pre><br />
<br />
Sinon:<br />
<br />
<pre><br />
java -jar bin/felix.jar<br />
</pre><br />
<br />
=Premières commandes=<br />
Depuis le shell Gogo de Felix<br />
<pre><br />
help<br />
lb<br />
headers<br />
inspect capability osgi.wiring.package 0<br />
inspect requirement osgi.wiring.package 0<br />
inspect capability service 0<br />
inspect requirement service 0<br />
<br />
inspect c osgi.wiring.package 1<br />
inspect r osgi.wiring.package 1<br />
inspect c service 1<br />
inspect r service 1<br />
<br />
<br />
obr:deploy -s "Apache Felix Log Service"<br />
help log<br />
log debug<br />
log info<br />
log warn<br />
log error<br />
</pre><br />
<br />
=Deploiement de bundles=<br />
<pre><br />
install file:./repository/org.apache.felix.sandbox.mbean.shell.gogo-0.4.0.jar<br />
lb<br />
start 5<br />
inspect c osgi.wiring.package 5<br />
inspect r osgi.wiring.package 5<br />
inspect c service 5<br />
inspect r service 5<br />
<br />
update 5<br />
log debug<br />
<br />
<br />
install http://repo1.maven.org/maven2/org/apache/felix/org.apache.felix.http.jetty/1.0.1/org.apache.felix.http.jetty-1.0.1.jar<br />
log 1<br />
lb<br />
start 6<br />
uninstall 6<br />
</pre><br />
<br />
que se passe t'il et pourquoi ?<br />
<br />
=Changement du niveau d'execution=<br />
<pre><br />
lb<br />
help bundlelevel<br />
bundlelevel <OBR' bundle Id><br />
frameworklevel<br />
bundlelevel -s 2 <OBR' bundle Id><br />
log debug<br />
obr:list<br />
</pre><br />
<br />
que s'est il passÈ ?<br />
<br />
<pre><br />
frameworklevel 2<br />
log debug<br />
lb<br />
obr:list<br />
</pre><br />
<br />
<br />
que s'est il passÈ ?<br />
<br />
=Deployez et lancez la Web console via l'OBR=<br />
Qu'est que l'OBR ([[OSGi Bundle Repository]]) ?<br />
<br />
<pre><br />
obr:help<br />
obr:list<br />
obr:info "org.apache.felix.webconsole"<br />
obr:deploy -s "org.apache.felix.webconsole"<br />
lb<br />
<br />
obr:deploy -s "org.apache.felix.webconsole" "Apache Felix Web Console Event Plugin" "Apache Felix Web Console Memory Usage Plugin" "Apache Felix Web Console Service Diagnostics Plugin"<br />
lb<br />
<br />
obr:deploy -s "Apache Felix Web Console UPnP Plugin"<br />
(peux échouer)<br />
</pre><br />
<br />
<br />
Combien de bundles ont été déployés (installés et démarrés) ?<br />
<br />
naviguez http://localhost:8080/system/console depuis votre browser (username et password : admin et admin)<br />
<br />
Deployez File Install soit depuis la web console onglet "OSGi repository"<br />
soit avec la commande<br />
<pre><br />
obr:deploy -s "Apache Felix File Install"<br />
</pre><br />
<br />
=FileInstall=<br />
<br />
Deployez des bundles via FileInstall en copiant les jarfiles des bundles du répertoire .\repository vers .\load depuis un terminal<br />
<br />
Sous Windows:<br />
<pre><br />
copy .\repository\org.apache.felix.examples.managedservice-0.1.0-SNAPSHOT.jar .\load<br />
</pre><br />
<br />
Sous Linux:<br />
<pre><br />
copy ./repository/org.apache.felix.examples.managedservice-0.1.0-SNAPSHOT.jar ./load<br />
</pre><br />
<br />
Que s'est il passé ? (faire lb puis log 4)<br />
<br />
Supprimez le JAR file.<br />
<br />
Sous Windows:<br />
<pre><br />
del .\load\org.apache.felix.examples.managedservice-0.1.0-SNAPSHOT.jar<br />
</pre><br />
<br />
Sous Linux:<br />
<pre><br />
rm ./load/org.apache.felix.examples.managedservice-0.1.0-SNAPSHOT.jar<br />
</pre><br />
<br />
Que s'est il passé ? (faire lb puis log 4)</div>Calmanthttps://air.imag.fr/index.php?title=Tutorial_OSGi_avec_Apache_Felix_-_Partie_1&diff=11326Tutorial OSGi avec Apache Felix - Partie 12013-04-19T08:35:03Z<p>Calmant: /* Deploiement de bundles */</p>
<hr />
<div>[[Tutorial OSGi avec Apache Felix|Revenir au sommaire]]<br />
<br />
<br />
<br />
=Installation et configuration=<br />
Telechargez la derniËre distribution de Felix depuis<br />
http://felix.apache.org/site/downloads.cgi<br />
<br />
DÈzippez la distribution dans le repertoire du TP<br />
<br />
Configurez les variables JAVA_HOME et PATH<br />
<br />
<pre><br />
set FELIX_VER=4.0.2<br />
set FELIX_HOME=felix-framework-%FELIX_VER%<br />
set JAVA_HOME=c:\Progra~1\Java\jre6<br />
set PATH=%JAVA_HOME%\bin;%PATH%<br />
java -version<br />
</pre><br />
<br />
<br />
<br />
creez les repertoires dans %FELIX_HOME%<br />
<pre><br />
mkdir %FELIX_HOME%\load<br />
mkdir %FELIX_HOME%\repository<br />
<br />
copy repository\*.* %FELIX_HOME%\repository<br />
copy run.bat %FELIX_HOME%<br />
</pre><br />
<br />
le fichier run.bat permet de lancer Felix avec le proxy HTTP configurÈ avec celui de l'UJF (www-cache.ujf-grenoble.fr:3128)<br />
<br />
Positionnez <br />
<pre><br />
cd %FELIX_HOME%<br />
</pre><br />
<br />
<br />
== Préparation pour HTTP Service ==<br />
<br />
Plus loin dans le TP, le service HTTP sera installé est devra utiliser un port réseau, par défaut 8080.<br />
Si ce port est déjà occupé par une autre application (tester avec un navigateur: http://localhost:8080/), il faut modifier le fichier <pre>conf/config.properties</pre> dans le dossier <pre>%FELIX_HOME%</pre>.<br />
<br />
À la fin du fichier, remplacer la ligne<br />
<pre><br />
org.osgi.service.http.port=8080<br />
</pre><br />
<br />
par<br />
<br />
<pre><br />
org.osgi.service.http.port=<numéro de port><br />
org.apache.felix.http.jettyEnabled=true<br />
</pre><br />
<br />
=Lancement de Felix=<br />
<br />
Si le proxy campus est actif:<br />
<br />
<pre><br />
run.bat<br />
</pre><br />
<br />
Sinon:<br />
<br />
<pre><br />
java -jar bin/felix.jar<br />
</pre><br />
<br />
=Premières commandes=<br />
Depuis le shell Gogo de Felix<br />
<pre><br />
help<br />
lb<br />
headers<br />
inspect capability osgi.wiring.package 0<br />
inspect requirement osgi.wiring.package 0<br />
inspect capability service 0<br />
inspect requirement service 0<br />
<br />
inspect c osgi.wiring.package 1<br />
inspect r osgi.wiring.package 1<br />
inspect c service 1<br />
inspect r service 1<br />
<br />
<br />
obr:deploy -s "Apache Felix Log Service"<br />
help log<br />
log debug<br />
log info<br />
log warn<br />
log error<br />
</pre><br />
<br />
=Deploiement de bundles=<br />
<pre><br />
install file:./repository/org.apache.felix.sandbox.mbean.shell.gogo-0.4.0.jar<br />
lb<br />
start 5<br />
inspect c osgi.wiring.package 5<br />
inspect r osgi.wiring.package 5<br />
inspect c service 5<br />
inspect r service 5<br />
<br />
update 5<br />
log debug<br />
<br />
<br />
install http://repo1.maven.org/maven2/org/apache/felix/org.apache.felix.http.jetty/1.0.1/org.apache.felix.http.jetty-1.0.1.jar<br />
log 1<br />
lb<br />
start 6<br />
uninstall 6<br />
</pre><br />
<br />
que se passe t'il et pourquoi ?<br />
<br />
=Changement du niveau d'execution=<br />
<pre><br />
lb<br />
help bundlelevel<br />
bundlelevel <OBR' bundle Id><br />
frameworklevel<br />
bundlelevel -s 2 <OBR' bundle Id><br />
log debug<br />
obr:list<br />
</pre><br />
<br />
que s'est il passÈ ?<br />
<br />
<pre><br />
frameworklevel 2<br />
log debug<br />
lb<br />
obr:list<br />
</pre><br />
<br />
<br />
que s'est il passÈ ?<br />
<br />
=Deployez et lancez la Web console via l'OBR=<br />
Qu'est que l'OBR ([[OSGi Bundle Repository]]) ?<br />
<br />
<pre><br />
obr:help<br />
obr:list<br />
obr:info "org.apache.felix.webconsole"<br />
obr:deploy -s "org.apache.felix.webconsole"<br />
lb<br />
<br />
obr:deploy -s "org.apache.felix.webconsole" "Apache Felix Web Console Event Plugin" "Apache Felix Web Console Memory Usage Plugin" "Apache Felix Web Console Service Diagnostics Plugin"<br />
lb<br />
<br />
obr:deploy -s "Apache Felix Web Console UPnP Plugin"<br />
(peux échouer)<br />
</pre><br />
<br />
<br />
Combien de bundles ont été déployés (installés et démarrés) ?<br />
<br />
naviguez http://localhost:8080/system/console depuis votre browser (username et password : admin et admin)<br />
<br />
Deployez File Install soit depuis la web console onglet "OSGi repository"<br />
soit avec la commande<br />
<pre><br />
obr:deploy -s "Apache Felix File Install"<br />
</pre><br />
<br />
=FileInstall=<br />
Deployez des bundles via FileInstall en copiant les jarfiles des bundles du rÈpertoires .\repertoire vers .\load depuis un cmd DOS<br />
copy .\repository\org.apache.felix.examples.managedservice-0.1.0-SNAPSHOT.jar .\load<br />
Que s'est il passÈ ? (faire lb puis log 4)<br />
<br />
del .\load\org.apache.felix.examples.managedservice-0.1.0-SNAPSHOT.jar<br />
Que s'est il passÈ ? (faire lb puis log 4)</div>Calmanthttps://air.imag.fr/index.php?title=Tutorial_OSGi_avec_Apache_Felix_-_Partie_1&diff=11325Tutorial OSGi avec Apache Felix - Partie 12013-04-19T08:30:35Z<p>Calmant: /* Deployez et lancez la Web console via l'OBR */</p>
<hr />
<div>[[Tutorial OSGi avec Apache Felix|Revenir au sommaire]]<br />
<br />
<br />
<br />
=Installation et configuration=<br />
Telechargez la derniËre distribution de Felix depuis<br />
http://felix.apache.org/site/downloads.cgi<br />
<br />
DÈzippez la distribution dans le repertoire du TP<br />
<br />
Configurez les variables JAVA_HOME et PATH<br />
<br />
<pre><br />
set FELIX_VER=4.0.2<br />
set FELIX_HOME=felix-framework-%FELIX_VER%<br />
set JAVA_HOME=c:\Progra~1\Java\jre6<br />
set PATH=%JAVA_HOME%\bin;%PATH%<br />
java -version<br />
</pre><br />
<br />
<br />
<br />
creez les repertoires dans %FELIX_HOME%<br />
<pre><br />
mkdir %FELIX_HOME%\load<br />
mkdir %FELIX_HOME%\repository<br />
<br />
copy repository\*.* %FELIX_HOME%\repository<br />
copy run.bat %FELIX_HOME%<br />
</pre><br />
<br />
le fichier run.bat permet de lancer Felix avec le proxy HTTP configurÈ avec celui de l'UJF (www-cache.ujf-grenoble.fr:3128)<br />
<br />
Positionnez <br />
<pre><br />
cd %FELIX_HOME%<br />
</pre><br />
<br />
<br />
== Préparation pour HTTP Service ==<br />
<br />
Plus loin dans le TP, le service HTTP sera installé est devra utiliser un port réseau, par défaut 8080.<br />
Si ce port est déjà occupé par une autre application (tester avec un navigateur: http://localhost:8080/), il faut modifier le fichier <pre>conf/config.properties</pre> dans le dossier <pre>%FELIX_HOME%</pre>.<br />
<br />
À la fin du fichier, remplacer la ligne<br />
<pre><br />
org.osgi.service.http.port=8080<br />
</pre><br />
<br />
par<br />
<br />
<pre><br />
org.osgi.service.http.port=<numéro de port><br />
org.apache.felix.http.jettyEnabled=true<br />
</pre><br />
<br />
=Lancement de Felix=<br />
<br />
Si le proxy campus est actif:<br />
<br />
<pre><br />
run.bat<br />
</pre><br />
<br />
Sinon:<br />
<br />
<pre><br />
java -jar bin/felix.jar<br />
</pre><br />
<br />
=Premières commandes=<br />
Depuis le shell Gogo de Felix<br />
<pre><br />
help<br />
lb<br />
headers<br />
inspect capability osgi.wiring.package 0<br />
inspect requirement osgi.wiring.package 0<br />
inspect capability service 0<br />
inspect requirement service 0<br />
<br />
inspect c osgi.wiring.package 1<br />
inspect r osgi.wiring.package 1<br />
inspect c service 1<br />
inspect r service 1<br />
<br />
<br />
obr:deploy -s "Apache Felix Log Service"<br />
help log<br />
log debug<br />
log info<br />
log warn<br />
log error<br />
</pre><br />
<br />
=Deploiement de bundles=<br />
<pre><br />
install file:./repository/org.apache.felix.sandbox.mbean.shell.felix.gogo-0.4.0.jar<br />
lb<br />
start 5<br />
inspect c osgi.wiring.package 5<br />
inspect r osgi.wiring.package 5<br />
inspect c service 5<br />
inspect r service 5<br />
<br />
update 5<br />
log debug<br />
<br />
<br />
install http://repo1.maven.org/maven2/org/apache/felix/org.apache.felix.http.jetty/1.0.1/org.apache.felix.http.jetty-1.0.1.jar<br />
log 1<br />
lb<br />
start 6<br />
uninstall 6<br />
</pre><br />
<br />
que se passe t'il et pourquoi ?<br />
<br />
=Changement du niveau d'execution=<br />
<pre><br />
lb<br />
help bundlelevel<br />
bundlelevel <OBR' bundle Id><br />
frameworklevel<br />
bundlelevel -s 2 <OBR' bundle Id><br />
log debug<br />
obr:list<br />
</pre><br />
<br />
que s'est il passÈ ?<br />
<br />
<pre><br />
frameworklevel 2<br />
log debug<br />
lb<br />
obr:list<br />
</pre><br />
<br />
<br />
que s'est il passÈ ?<br />
<br />
=Deployez et lancez la Web console via l'OBR=<br />
Qu'est que l'OBR ([[OSGi Bundle Repository]]) ?<br />
<br />
<pre><br />
obr:help<br />
obr:list<br />
obr:info "org.apache.felix.webconsole"<br />
obr:deploy -s "org.apache.felix.webconsole"<br />
lb<br />
<br />
obr:deploy -s "org.apache.felix.webconsole" "Apache Felix Web Console Event Plugin" "Apache Felix Web Console Memory Usage Plugin" "Apache Felix Web Console Service Diagnostics Plugin"<br />
lb<br />
<br />
obr:deploy -s "Apache Felix Web Console UPnP Plugin"<br />
(peux échouer)<br />
</pre><br />
<br />
<br />
Combien de bundles ont été déployés (installés et démarrés) ?<br />
<br />
naviguez http://localhost:8080/system/console depuis votre browser (username et password : admin et admin)<br />
<br />
Deployez File Install soit depuis la web console onglet "OSGi repository"<br />
soit avec la commande<br />
<pre><br />
obr:deploy -s "Apache Felix File Install"<br />
</pre><br />
<br />
=FileInstall=<br />
Deployez des bundles via FileInstall en copiant les jarfiles des bundles du rÈpertoires .\repertoire vers .\load depuis un cmd DOS<br />
copy .\repository\org.apache.felix.examples.managedservice-0.1.0-SNAPSHOT.jar .\load<br />
Que s'est il passÈ ? (faire lb puis log 4)<br />
<br />
del .\load\org.apache.felix.examples.managedservice-0.1.0-SNAPSHOT.jar<br />
Que s'est il passÈ ? (faire lb puis log 4)</div>Calmanthttps://air.imag.fr/index.php?title=Tutorial_OSGi_avec_Apache_Felix_-_Partie_1&diff=11324Tutorial OSGi avec Apache Felix - Partie 12013-04-19T08:25:59Z<p>Calmant: /* Installation et configuration */</p>
<hr />
<div>[[Tutorial OSGi avec Apache Felix|Revenir au sommaire]]<br />
<br />
<br />
<br />
=Installation et configuration=<br />
Telechargez la derniËre distribution de Felix depuis<br />
http://felix.apache.org/site/downloads.cgi<br />
<br />
DÈzippez la distribution dans le repertoire du TP<br />
<br />
Configurez les variables JAVA_HOME et PATH<br />
<br />
<pre><br />
set FELIX_VER=4.0.2<br />
set FELIX_HOME=felix-framework-%FELIX_VER%<br />
set JAVA_HOME=c:\Progra~1\Java\jre6<br />
set PATH=%JAVA_HOME%\bin;%PATH%<br />
java -version<br />
</pre><br />
<br />
<br />
<br />
creez les repertoires dans %FELIX_HOME%<br />
<pre><br />
mkdir %FELIX_HOME%\load<br />
mkdir %FELIX_HOME%\repository<br />
<br />
copy repository\*.* %FELIX_HOME%\repository<br />
copy run.bat %FELIX_HOME%<br />
</pre><br />
<br />
le fichier run.bat permet de lancer Felix avec le proxy HTTP configurÈ avec celui de l'UJF (www-cache.ujf-grenoble.fr:3128)<br />
<br />
Positionnez <br />
<pre><br />
cd %FELIX_HOME%<br />
</pre><br />
<br />
<br />
== Préparation pour HTTP Service ==<br />
<br />
Plus loin dans le TP, le service HTTP sera installé est devra utiliser un port réseau, par défaut 8080.<br />
Si ce port est déjà occupé par une autre application (tester avec un navigateur: http://localhost:8080/), il faut modifier le fichier <pre>conf/config.properties</pre> dans le dossier <pre>%FELIX_HOME%</pre>.<br />
<br />
À la fin du fichier, remplacer la ligne<br />
<pre><br />
org.osgi.service.http.port=8080<br />
</pre><br />
<br />
par<br />
<br />
<pre><br />
org.osgi.service.http.port=<numéro de port><br />
org.apache.felix.http.jettyEnabled=true<br />
</pre><br />
<br />
=Lancement de Felix=<br />
<br />
Si le proxy campus est actif:<br />
<br />
<pre><br />
run.bat<br />
</pre><br />
<br />
Sinon:<br />
<br />
<pre><br />
java -jar bin/felix.jar<br />
</pre><br />
<br />
=Premières commandes=<br />
Depuis le shell Gogo de Felix<br />
<pre><br />
help<br />
lb<br />
headers<br />
inspect capability osgi.wiring.package 0<br />
inspect requirement osgi.wiring.package 0<br />
inspect capability service 0<br />
inspect requirement service 0<br />
<br />
inspect c osgi.wiring.package 1<br />
inspect r osgi.wiring.package 1<br />
inspect c service 1<br />
inspect r service 1<br />
<br />
<br />
obr:deploy -s "Apache Felix Log Service"<br />
help log<br />
log debug<br />
log info<br />
log warn<br />
log error<br />
</pre><br />
<br />
=Deploiement de bundles=<br />
<pre><br />
install file:./repository/org.apache.felix.sandbox.mbean.shell.felix.gogo-0.4.0.jar<br />
lb<br />
start 5<br />
inspect c osgi.wiring.package 5<br />
inspect r osgi.wiring.package 5<br />
inspect c service 5<br />
inspect r service 5<br />
<br />
update 5<br />
log debug<br />
<br />
<br />
install http://repo1.maven.org/maven2/org/apache/felix/org.apache.felix.http.jetty/1.0.1/org.apache.felix.http.jetty-1.0.1.jar<br />
log 1<br />
lb<br />
start 6<br />
uninstall 6<br />
</pre><br />
<br />
que se passe t'il et pourquoi ?<br />
<br />
=Changement du niveau d'execution=<br />
<pre><br />
lb<br />
help bundlelevel<br />
bundlelevel <OBR' bundle Id><br />
frameworklevel<br />
bundlelevel -s 2 <OBR' bundle Id><br />
log debug<br />
obr:list<br />
</pre><br />
<br />
que s'est il passÈ ?<br />
<br />
<pre><br />
frameworklevel 2<br />
log debug<br />
lb<br />
obr:list<br />
</pre><br />
<br />
<br />
que s'est il passÈ ?<br />
<br />
=Deployez et lancez la Web console via l'OBR=<br />
Qu'est que l'OBR ([[OSGi Bundle Repository]]) ?<br />
<br />
<pre><br />
obr:help<br />
obr:list<br />
obr:info "org.apache.felix.webconsole"<br />
obr:deploy -s "org.apache.felix.webconsole"<br />
lb<br />
<br />
obr:deploy -s "org.apache.felix.webconsole" "Apache Felix Web Console Event Plugin" "Apache Felix Web Console Memory Usage Plugin" "Apache Felix Web Console Service Diagnostics Plugin"<br />
lb<br />
<br />
obr:deploy -s "Apache Felix Web Console UPnP Plugin"<br />
(peux échouer)<br />
</pre><br />
<br />
<br />
Combien de bundles ont été déployés (installés et démarrés) ?<br />
<br />
naviguez http://localhost:8080/system/console depuis votre browser (username et password : admin et admin)<br />
<br />
Deployez File Install soit depuis la web console onglet "OSGi repository"<br />
soit avec la commande<br />
<pre><br />
obr:deploy -start "Apache Felix File Install"<br />
</pre><br />
<br />
=FileInstall=<br />
Deployez des bundles via FileInstall en copiant les jarfiles des bundles du rÈpertoires .\repertoire vers .\load depuis un cmd DOS<br />
copy .\repository\org.apache.felix.examples.managedservice-0.1.0-SNAPSHOT.jar .\load<br />
Que s'est il passÈ ? (faire lb puis log 4)<br />
<br />
del .\load\org.apache.felix.examples.managedservice-0.1.0-SNAPSHOT.jar<br />
Que s'est il passÈ ? (faire lb puis log 4)</div>Calmanthttps://air.imag.fr/index.php?title=Tutorial_OSGi_avec_Apache_Felix_-_Partie_1&diff=11323Tutorial OSGi avec Apache Felix - Partie 12013-04-19T08:15:12Z<p>Calmant: /* Deployez et lancez la Web console via l'OBR */</p>
<hr />
<div>[[Tutorial OSGi avec Apache Felix|Revenir au sommaire]]<br />
<br />
<br />
<br />
=Installation et configuration=<br />
Telechargez la derniËre distribution de Felix depuis<br />
http://felix.apache.org/site/downloads.cgi<br />
<br />
DÈzippez la distribution dans le repertoire du TP<br />
<br />
Configurez les variables JAVA_HOME et PATH<br />
<br />
<pre><br />
set FELIX_VER=4.0.2<br />
set FELIX_HOME=felix-framework-%FELIX_VER%<br />
set JAVA_HOME=c:\Progra~1\Java\jre6<br />
set PATH=%JAVA_HOME%\bin;%PATH%<br />
java -version<br />
</pre><br />
<br />
<br />
<br />
creez les repertoires dans %FELIX_HOME%<br />
<pre><br />
mkdir %FELIX_HOME%\load<br />
mkdir %FELIX_HOME%\repository<br />
<br />
copy repository\*.* %FELIX_HOME%\repository<br />
copy run.bat %FELIX_HOME%<br />
</pre><br />
<br />
le fichier run.bat permet de lancer Felix avec le proxy HTTP configurÈ avec celui de l'UJF (www-cache.ujf-grenoble.fr:3128)<br />
<br />
Positionnez <br />
<pre><br />
cd %FELIX_HOME%<br />
</pre><br />
<br />
=Lancement de Felix=<br />
<br />
Si le proxy campus est actif:<br />
<br />
<pre><br />
run.bat<br />
</pre><br />
<br />
Sinon:<br />
<br />
<pre><br />
java -jar bin/felix.jar<br />
</pre><br />
<br />
=Premières commandes=<br />
Depuis le shell Gogo de Felix<br />
<pre><br />
help<br />
lb<br />
headers<br />
inspect capability osgi.wiring.package 0<br />
inspect requirement osgi.wiring.package 0<br />
inspect capability service 0<br />
inspect requirement service 0<br />
<br />
inspect c osgi.wiring.package 1<br />
inspect r osgi.wiring.package 1<br />
inspect c service 1<br />
inspect r service 1<br />
<br />
<br />
obr:deploy -s "Apache Felix Log Service"<br />
help log<br />
log debug<br />
log info<br />
log warn<br />
log error<br />
</pre><br />
<br />
=Deploiement de bundles=<br />
<pre><br />
install file:./repository/org.apache.felix.sandbox.mbean.shell.felix.gogo-0.4.0.jar<br />
lb<br />
start 5<br />
inspect c osgi.wiring.package 5<br />
inspect r osgi.wiring.package 5<br />
inspect c service 5<br />
inspect r service 5<br />
<br />
update 5<br />
log debug<br />
<br />
<br />
install http://repo1.maven.org/maven2/org/apache/felix/org.apache.felix.http.jetty/1.0.1/org.apache.felix.http.jetty-1.0.1.jar<br />
log 1<br />
lb<br />
start 6<br />
uninstall 6<br />
</pre><br />
<br />
que se passe t'il et pourquoi ?<br />
<br />
=Changement du niveau d'execution=<br />
<pre><br />
lb<br />
help bundlelevel<br />
bundlelevel <OBR' bundle Id><br />
frameworklevel<br />
bundlelevel -s 2 <OBR' bundle Id><br />
log debug<br />
obr:list<br />
</pre><br />
<br />
que s'est il passÈ ?<br />
<br />
<pre><br />
frameworklevel 2<br />
log debug<br />
lb<br />
obr:list<br />
</pre><br />
<br />
<br />
que s'est il passÈ ?<br />
<br />
=Deployez et lancez la Web console via l'OBR=<br />
Qu'est que l'OBR ([[OSGi Bundle Repository]]) ?<br />
<br />
<pre><br />
obr:help<br />
obr:list<br />
obr:info "org.apache.felix.webconsole"<br />
obr:deploy -s "org.apache.felix.webconsole"<br />
lb<br />
<br />
obr:deploy -s "org.apache.felix.webconsole" "Apache Felix Web Console Event Plugin" "Apache Felix Web Console Memory Usage Plugin" "Apache Felix Web Console Service Diagnostics Plugin"<br />
lb<br />
<br />
obr:deploy -s "Apache Felix Web Console UPnP Plugin"<br />
(peux échouer)<br />
</pre><br />
<br />
<br />
Combien de bundles ont été déployés (installés et démarrés) ?<br />
<br />
naviguez http://localhost:8080/system/console depuis votre browser (username et password : admin et admin)<br />
<br />
Deployez File Install soit depuis la web console onglet "OSGi repository"<br />
soit avec la commande<br />
<pre><br />
obr:deploy -start "Apache Felix File Install"<br />
</pre><br />
<br />
=FileInstall=<br />
Deployez des bundles via FileInstall en copiant les jarfiles des bundles du rÈpertoires .\repertoire vers .\load depuis un cmd DOS<br />
copy .\repository\org.apache.felix.examples.managedservice-0.1.0-SNAPSHOT.jar .\load<br />
Que s'est il passÈ ? (faire lb puis log 4)<br />
<br />
del .\load\org.apache.felix.examples.managedservice-0.1.0-SNAPSHOT.jar<br />
Que s'est il passÈ ? (faire lb puis log 4)</div>Calmanthttps://air.imag.fr/index.php?title=Tutorial_OSGi_avec_Apache_Felix_-_Partie_1&diff=11322Tutorial OSGi avec Apache Felix - Partie 12013-04-19T07:51:15Z<p>Calmant: /* Lancement de Felix */</p>
<hr />
<div>[[Tutorial OSGi avec Apache Felix|Revenir au sommaire]]<br />
<br />
<br />
<br />
=Installation et configuration=<br />
Telechargez la derniËre distribution de Felix depuis<br />
http://felix.apache.org/site/downloads.cgi<br />
<br />
DÈzippez la distribution dans le repertoire du TP<br />
<br />
Configurez les variables JAVA_HOME et PATH<br />
<br />
<pre><br />
set FELIX_VER=4.0.2<br />
set FELIX_HOME=felix-framework-%FELIX_VER%<br />
set JAVA_HOME=c:\Progra~1\Java\jre6<br />
set PATH=%JAVA_HOME%\bin;%PATH%<br />
java -version<br />
</pre><br />
<br />
<br />
<br />
creez les repertoires dans %FELIX_HOME%<br />
<pre><br />
mkdir %FELIX_HOME%\load<br />
mkdir %FELIX_HOME%\repository<br />
<br />
copy repository\*.* %FELIX_HOME%\repository<br />
copy run.bat %FELIX_HOME%<br />
</pre><br />
<br />
le fichier run.bat permet de lancer Felix avec le proxy HTTP configurÈ avec celui de l'UJF (www-cache.ujf-grenoble.fr:3128)<br />
<br />
Positionnez <br />
<pre><br />
cd %FELIX_HOME%<br />
</pre><br />
<br />
=Lancement de Felix=<br />
<br />
Si le proxy campus est actif:<br />
<br />
<pre><br />
run.bat<br />
</pre><br />
<br />
Sinon:<br />
<br />
<pre><br />
java -jar bin/felix.jar<br />
</pre><br />
<br />
=Premières commandes=<br />
Depuis le shell Gogo de Felix<br />
<pre><br />
help<br />
lb<br />
headers<br />
inspect capability osgi.wiring.package 0<br />
inspect requirement osgi.wiring.package 0<br />
inspect capability service 0<br />
inspect requirement service 0<br />
<br />
inspect c osgi.wiring.package 1<br />
inspect r osgi.wiring.package 1<br />
inspect c service 1<br />
inspect r service 1<br />
<br />
<br />
obr:deploy -s "Apache Felix Log Service"<br />
help log<br />
log debug<br />
log info<br />
log warn<br />
log error<br />
</pre><br />
<br />
=Deploiement de bundles=<br />
<pre><br />
install file:./repository/org.apache.felix.sandbox.mbean.shell.felix.gogo-0.4.0.jar<br />
lb<br />
start 5<br />
inspect c osgi.wiring.package 5<br />
inspect r osgi.wiring.package 5<br />
inspect c service 5<br />
inspect r service 5<br />
<br />
update 5<br />
log debug<br />
<br />
<br />
install http://repo1.maven.org/maven2/org/apache/felix/org.apache.felix.http.jetty/1.0.1/org.apache.felix.http.jetty-1.0.1.jar<br />
log 1<br />
lb<br />
start 6<br />
uninstall 6<br />
</pre><br />
<br />
que se passe t'il et pourquoi ?<br />
<br />
=Changement du niveau d'execution=<br />
<pre><br />
lb<br />
help bundlelevel<br />
bundlelevel <OBR' bundle Id><br />
frameworklevel<br />
bundlelevel -s 2 <OBR' bundle Id><br />
log debug<br />
obr:list<br />
</pre><br />
<br />
que s'est il passÈ ?<br />
<br />
<pre><br />
frameworklevel 2<br />
log debug<br />
lb<br />
obr:list<br />
</pre><br />
<br />
<br />
que s'est il passÈ ?<br />
<br />
=Deployez et lancez la Web console via l'OBR=<br />
Qu'est que l'OBR ([[OSGi Bundle Repository]]) ?<br />
<br />
<pre><br />
obr:help<br />
obr:list<br />
obr:info "Apache Felix Web Management Console"<br />
obr:deploy -s "Apache Felix Web Management Console"<br />
lb<br />
<br />
obr:deploy -s "Apache Felix Web Management Console" "Apache Felix Web Console Event Plugin" "Apache Felix Web Console Memory Usage Plugin" "Apache Felix Web Console Service Diagnostics Plugin" "Apache Felix Web Console UPnP Plugin"<br />
lb<br />
</pre><br />
<br />
<br />
Combien de bundles ont ÈtÈ dÈployÈs (installÈs et dÈmarrÈs) ?<br />
<br />
naviguez http://localhost:8080/system/console depuis votre browser (username et password : admin et admin)<br />
<br />
Deployez File Install soit depuis la web console onglet "OSGi repository"<br />
soit avec la commande<br />
<pre><br />
obr:deploy -start "Apache Felix File Install"<br />
</pre><br />
<br />
=FileInstall=<br />
Deployez des bundles via FileInstall en copiant les jarfiles des bundles du rÈpertoires .\repertoire vers .\load depuis un cmd DOS<br />
copy .\repository\org.apache.felix.examples.managedservice-0.1.0-SNAPSHOT.jar .\load<br />
Que s'est il passÈ ? (faire lb puis log 4)<br />
<br />
del .\load\org.apache.felix.examples.managedservice-0.1.0-SNAPSHOT.jar<br />
Que s'est il passÈ ? (faire lb puis log 4)</div>Calmanthttps://air.imag.fr/index.php?title=Tutorial_OSGi_avec_Apache_Felix_-_Partie_1&diff=11321Tutorial OSGi avec Apache Felix - Partie 12013-04-19T07:50:29Z<p>Calmant: /* PremiËres commandes */</p>
<hr />
<div>[[Tutorial OSGi avec Apache Felix|Revenir au sommaire]]<br />
<br />
<br />
<br />
=Installation et configuration=<br />
Telechargez la derniËre distribution de Felix depuis<br />
http://felix.apache.org/site/downloads.cgi<br />
<br />
DÈzippez la distribution dans le repertoire du TP<br />
<br />
Configurez les variables JAVA_HOME et PATH<br />
<br />
<pre><br />
set FELIX_VER=4.0.2<br />
set FELIX_HOME=felix-framework-%FELIX_VER%<br />
set JAVA_HOME=c:\Progra~1\Java\jre6<br />
set PATH=%JAVA_HOME%\bin;%PATH%<br />
java -version<br />
</pre><br />
<br />
<br />
<br />
creez les repertoires dans %FELIX_HOME%<br />
<pre><br />
mkdir %FELIX_HOME%\load<br />
mkdir %FELIX_HOME%\repository<br />
<br />
copy repository\*.* %FELIX_HOME%\repository<br />
copy run.bat %FELIX_HOME%<br />
</pre><br />
<br />
le fichier run.bat permet de lancer Felix avec le proxy HTTP configurÈ avec celui de l'UJF (www-cache.ujf-grenoble.fr:3128)<br />
<br />
Positionnez <br />
<pre><br />
cd %FELIX_HOME%<br />
</pre><br />
<br />
=Lancement de Felix=<br />
<pre><br />
run.bat<br />
</pre><br />
<br />
=Premières commandes=<br />
Depuis le shell Gogo de Felix<br />
<pre><br />
help<br />
lb<br />
headers<br />
inspect capability osgi.wiring.package 0<br />
inspect requirement osgi.wiring.package 0<br />
inspect capability service 0<br />
inspect requirement service 0<br />
<br />
inspect c osgi.wiring.package 1<br />
inspect r osgi.wiring.package 1<br />
inspect c service 1<br />
inspect r service 1<br />
<br />
<br />
obr:deploy -s "Apache Felix Log Service"<br />
help log<br />
log debug<br />
log info<br />
log warn<br />
log error<br />
</pre><br />
<br />
=Deploiement de bundles=<br />
<pre><br />
install file:./repository/org.apache.felix.sandbox.mbean.shell.felix.gogo-0.4.0.jar<br />
lb<br />
start 5<br />
inspect c osgi.wiring.package 5<br />
inspect r osgi.wiring.package 5<br />
inspect c service 5<br />
inspect r service 5<br />
<br />
update 5<br />
log debug<br />
<br />
<br />
install http://repo1.maven.org/maven2/org/apache/felix/org.apache.felix.http.jetty/1.0.1/org.apache.felix.http.jetty-1.0.1.jar<br />
log 1<br />
lb<br />
start 6<br />
uninstall 6<br />
</pre><br />
<br />
que se passe t'il et pourquoi ?<br />
<br />
=Changement du niveau d'execution=<br />
<pre><br />
lb<br />
help bundlelevel<br />
bundlelevel <OBR' bundle Id><br />
frameworklevel<br />
bundlelevel -s 2 <OBR' bundle Id><br />
log debug<br />
obr:list<br />
</pre><br />
<br />
que s'est il passÈ ?<br />
<br />
<pre><br />
frameworklevel 2<br />
log debug<br />
lb<br />
obr:list<br />
</pre><br />
<br />
<br />
que s'est il passÈ ?<br />
<br />
=Deployez et lancez la Web console via l'OBR=<br />
Qu'est que l'OBR ([[OSGi Bundle Repository]]) ?<br />
<br />
<pre><br />
obr:help<br />
obr:list<br />
obr:info "Apache Felix Web Management Console"<br />
obr:deploy -s "Apache Felix Web Management Console"<br />
lb<br />
<br />
obr:deploy -s "Apache Felix Web Management Console" "Apache Felix Web Console Event Plugin" "Apache Felix Web Console Memory Usage Plugin" "Apache Felix Web Console Service Diagnostics Plugin" "Apache Felix Web Console UPnP Plugin"<br />
lb<br />
</pre><br />
<br />
<br />
Combien de bundles ont ÈtÈ dÈployÈs (installÈs et dÈmarrÈs) ?<br />
<br />
naviguez http://localhost:8080/system/console depuis votre browser (username et password : admin et admin)<br />
<br />
Deployez File Install soit depuis la web console onglet "OSGi repository"<br />
soit avec la commande<br />
<pre><br />
obr:deploy -start "Apache Felix File Install"<br />
</pre><br />
<br />
=FileInstall=<br />
Deployez des bundles via FileInstall en copiant les jarfiles des bundles du rÈpertoires .\repertoire vers .\load depuis un cmd DOS<br />
copy .\repository\org.apache.felix.examples.managedservice-0.1.0-SNAPSHOT.jar .\load<br />
Que s'est il passÈ ? (faire lb puis log 4)<br />
<br />
del .\load\org.apache.felix.examples.managedservice-0.1.0-SNAPSHOT.jar<br />
Que s'est il passÈ ? (faire lb puis log 4)</div>Calmanthttps://air.imag.fr/index.php?title=Tutorial_OSGi_avec_Apache_Felix_-_Partie_1&diff=11320Tutorial OSGi avec Apache Felix - Partie 12013-04-19T07:49:13Z<p>Calmant: /* PremiËres commandes */</p>
<hr />
<div>[[Tutorial OSGi avec Apache Felix|Revenir au sommaire]]<br />
<br />
<br />
<br />
=Installation et configuration=<br />
Telechargez la derniËre distribution de Felix depuis<br />
http://felix.apache.org/site/downloads.cgi<br />
<br />
DÈzippez la distribution dans le repertoire du TP<br />
<br />
Configurez les variables JAVA_HOME et PATH<br />
<br />
<pre><br />
set FELIX_VER=4.0.2<br />
set FELIX_HOME=felix-framework-%FELIX_VER%<br />
set JAVA_HOME=c:\Progra~1\Java\jre6<br />
set PATH=%JAVA_HOME%\bin;%PATH%<br />
java -version<br />
</pre><br />
<br />
<br />
<br />
creez les repertoires dans %FELIX_HOME%<br />
<pre><br />
mkdir %FELIX_HOME%\load<br />
mkdir %FELIX_HOME%\repository<br />
<br />
copy repository\*.* %FELIX_HOME%\repository<br />
copy run.bat %FELIX_HOME%<br />
</pre><br />
<br />
le fichier run.bat permet de lancer Felix avec le proxy HTTP configurÈ avec celui de l'UJF (www-cache.ujf-grenoble.fr:3128)<br />
<br />
Positionnez <br />
<pre><br />
cd %FELIX_HOME%<br />
</pre><br />
<br />
=Lancement de Felix=<br />
<pre><br />
run.bat<br />
</pre><br />
<br />
=PremiËres commandes=<br />
Depuis le shell Gogo de Felix<br />
<pre><br />
help<br />
lb<br />
headers<br />
inspect capability osgi.wiring.package 0<br />
inspect requirement osgi.wiring.package 0<br />
inspect capability service 0<br />
inspect requirement service 0<br />
<br />
inspect c osgi.wiring.package 1<br />
inspect r osgi.wiring.package 1<br />
inspect c service 1<br />
inspect r service 1<br />
<br />
<br />
obr:deploy -s "Apache Felix Log Service"<br />
help log<br />
log debug<br />
log info<br />
log warn<br />
log error<br />
</pre><br />
<br />
=Deploiement de bundles=<br />
<pre><br />
install file:./repository/org.apache.felix.sandbox.mbean.shell.felix.gogo-0.4.0.jar<br />
lb<br />
start 5<br />
inspect c osgi.wiring.package 5<br />
inspect r osgi.wiring.package 5<br />
inspect c service 5<br />
inspect r service 5<br />
<br />
update 5<br />
log debug<br />
<br />
<br />
install http://repo1.maven.org/maven2/org/apache/felix/org.apache.felix.http.jetty/1.0.1/org.apache.felix.http.jetty-1.0.1.jar<br />
log 1<br />
lb<br />
start 6<br />
uninstall 6<br />
</pre><br />
<br />
que se passe t'il et pourquoi ?<br />
<br />
=Changement du niveau d'execution=<br />
<pre><br />
lb<br />
help bundlelevel<br />
bundlelevel <OBR' bundle Id><br />
frameworklevel<br />
bundlelevel -s 2 <OBR' bundle Id><br />
log debug<br />
obr:list<br />
</pre><br />
<br />
que s'est il passÈ ?<br />
<br />
<pre><br />
frameworklevel 2<br />
log debug<br />
lb<br />
obr:list<br />
</pre><br />
<br />
<br />
que s'est il passÈ ?<br />
<br />
=Deployez et lancez la Web console via l'OBR=<br />
Qu'est que l'OBR ([[OSGi Bundle Repository]]) ?<br />
<br />
<pre><br />
obr:help<br />
obr:list<br />
obr:info "Apache Felix Web Management Console"<br />
obr:deploy -s "Apache Felix Web Management Console"<br />
lb<br />
<br />
obr:deploy -s "Apache Felix Web Management Console" "Apache Felix Web Console Event Plugin" "Apache Felix Web Console Memory Usage Plugin" "Apache Felix Web Console Service Diagnostics Plugin" "Apache Felix Web Console UPnP Plugin"<br />
lb<br />
</pre><br />
<br />
<br />
Combien de bundles ont ÈtÈ dÈployÈs (installÈs et dÈmarrÈs) ?<br />
<br />
naviguez http://localhost:8080/system/console depuis votre browser (username et password : admin et admin)<br />
<br />
Deployez File Install soit depuis la web console onglet "OSGi repository"<br />
soit avec la commande<br />
<pre><br />
obr:deploy -start "Apache Felix File Install"<br />
</pre><br />
<br />
=FileInstall=<br />
Deployez des bundles via FileInstall en copiant les jarfiles des bundles du rÈpertoires .\repertoire vers .\load depuis un cmd DOS<br />
copy .\repository\org.apache.felix.examples.managedservice-0.1.0-SNAPSHOT.jar .\load<br />
Que s'est il passÈ ? (faire lb puis log 4)<br />
<br />
del .\load\org.apache.felix.examples.managedservice-0.1.0-SNAPSHOT.jar<br />
Que s'est il passÈ ? (faire lb puis log 4)</div>Calmanthttps://air.imag.fr/index.php?title=Tutorial_OSGi_avec_Apache_Felix_-_Partie_1&diff=11319Tutorial OSGi avec Apache Felix - Partie 12013-04-19T07:48:56Z<p>Calmant: /* Changement du niveau d'execution */</p>
<hr />
<div>[[Tutorial OSGi avec Apache Felix|Revenir au sommaire]]<br />
<br />
<br />
<br />
=Installation et configuration=<br />
Telechargez la derniËre distribution de Felix depuis<br />
http://felix.apache.org/site/downloads.cgi<br />
<br />
DÈzippez la distribution dans le repertoire du TP<br />
<br />
Configurez les variables JAVA_HOME et PATH<br />
<br />
<pre><br />
set FELIX_VER=4.0.2<br />
set FELIX_HOME=felix-framework-%FELIX_VER%<br />
set JAVA_HOME=c:\Progra~1\Java\jre6<br />
set PATH=%JAVA_HOME%\bin;%PATH%<br />
java -version<br />
</pre><br />
<br />
<br />
<br />
creez les repertoires dans %FELIX_HOME%<br />
<pre><br />
mkdir %FELIX_HOME%\load<br />
mkdir %FELIX_HOME%\repository<br />
<br />
copy repository\*.* %FELIX_HOME%\repository<br />
copy run.bat %FELIX_HOME%<br />
</pre><br />
<br />
le fichier run.bat permet de lancer Felix avec le proxy HTTP configurÈ avec celui de l'UJF (www-cache.ujf-grenoble.fr:3128)<br />
<br />
Positionnez <br />
<pre><br />
cd %FELIX_HOME%<br />
</pre><br />
<br />
=Lancement de Felix=<br />
<pre><br />
run.bat<br />
</pre><br />
<br />
=PremiËres commandes=<br />
Depuis le shell Gogo de Felix<br />
<pre><br />
help<br />
lb<br />
headers<br />
inspect capability osgi.wiring.package 0<br />
inspect requirement osgi.wiring.package 0<br />
inspect capability service 0<br />
inspect requirement service 0<br />
<br />
inspect c osgi.wiring.package 1<br />
inspect r osgi.wiring.package 1<br />
inspect c service 1<br />
inspect r service 1<br />
<br />
<br />
obr:deploy -start "Apache Felix Log Service"<br />
help log<br />
log debug<br />
log info<br />
log warn<br />
log error<br />
</pre><br />
<br />
=Deploiement de bundles=<br />
<pre><br />
install file:./repository/org.apache.felix.sandbox.mbean.shell.felix.gogo-0.4.0.jar<br />
lb<br />
start 5<br />
inspect c osgi.wiring.package 5<br />
inspect r osgi.wiring.package 5<br />
inspect c service 5<br />
inspect r service 5<br />
<br />
update 5<br />
log debug<br />
<br />
<br />
install http://repo1.maven.org/maven2/org/apache/felix/org.apache.felix.http.jetty/1.0.1/org.apache.felix.http.jetty-1.0.1.jar<br />
log 1<br />
lb<br />
start 6<br />
uninstall 6<br />
</pre><br />
<br />
que se passe t'il et pourquoi ?<br />
<br />
=Changement du niveau d'execution=<br />
<pre><br />
lb<br />
help bundlelevel<br />
bundlelevel <OBR' bundle Id><br />
frameworklevel<br />
bundlelevel -s 2 <OBR' bundle Id><br />
log debug<br />
obr:list<br />
</pre><br />
<br />
que s'est il passÈ ?<br />
<br />
<pre><br />
frameworklevel 2<br />
log debug<br />
lb<br />
obr:list<br />
</pre><br />
<br />
<br />
que s'est il passÈ ?<br />
<br />
=Deployez et lancez la Web console via l'OBR=<br />
Qu'est que l'OBR ([[OSGi Bundle Repository]]) ?<br />
<br />
<pre><br />
obr:help<br />
obr:list<br />
obr:info "Apache Felix Web Management Console"<br />
obr:deploy -s "Apache Felix Web Management Console"<br />
lb<br />
<br />
obr:deploy -s "Apache Felix Web Management Console" "Apache Felix Web Console Event Plugin" "Apache Felix Web Console Memory Usage Plugin" "Apache Felix Web Console Service Diagnostics Plugin" "Apache Felix Web Console UPnP Plugin"<br />
lb<br />
</pre><br />
<br />
<br />
Combien de bundles ont ÈtÈ dÈployÈs (installÈs et dÈmarrÈs) ?<br />
<br />
naviguez http://localhost:8080/system/console depuis votre browser (username et password : admin et admin)<br />
<br />
Deployez File Install soit depuis la web console onglet "OSGi repository"<br />
soit avec la commande<br />
<pre><br />
obr:deploy -start "Apache Felix File Install"<br />
</pre><br />
<br />
=FileInstall=<br />
Deployez des bundles via FileInstall en copiant les jarfiles des bundles du rÈpertoires .\repertoire vers .\load depuis un cmd DOS<br />
copy .\repository\org.apache.felix.examples.managedservice-0.1.0-SNAPSHOT.jar .\load<br />
Que s'est il passÈ ? (faire lb puis log 4)<br />
<br />
del .\load\org.apache.felix.examples.managedservice-0.1.0-SNAPSHOT.jar<br />
Que s'est il passÈ ? (faire lb puis log 4)</div>Calmanthttps://air.imag.fr/index.php?title=Tutorial_OSGi_avec_Apache_Felix_-_Partie_1&diff=11318Tutorial OSGi avec Apache Felix - Partie 12013-04-19T07:48:34Z<p>Calmant: /* Deploiement de bundles */</p>
<hr />
<div>[[Tutorial OSGi avec Apache Felix|Revenir au sommaire]]<br />
<br />
<br />
<br />
=Installation et configuration=<br />
Telechargez la derniËre distribution de Felix depuis<br />
http://felix.apache.org/site/downloads.cgi<br />
<br />
DÈzippez la distribution dans le repertoire du TP<br />
<br />
Configurez les variables JAVA_HOME et PATH<br />
<br />
<pre><br />
set FELIX_VER=4.0.2<br />
set FELIX_HOME=felix-framework-%FELIX_VER%<br />
set JAVA_HOME=c:\Progra~1\Java\jre6<br />
set PATH=%JAVA_HOME%\bin;%PATH%<br />
java -version<br />
</pre><br />
<br />
<br />
<br />
creez les repertoires dans %FELIX_HOME%<br />
<pre><br />
mkdir %FELIX_HOME%\load<br />
mkdir %FELIX_HOME%\repository<br />
<br />
copy repository\*.* %FELIX_HOME%\repository<br />
copy run.bat %FELIX_HOME%<br />
</pre><br />
<br />
le fichier run.bat permet de lancer Felix avec le proxy HTTP configurÈ avec celui de l'UJF (www-cache.ujf-grenoble.fr:3128)<br />
<br />
Positionnez <br />
<pre><br />
cd %FELIX_HOME%<br />
</pre><br />
<br />
=Lancement de Felix=<br />
<pre><br />
run.bat<br />
</pre><br />
<br />
=PremiËres commandes=<br />
Depuis le shell Gogo de Felix<br />
<pre><br />
help<br />
lb<br />
headers<br />
inspect capability osgi.wiring.package 0<br />
inspect requirement osgi.wiring.package 0<br />
inspect capability service 0<br />
inspect requirement service 0<br />
<br />
inspect c osgi.wiring.package 1<br />
inspect r osgi.wiring.package 1<br />
inspect c service 1<br />
inspect r service 1<br />
<br />
<br />
obr:deploy -start "Apache Felix Log Service"<br />
help log<br />
log debug<br />
log info<br />
log warn<br />
log error<br />
</pre><br />
<br />
=Deploiement de bundles=<br />
<pre><br />
install file:./repository/org.apache.felix.sandbox.mbean.shell.felix.gogo-0.4.0.jar<br />
lb<br />
start 5<br />
inspect c osgi.wiring.package 5<br />
inspect r osgi.wiring.package 5<br />
inspect c service 5<br />
inspect r service 5<br />
<br />
update 5<br />
log debug<br />
<br />
<br />
install http://repo1.maven.org/maven2/org/apache/felix/org.apache.felix.http.jetty/1.0.1/org.apache.felix.http.jetty-1.0.1.jar<br />
log 1<br />
lb<br />
start 6<br />
uninstall 6<br />
</pre><br />
<br />
que se passe t'il et pourquoi ?<br />
<br />
=Changement du niveau d'execution=<br />
<pre><br />
lb<br />
help bundlelevel<br />
bundlelevel <OBR' bundle Id><br />
frameworklevel<br />
bundlelevel -s 2 <OBR' bundle Id><br />
log<br />
obr:list<br />
</pre><br />
<br />
que s'est il passÈ ?<br />
<br />
<pre><br />
frameworklevel 2<br />
log<br />
lb<br />
obr:list<br />
</pre><br />
<br />
<br />
que s'est il passÈ ?<br />
<br />
=Deployez et lancez la Web console via l'OBR=<br />
Qu'est que l'OBR ([[OSGi Bundle Repository]]) ?<br />
<br />
<pre><br />
obr:help<br />
obr:list<br />
obr:info "Apache Felix Web Management Console"<br />
obr:deploy -s "Apache Felix Web Management Console"<br />
lb<br />
<br />
obr:deploy -s "Apache Felix Web Management Console" "Apache Felix Web Console Event Plugin" "Apache Felix Web Console Memory Usage Plugin" "Apache Felix Web Console Service Diagnostics Plugin" "Apache Felix Web Console UPnP Plugin"<br />
lb<br />
</pre><br />
<br />
<br />
Combien de bundles ont ÈtÈ dÈployÈs (installÈs et dÈmarrÈs) ?<br />
<br />
naviguez http://localhost:8080/system/console depuis votre browser (username et password : admin et admin)<br />
<br />
Deployez File Install soit depuis la web console onglet "OSGi repository"<br />
soit avec la commande<br />
<pre><br />
obr:deploy -start "Apache Felix File Install"<br />
</pre><br />
<br />
=FileInstall=<br />
Deployez des bundles via FileInstall en copiant les jarfiles des bundles du rÈpertoires .\repertoire vers .\load depuis un cmd DOS<br />
copy .\repository\org.apache.felix.examples.managedservice-0.1.0-SNAPSHOT.jar .\load<br />
Que s'est il passÈ ? (faire lb puis log 4)<br />
<br />
del .\load\org.apache.felix.examples.managedservice-0.1.0-SNAPSHOT.jar<br />
Que s'est il passÈ ? (faire lb puis log 4)</div>Calmanthttps://air.imag.fr/index.php?title=Arduino&diff=9421Arduino2013-03-06T13:35:07Z<p>Calmant: /* Liens */</p>
<hr />
<div>[[Image:arduinos.jpg|200px|thumb|Assortiments d'Arduino et consors: Uno, Mega, Seeeduino, FEZ Panda]]<br />
[[Image:arduinoteam.jpg|200px|thumb|The Arduino (Dream) Team]]<br />
<br />
<br />
==Description==<br />
Arduino est un ensemble de cartes à base d'AVR ATMega pour le prototypage rapide d'applications ''[[physical computing]]'' mêlant programmation simple et électronique de base. Elle s'adresse aux artistes, hobbiistes, lycéens et enseignants.<br />
<br />
<br />
Les points forts de cette carte sont:<br />
* son caractère [[open-source]] (multi fournisseurs, ...)<br />
* son environnement simplifié pour le développement (basé sur [[Processing]], langage Wiring, programmation vers l'USB, ...)<br />
* sa communauté d'utilisateurs (millions, entraide, idées de projet, ...)<br />
* sa connection avec l'environnement [[Processing]] (sur un hôte PC, Mac, ...)<br />
<br />
Les points faible de cette carte sont:<br />
* des capacités limitées en mémoire RAM et FLASH<br />
<br />
==Installation==<br />
===Windows===<br />
Téléchargez l'environnement de développement Arduino depuis http://www.arduino.cc/en/Main/Software<br />
<br />
Dézippez l'environnement (qui requière un JRE)<br />
<br />
Installez les drivers de votre carte (Uno, Duemilanove ...) présents dans le répertoire arduino-0xyz\drivers en suivant les [http://arduino.cc/en/Guide/Windows#toc4 instructions].<br />
<br />
===MacOS X===<br />
<br />
===Linux===<br />
Sous Linux [http://www.arduino.cc/playground/Learning/Linux http://www.arduino.cc/playground/Learning/Linux]<br />
<pre><br />
sudo apt-get install arduino<br />
</pre><br />
<br />
More for Ubuntu at ''http://arduino.cc/playground/Linux/Ubuntu''<br />
<br />
Quote:<br />
''Is there any way I can "see" the avrdude command the Arduino IDE uses (since it works)?''<br />
<br />
Close the IDE if running and open the preferences.txt file for the IDE in a texteditor. Change the keys :<br />
<pre><br />
build.verbose=true<br />
upload.verbose=true<br />
</pre><br />
<br />
Then startup the IDE. It should now print all the compiler and avrdude upload messages.<br />
<br />
Related info<br />
<br />
* For Arduino 22 on 64 bit [http://thenybble.de/projects/arduino-64-bit.html http://thenybble.de/projects/arduino-64-bit.html]<br />
* Ecplise plugin [http://www.arduino.cc/playground/Code/Eclipse http://www.arduino.cc/playground/Code/Eclipse]<br />
<br />
==Premiers pas==<br />
Pour tester que l'installation est opérationnelle:<br />
* connectez votre carte Arduino sur le port USB de votre machine<br />
* lancez l'environnement Arduino<br />
* sélectionnez le modèle de votre carte Arduino : ''Menu Tools > Board''<br />
* sélectionnez le port série (ie port COM sous Windows) sur lequel se trouve brancher votre carte Arduino : ''Menu Tools > Serial Port'' <br />
* ouvrez l'exemple Blink ''Menu File > Examples > 1.Basics > Blink''<br />
* compilez et chargez le code sur la carte ''Menu File > Upload to IO Board''<br />
* normalement, la LED 13 de la carte clignote en continu ! (dès qu'elle est alimentée, la carte boot et exécute ce programme qui est installé dans la FlashRAM.<br />
<br />
C'est tout bon : à vous de jouer ...<br />
<br />
Vous pouvez tester les autres exemples ''Menu File > Examples''<br />
Notamment celui utilisant le port série ''Menu File > Examples > 4.Communication > ASCIITable''<br />
<br />
Voici un aide mémoire Arduino [[Media:arduinocheatsheet.pdf]] ([http://sites.google.com/site/mechatronicsguy/arduinocheatsheet/Arduinocheatsheetv02c.pdf?attredirects=0&d=1 original])<br />
<br />
et d'autres manipulations avec des capteurs et des actionneurs<br />
* Sparkfun Inventor Kit (en VO)<br />
** http://www.sparkfun.com/tutorial/AIK/ARDX-EG-SPAR-PRINT-85.pdf<br />
** http://www.sparkfun.com/tutorial/AIK/CIRC00-sheet-SPAR.pdf<br />
* Sparkfun Inventor Kit (en VF)<br />
** http://ardx.org/src/guide/2/ARDX-EG-SPAR-FR-WEB.pdf<br />
** http://www.sparkfun.com/news/636<br />
<br />
Des [[Travaux Pratiques Arduino]] plus conséquents sont disponibles pour les élèves de AIR.<br />
<br />
==Avancés==<br />
[http://robotgroup.com.ar/duinos/wiki/index.php?title=Main_Page-FR DuinOS] un OS temps réel pour Arduino.<br />
<br />
==Arduino @ AIR==<br />
Les cartes disponibles dans la salle AIR:<br />
* [http://arduino.cc/en/Main/ArduinoBoardUno Arduino Uno]<br />
* Arduino Duemilanove<br />
* [http://arduino.cc/en/Main/ArduinoBoardMega2560 Arduino Mega2560]<br />
* [http://www.arduino.cc/en/Main/ArduinoBoardLilyPad Arduino Lilypad]<br />
* [[Arduino FIO]] (included XBee socket)<br />
* [http://www.seeedstudio.com/depot/seeeduino-stalker-p-600.html Seeeduino Stalker] (included ZigBee + SD Card)<br />
* "[[Breaduino]]" (Arduino bootable ATMega328 standalone)<br />
<br />
Des cartes ''erzats'' utilisant des processeurs ARM7 sont compatibles avec les montages et les cartes filles développées pour les cartes Arduino. Pour certaines, le développement se fait par contre en C# .NET MicroFramework<br />
* [[Arduino Due]]<br />
* [[chipKIT Uno32]]<br />
* [[Netduino]]<br />
* [[FEZ]] Panda<br />
<br />
Des cartes [[FPGA]] comme la carte [[Papilio]] peuvent être synthètisées en AVR8 (ou [[ZPUino|ZPU]]) et exécuter des schetches Arduino via l'IDE Arduino modifié.<br />
<br />
[[Image:arduinos.jpg|500px|Assortiments d'Arduino et consors: Uno, Mega, Seeeduino, FEZ Panda]][[Image:arduigrid-v0.1.jpg|500px|ArduiGrid]][[Image:Breaduino1.jpg|300px|Breaduino]][[Image:Solarpanel2.jpg|300px|Module XBee sur Arduino Fio]][[Image:papilio500Arcade2.jpg|300px|Carte FPGA Papilio 500K + Papilio Arcade MegaWing + Vintage joysticks (6 switches)]]<br />
<br />
==Ressources==<br />
===Liens===<br />
* [http://www.arduino.cc Arduino Website]<br />
* [http://www.arduino.cc/en/Main/Hardware Arduino Hardware]<br />
* [http://membres-liglab.imag.fr/donsez/cours/arduino.pdf Transparents du cours]<br />
* Un trés bon [http://fr.flossmanuals.net/arduino/ flossmanuals] sur l'arduino<br />
* Un aide mémoire sur Arduino [[Media:arduinocheatsheet.pdf]] ([http://sites.google.com/site/mechatronicsguy/arduinocheatsheet/Arduinocheatsheetv02c.pdf?attredirects=0&d=1 original])<br />
* ''[http://gitorious.org/simavr simavr] is a new AVR simulator for linux, or any platform that uses avr-gcc. It uses avr-gcc own register definition to simplify creating new targets for supported AVR devices''<br />
* [[Modk.it]]<br />
* http://blog.ardublock.com/<br />
* [http://android.serverbox.ch/?p=549 Arduino avec Android (USB Host)]<br />
<br />
===Kits===<br />
* Sparkfun Inventor Kit (un kit de base pour démarrer avec l'Ardiuno en VO<br />
** http://www.sparkfun.com/tutorial/AIK/ARDX-EG-SPAR-PRINT-85.pdf<br />
** http://www.sparkfun.com/tutorial/AIK/CIRC00-sheet-SPAR.pdf<br />
* Sparkfun Inventor Kit (en VF)<br />
** http://ardx.org/src/guide/2/ARDX-EG-SPAR-FR-WEB.pdf<br />
** http://www.sparkfun.com/news/636<br />
<br />
===Livres===<br />
* Massimo Banzi, Getting Started with Arduino, Pub. Make; 1 edition (October 15, 2008) ISBN-10: 0596155514<br />
* Tom Igoe, [http://oreilly.com/catalog/9780596510510 Making Things Talk: Practical Methods for Connecting Physical Objects], Make; 1 edition (September 28, 2007), ISBN-10: 0596510519 ([http://examples.oreilly.com/9780596510510/ exemples de code]) un livre plein de recette de cuisine !</div>Calmanthttps://air.imag.fr/index.php?title=Tutorial_OSGi_avec_Apache_Felix_-_Partie_4&diff=7103Tutorial OSGi avec Apache Felix - Partie 42012-12-20T10:17:47Z<p>Calmant: /* II. Pure-OSGi service */</p>
<hr />
<div>[[Tutorial OSGi avec Apache Felix|Revenir au sommaire]]<br />
<br />
=Requirements=<br />
<br />
* Felix Framework Distribution (voir [[Tutorial OSGi avec Apache Felix - Partie 1]])<br />
** with the iPOJO Core bundle[http://felix.apache.org/site/download.html] (see next section)<br />
* [http://www.eclipse.org/downloads/ Eclipse].<br />
** To support OSGi development, Eclipse needs the '''PDE''' (Plug-in Development Environment) plug-in, bundled in ''Eclipse IDE for Java EE Developers''<br />
* iPOJO Nature plug-in for Eclipse, available [https://dl.dropbox.com/u/59622687/org.ow2.chameleon.eclipse.ipojo.updatesite-1.0.1-SNAPSHOT.zip as an archive distribution]<br />
** Install the ''iPOJO Project Nature'' and ''iPOJO Nature Dependencies'' plug-ins<br />
<br />
==Set up your Felix installation==<br />
<br />
# Run Felix using the following command in the Felix installation directory<br />
#* <code>java -jar bin/felix.jar</code><br />
# Install iPOJO, using the following Felix Gogo shell commands:<br />
#* <code>obr:list</code><br />
#* <code>obr:deploy -s "Apache Felix Log Service"</code><br />
#* <code>obr:deploy -s "Apache Felix iPOJO"</code><br />
#* <code>obr:deploy -s "Apache Felix iPOJO Gogo Command"</code><br />
<br />
==Useful Gogo commands==<br />
<br />
''Note'': To ease shell lines edition on Linux, you might use the [http://utopia.knoware.nl/~hlub/rlwrap/#rlwrap rlwrap] tool: <code>rlwrap java -jar bin/felix.jar</code><br />
<br />
* <code>help {command}</code><br />
** Print the help of the given command<br />
* <code>lb</code><br />
** Lists the bundles installed in the framework<br />
* <code>inspect capability service {bundle ID}</code><br />
** Lists the services provided by the given bundle<br />
** <code>capability</code> can be written <code>c</code><br />
* <code>inspect requirement service {bundle ID}</code><br />
** Lists the services consumed by the given bundle<br />
** <code>requirement</code> can be written <code>r</code><br />
* <code>ipojo:factories</code><br />
** Prints the publicly available iPOJO factories<br />
* <code>ipojo:factory {factory name}</code><br />
** Prints the details of the given iPOJO factory<br />
* <code>ipojo:instances</code><br />
** Prints the names and states of iPOJO instances<br />
* <code>ipojo:instance {instance name}</code><br />
** Prints the details of the given iPOJO component instance<br />
<br />
==Eclipse Configuration==<br />
<br />
By default, Eclipse uses its installation directory as the Target Platform, i.e. the group of bundles accessible by your bundle project.<br />
You should declare the installation folder of the Felix Framework as the target platform to avoid compilation and access rights errors.<br />
<br />
# Open Eclipse preferences<br />
# Plug-in Development > Target Platform<br />
# Add...<br />
## Create an empty target platform (check ''nothing...'')<br />
## Add the ''bin'' and ''bundle'' folders of your Felix installation to the Target Platform<br />
# Set the new target platform as the current one<br />
<br />
=I. Activator=<br />
<br />
# Create an Eclipse Plug-in project ''fr.erods.tp.bundle1''<br />
#* New > Plug-in project<br />
#* Select the option "Target Platform" > "an OSGi framework" > ''standard''<br />
#* Next<br />
#* Check "Generate an activator"<br />
#* Finish<br />
# Open the activator class and print some text when the bundle starts and stops<br />
# Export the bundle JAR file with iPOJO Nature<br />
#* Right click on the bundle project > Export > iPOJO Bundle<br />
#* Choose an output folder (the Felix installation folder)<br />
#* Finish<br />
# Install and test the bundle using the Felix shell (start/update/stop)<br />
<br />
Questions:<br />
* Indicate when start() and stop() methods are called.<br />
* Why the BundleContext can be kept as a <code>private static</code> class member ?<br />
<br />
=II. Pure-OSGi service=<br />
<br />
# Create an new bundle project ''fr.erods.tp.api''.<br />
#* Activator is not needed: uncheck "Generate an activator" in step 2<br />
# Create the <code>fr.erods.tp.api.IScheduleService</code> interface with two methods:<br />
#* <code>int createJob(Runnable aRunnable, int aDelay)</code><br />
#* <code>void deleteJob(int aId)</code><br />
# Export the API package<br />
#* Open the Manifest.mf file of ''fr.erods.tp.api''<br />
#* In tab "Runtime" > "Exported Packages" > Add<br />
#** Select the <code>fr.erods.tp.api</code> package<br />
# Import the API package in bundle 1<br />
#* Open the Manifest.mf file of ''fr.erods.tp.bundle1''<br />
#* In tab "Dependencies" > "Imported Packages" > Add<br />
#* Select the <code>fr.erods.tp.api</code> package<br />
# Implement the service in bundle 1<br />
#* Create the class <code>fr.erods.tp.bundle1.ScheduleImpl</code>, implementing <code>IScheduleService</code> in the bundle 1.<br />
# Register the service with the activator of bundle 1<br />
#* see [http://www.osgi.org/javadoc/r4v43/core/org/osgi/framework/BundleContext.html#registerService%28java.lang.Class,%20S,%20java.util.Dictionary%29 registerService()]<br />
#* see [http://www.osgi.org/javadoc/r4v43/core/org/osgi/framework/ServiceRegistration.html#unregister%28%29 unregister()]<br />
# Implement a service consumer in a new bundle<br />
#* Create project ''fr.erods.tp.bundle2''<br />
#* Import the API package<br />
#** In the Manifest.mf file of bundle 2<br />
#** In tab "Dependencies" > "Imported Packages" > Add<br />
#** Select the <code>fr.erods.tp.api</code> package<br />
#* Implement a <code>Consumer</code> class, implementing the OSGi <code>ServiceListener</code>[http://www.osgi.org/javadoc/r4v43/core/org/osgi/framework/ServiceListener.html] interface<br />
#* Print a message when the service is bound/unbound<br />
# Test the bundles in Felix<br />
<br />
Questions:<br />
* What happens when the consumer is started after the service bundle and why ?<br />
* Correct this behavior, using [http://www.osgi.org/javadoc/r4v43/core/org/osgi/framework/BundleContext.html#getServiceReference%28java.lang.Class%29 getServiceReference()] and [http://www.osgi.org/javadoc/r4v43/core/org/osgi/framework/BundleContext.html#getService%28org.osgi.framework.ServiceReference%29 getService()]<br />
<br />
=II. iPOJO: provide and consume with iPOJO=<br />
<br />
# Add the iPOJO Nature to projects ''bundle 1'' and ''bundle 2''<br />
#* Select the projects<br />
#* Right click > Add iPOJO Nature<br />
#* Check ''Use annotations''<br />
<br />
==Consumer==<br />
<br />
# Implement a <code>ConsumerIpojo</code> class in bundle 2<br />
#* See [http://felix.apache.org/site/how-to-use-ipojo-annotations.html How to use iPOJO Annotations]<br />
#* The component must be instantiated automatically<br />
#* Print a message when the component is (in)validated and when the service is (un)bound<br />
# Test<br />
# Set the service requirement as optional<br />
# Test<br />
<br />
Questions:<br />
* Why are the callbacks called in that order ?<br />
* What happens if you use a missing optional requirement ?<br />
<br />
==Provider==<br />
<br />
# Implement a <code>ServiceProviderIpojo</code> class in bundle 1<br />
#* See [http://felix.apache.org/site/how-to-use-ipojo-annotations.html How to use iPOJO Annotations]<br />
#* The component must be instantiated automatically<br />
#* The component must provide its service<br />
#* Print a message when the component is (in)validated<br />
# Test<br />
# Add a ''service controller'' and alternate the service presence<br />
# Test<br />
<br />
Question:<br />
* How does the consumers react to the service presence cycle ?<br />
<br />
==Bonus==<br />
<br />
# Add a "service.ranking" property to the pure-OSGi and the iPOJO service, and an "implementation" property to identify them<br />
# Print the name of the implementation the consumers are bound to<br />
# Modify the ranking value<br />
<br />
Question:<br />
* How does a service the service selection works ?<br />
<br />
''Note'': The consumer should call methods of the service and traces should be printed in order to show which service the consumer is bound to.<br />
<br />
=III. Whiteboard pattern=<br />
<br />
# Create interface <code>IJobListener</code> in the API package, with two methods:<br />
#* <code>void onJobCreation(int aId)</code><br />
#* <code>void onJobDeletion(int aId)</code><br />
# Create a new bundle project ''fr.erods.tp.bundle3''<br />
#* Add the iPOJO Nature and annotations<br />
#* Let it import the API package<br />
# Create a component providing an <code>IJobListener</code> service in bundle 3<br />
# Add job creation / deletion operations in a consumer<br />
<br />
==Subscription pattern==<br />
<br />
# Modify the schedule component to allow listeners registration:<br />
#* <code>void addListener(IJobListener)</code><br />
#* <code>void removeListener(IJobListener)</code><br />
# Register component of bundle 3 as a job listener<br />
# Test<br />
<br />
==Whiteboard pattern==<br />
<br />
# Modify the schedule component (in bundle 1)<br />
#* Remove the registration methods created above<br />
#* Add a requirement to an array of <code>IJobListener</code>s, as an optional requirement<br />
#* Notify them on job creation/deletion<br />
# Test<br />
<br />
Questions:<br />
* What are the pros/cons of the whiteboard pattern vs. the subscription pattern ?<br />
* Bonus: compare this whiteboard pattern implementation with the iPOJO Whiteboard pattern handler[http://felix.apache.org/site/white-board-pattern-handler.html]<br />
<br />
=IV. JMX MBean with iPOJO=<br />
<br />
# Create a new bundle, with iPOJO Nature and annotations<br />
# Create a component, which doesn't provide any service, but contains public methods to create/delete/list <code>IScheduleService</code> jobs<br />
# Use iPOJO JMX annotations[http://felix.apache.org/site/how-to-use-ipojo-annotations.html#HowtouseiPOJOAnnotations-ExposinginstancesasaJMXMBean%28externalhandler%29] to export those methods<br />
# You will need the iPOJO JMX handler to test this component: install it using the following command in the Felix shell:<br />
#* <code>obr:deploy -s "Apache Felix iPOJO JMX Handler</code><br />
# Install the bundle in the Felix framework<br />
# Run <code>jconsole</code> (in the Oracle Java distribution) or <code>jvisualvm</code> (in the Oracle Java distribution) or <code>visualvm</code>[http://visualvm.java.net/download.html]<br />
#* You might need to install the JMX plug-in in VisualVM:<br />
#** Tools > Plugins > Available Plugi-ns<br />
#** Install the ''VisualVM-MBeans'' plug-in<br />
# Connect VisualVM to your Felix JVM and play with the JMX beans<br />
<br />
=V. Gogo Command with iPOJO=<br />
<br />
# Create a new bundle, with iPOJO Nature and annotations<br />
# Create a Gogo command provider to create and delete jobs, and to list current jobs status<br />
<br />
==Minimal Gogo command component==<br />
<br />
<pre><br />
import org.apache.felix.ipojo.annotations.Component;<br />
import org.apache.felix.ipojo.annotations.Instantiate;<br />
import org.apache.felix.ipojo.annotations.Provides;<br />
import org.apache.felix.ipojo.annotations.ServiceProperty;<br />
import org.apache.felix.service.command.Descriptor;<br />
<br />
@Component(immediate = true)<br />
// Provide the component class as a service<br />
@Provides(specifications = ListComponentsCommand.class)<br />
// Instantiate the component automatically<br />
@Instantiate<br />
public class ListComponentsCommand {<br />
<br />
// Gogo scope/namespace<br />
@ServiceProperty(name = "osgi.command.scope", value = "test")<br />
String scope;<br />
<br />
// Gogo commands provided by this class (must be methods names)<br />
@ServiceProperty(name = "osgi.command.function", value = "{}")<br />
String[] function = new String[] { "test" };<br />
<br />
// Method description<br />
@Descriptor("test")<br />
public void test() {<br />
System.out.println("test!");<br />
}<br />
}<br />
</pre><br />
<br />
=VI. Config Admin with iPOJO=<br />
<br />
See [http://felix.apache.org/site/combining-ipojo-and-configuration-admin.html Combining iPOJO and Configuration Admin]<br />
<br />
=VII. Event Admin with iPOJO=<br />
1. Create a new bundle, with iPOJO annotations to send events on jobs status changes<br />
<br />
=VIII. Extender with iPOJO=<br />
??<br />
<br />
=Guidelines & Good Practices ("OSGi Zen")=<br />
<br />
* Always separate API and implementations<br />
* Always release services and resources once you're done or when their bundle is stopping<br />
* Always indicate requested/provided packages versions<br />
* Avoid <code>public static</code> class members<br />
** <code>private static</code> are allowed<br />
** Use interfaces to declare constants</div>Calmanthttps://air.imag.fr/index.php?title=Tutorial_OSGi_avec_Apache_Felix_-_Partie_4&diff=7102Tutorial OSGi avec Apache Felix - Partie 42012-12-20T08:51:39Z<p>Calmant: /* II. Pure-OSGi service */</p>
<hr />
<div>[[Tutorial OSGi avec Apache Felix|Revenir au sommaire]]<br />
<br />
=Requirements=<br />
<br />
* Felix Framework Distribution (voir [[Tutorial OSGi avec Apache Felix - Partie 1]])<br />
** with the iPOJO Core bundle[http://felix.apache.org/site/download.html] (see next section)<br />
* [http://www.eclipse.org/downloads/ Eclipse].<br />
** To support OSGi development, Eclipse needs the '''PDE''' (Plug-in Development Environment) plug-in, bundled in ''Eclipse IDE for Java EE Developers''<br />
* iPOJO Nature plug-in for Eclipse, available [https://dl.dropbox.com/u/59622687/org.ow2.chameleon.eclipse.ipojo.updatesite-1.0.1-SNAPSHOT.zip as an archive distribution]<br />
** Install the ''iPOJO Project Nature'' and ''iPOJO Nature Dependencies'' plug-ins<br />
<br />
==Set up your Felix installation==<br />
<br />
# Run Felix using the following command in the Felix installation directory<br />
#* <code>java -jar bin/felix.jar</code><br />
# Install iPOJO, using the following Felix Gogo shell commands:<br />
#* <code>obr:list</code><br />
#* <code>obr:deploy -s "Apache Felix Log Service"</code><br />
#* <code>obr:deploy -s "Apache Felix iPOJO"</code><br />
#* <code>obr:deploy -s "Apache Felix iPOJO Gogo Command"</code><br />
<br />
==Useful Gogo commands==<br />
<br />
''Note'': To ease shell lines edition on Linux, you might use the [http://utopia.knoware.nl/~hlub/rlwrap/#rlwrap rlwrap] tool: <code>rlwrap java -jar bin/felix.jar</code><br />
<br />
* <code>help {command}</code><br />
** Print the help of the given command<br />
* <code>lb</code><br />
** Lists the bundles installed in the framework<br />
* <code>inspect capability service {bundle ID}</code><br />
** Lists the services provided by the given bundle<br />
** <code>capability</code> can be written <code>c</code><br />
* <code>inspect requirement service {bundle ID}</code><br />
** Lists the services consumed by the given bundle<br />
** <code>requirement</code> can be written <code>r</code><br />
* <code>ipojo:factories</code><br />
** Prints the publicly available iPOJO factories<br />
* <code>ipojo:factory {factory name}</code><br />
** Prints the details of the given iPOJO factory<br />
* <code>ipojo:instances</code><br />
** Prints the names and states of iPOJO instances<br />
* <code>ipojo:instance {instance name}</code><br />
** Prints the details of the given iPOJO component instance<br />
<br />
==Eclipse Configuration==<br />
<br />
By default, Eclipse uses its installation directory as the Target Platform, i.e. the group of bundles accessible by your bundle project.<br />
You should declare the installation folder of the Felix Framework as the target platform to avoid compilation and access rights errors.<br />
<br />
# Open Eclipse preferences<br />
# Plug-in Development > Target Platform<br />
# Add...<br />
## Create an empty target platform (check ''nothing...'')<br />
## Add the ''bin'' and ''bundle'' folders of your Felix installation to the Target Platform<br />
# Set the new target platform as the current one<br />
<br />
=I. Activator=<br />
<br />
# Create an Eclipse Plug-in project ''fr.erods.tp.bundle1''<br />
#* New > Plug-in project<br />
#* Select the option "Target Platform" > "an OSGi framework" > ''standard''<br />
#* Next<br />
#* Check "Generate an activator"<br />
#* Finish<br />
# Open the activator class and print some text when the bundle starts and stops<br />
# Export the bundle JAR file with iPOJO Nature<br />
#* Right click on the bundle project > Export > iPOJO Bundle<br />
#* Choose an output folder (the Felix installation folder)<br />
#* Finish<br />
# Install and test the bundle using the Felix shell (start/update/stop)<br />
<br />
Questions:<br />
* Indicate when start() and stop() methods are called.<br />
* Why the BundleContext can be kept as a <code>private static</code> class member ?<br />
<br />
=II. Pure-OSGi service=<br />
<br />
# Create an new bundle project ''fr.erods.tp.api''.<br />
#* Activator is not needed: uncheck "Generate an activator" in step 2<br />
# Create the <code>fr.erods.tp.api.IScheduleService</code> interface with two methods:<br />
#* <code>int createJob(Runnable aRunnable, int aDelay)</code><br />
#* <code>void deleteJob(int aId)</code><br />
# Export the API package<br />
#* Open the Manifest.mf file of ''fr.erods.tp.api''<br />
#* In tab "Runtime" > "Exported Packages" > Add<br />
#** Select the <code>fr.erods.tp.api</code> package<br />
# Implement the service in bundle 1<br />
#* Create the class <code>fr.erods.tp.bundle1.ScheduleImpl</code>, implementing <code>IScheduleService</code> in the bundle 1.<br />
# Register the service with the activator of bundle 1<br />
#* see [http://www.osgi.org/javadoc/r4v43/core/org/osgi/framework/BundleContext.html#registerService%28java.lang.Class,%20S,%20java.util.Dictionary%29 registerService()]<br />
#* see [http://www.osgi.org/javadoc/r4v43/core/org/osgi/framework/ServiceRegistration.html#unregister%28%29 unregister()]<br />
# Implement a service consumer in a new bundle<br />
#* Create project ''fr.erods.tp.bundle2''<br />
#* Import the API package<br />
#** In the Manifest.mf file of bundle 2<br />
#** In tab "Dependencies" > "Imported Packages" > Add<br />
#** Select the <code>fr.erods.tp.api</code> package<br />
#* Implement a <code>Consumer</code> class, implementing the OSGi <code>ServiceListener</code>[http://www.osgi.org/javadoc/r4v43/core/org/osgi/framework/ServiceListener.html] interface<br />
#* Print a message when the service is bound/unbound<br />
# Test the bundles in Felix<br />
<br />
Questions:<br />
* What happens when the consumer is started after the service bundle and why ?<br />
* Correct this behavior, using [http://www.osgi.org/javadoc/r4v43/core/org/osgi/framework/BundleContext.html#getServiceReference%28java.lang.Class%29 getServiceReference()] and [http://www.osgi.org/javadoc/r4v43/core/org/osgi/framework/BundleContext.html#getService%28org.osgi.framework.ServiceReference%29 getService()]<br />
<br />
=II. iPOJO: provide and consume with iPOJO=<br />
<br />
# Add the iPOJO Nature to projects ''bundle 1'' and ''bundle 2''<br />
#* Select the projects<br />
#* Right click > Add iPOJO Nature<br />
#* Check ''Use annotations''<br />
<br />
==Consumer==<br />
<br />
# Implement a <code>ConsumerIpojo</code> class in bundle 2<br />
#* See [http://felix.apache.org/site/how-to-use-ipojo-annotations.html How to use iPOJO Annotations]<br />
#* The component must be instantiated automatically<br />
#* Print a message when the component is (in)validated and when the service is (un)bound<br />
# Test<br />
# Set the service requirement as optional<br />
# Test<br />
<br />
Questions:<br />
* Why are the callbacks called in that order ?<br />
* What happens if you use a missing optional requirement ?<br />
<br />
==Provider==<br />
<br />
# Implement a <code>ServiceProviderIpojo</code> class in bundle 1<br />
#* See [http://felix.apache.org/site/how-to-use-ipojo-annotations.html How to use iPOJO Annotations]<br />
#* The component must be instantiated automatically<br />
#* The component must provide its service<br />
#* Print a message when the component is (in)validated<br />
# Test<br />
# Add a ''service controller'' and alternate the service presence<br />
# Test<br />
<br />
Question:<br />
* How does the consumers react to the service presence cycle ?<br />
<br />
==Bonus==<br />
<br />
# Add a "service.ranking" property to the pure-OSGi and the iPOJO service, and an "implementation" property to identify them<br />
# Print the name of the implementation the consumers are bound to<br />
# Modify the ranking value<br />
<br />
Question:<br />
* How does a service the service selection works ?<br />
<br />
''Note'': The consumer should call methods of the service and traces should be printed in order to show which service the consumer is bound to.<br />
<br />
=III. Whiteboard pattern=<br />
<br />
# Create interface <code>IJobListener</code> in the API package, with two methods:<br />
#* <code>void onJobCreation(int aId)</code><br />
#* <code>void onJobDeletion(int aId)</code><br />
# Create a new bundle project ''fr.erods.tp.bundle3''<br />
#* Add the iPOJO Nature and annotations<br />
#* Let it import the API package<br />
# Create a component providing an <code>IJobListener</code> service in bundle 3<br />
# Add job creation / deletion operations in a consumer<br />
<br />
==Subscription pattern==<br />
<br />
# Modify the schedule component to allow listeners registration:<br />
#* <code>void addListener(IJobListener)</code><br />
#* <code>void removeListener(IJobListener)</code><br />
# Register component of bundle 3 as a job listener<br />
# Test<br />
<br />
==Whiteboard pattern==<br />
<br />
# Modify the schedule component (in bundle 1)<br />
#* Remove the registration methods created above<br />
#* Add a requirement to an array of <code>IJobListener</code>s, as an optional requirement<br />
#* Notify them on job creation/deletion<br />
# Test<br />
<br />
Questions:<br />
* What are the pros/cons of the whiteboard pattern vs. the subscription pattern ?<br />
* Bonus: compare this whiteboard pattern implementation with the iPOJO Whiteboard pattern handler[http://felix.apache.org/site/white-board-pattern-handler.html]<br />
<br />
=IV. JMX MBean with iPOJO=<br />
<br />
# Create a new bundle, with iPOJO Nature and annotations<br />
# Create a component, which doesn't provide any service, but contains public methods to create/delete/list <code>IScheduleService</code> jobs<br />
# Use iPOJO JMX annotations[http://felix.apache.org/site/how-to-use-ipojo-annotations.html#HowtouseiPOJOAnnotations-ExposinginstancesasaJMXMBean%28externalhandler%29] to export those methods<br />
# You will need the iPOJO JMX handler to test this component: install it using the following command in the Felix shell:<br />
#* <code>obr:deploy -s "Apache Felix iPOJO JMX Handler</code><br />
# Install the bundle in the Felix framework<br />
# Run <code>jconsole</code> (in the Oracle Java distribution) or <code>jvisualvm</code> (in the Oracle Java distribution) or <code>visualvm</code>[http://visualvm.java.net/download.html]<br />
#* You might need to install the JMX plug-in in VisualVM:<br />
#** Tools > Plugins > Available Plugi-ns<br />
#** Install the ''VisualVM-MBeans'' plug-in<br />
# Connect VisualVM to your Felix JVM and play with the JMX beans<br />
<br />
=V. Gogo Command with iPOJO=<br />
<br />
# Create a new bundle, with iPOJO Nature and annotations<br />
# Create a Gogo command provider to create and delete jobs, and to list current jobs status<br />
<br />
==Minimal Gogo command component==<br />
<br />
<pre><br />
import org.apache.felix.ipojo.annotations.Component;<br />
import org.apache.felix.ipojo.annotations.Instantiate;<br />
import org.apache.felix.ipojo.annotations.Provides;<br />
import org.apache.felix.ipojo.annotations.ServiceProperty;<br />
import org.apache.felix.service.command.Descriptor;<br />
<br />
@Component(immediate = true)<br />
// Provide the component class as a service<br />
@Provides(specifications = ListComponentsCommand.class)<br />
// Instantiate the component automatically<br />
@Instantiate<br />
public class ListComponentsCommand {<br />
<br />
// Gogo scope/namespace<br />
@ServiceProperty(name = "osgi.command.scope", value = "test")<br />
String scope;<br />
<br />
// Gogo commands provided by this class (must be methods names)<br />
@ServiceProperty(name = "osgi.command.function", value = "{}")<br />
String[] function = new String[] { "test" };<br />
<br />
// Method description<br />
@Descriptor("test")<br />
public void test() {<br />
System.out.println("test!");<br />
}<br />
}<br />
</pre><br />
<br />
=VI. Config Admin with iPOJO=<br />
<br />
See [http://felix.apache.org/site/combining-ipojo-and-configuration-admin.html Combining iPOJO and Configuration Admin]<br />
<br />
=VII. Event Admin with iPOJO=<br />
1. Create a new bundle, with iPOJO annotations to send events on jobs status changes<br />
<br />
=VIII. Extender with iPOJO=<br />
??<br />
<br />
=Guidelines & Good Practices ("OSGi Zen")=<br />
<br />
* Always separate API and implementations<br />
* Always release services and resources once you're done or when their bundle is stopping<br />
* Always indicate requested/provided packages versions<br />
* Avoid <code>public static</code> class members<br />
** <code>private static</code> are allowed<br />
** Use interfaces to declare constants</div>Calmant