air - User contributions [en]

TAGL/TP

2015-02-26T16:52:43Z

MatthieuCaneill: /* Contrôle Continu */

Travaux pratiques de l'UE [[TAGL]].

Anciennes versions : [[TAGL/TP 2014]]

=Séance 1 : Gestion de versions=
==Git==

Création d'un dépôt Git local

===Méthode simple: init first===

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".
Cette méthode est la plus simple, car on dispose immédiatement d'un répertoire de travail.

<syntaxhighlight lang="bash">
# Création d'un dépôt Git dans le dossier simple-repo
git init simple-repo

# Création d'un README
cd simple-repo
echo "Hello, World" > README

# Ajout du versionnement du fichier README
git add README

# Commit
git commit
</syntaxhighlight>

À ce niveau, on a un dépôt Git complètement fonctionnel.
Cependant, il est intéressant de pousser ses modifications vers un autre dépôt, sur une autre machine.
On va donc créer un dépôt bare sur une autre machine (ou autre dossier pour l'exemple)

<syntaxhighlight lang="bash">
git init --bare server-repo
</syntaxhighlight>

On considère que l'URL pour accéder à ce dépôt est URL_REPO.
On va d'abord ajouter ce dépôt serveur à la liste des dépôts connu-repos de votre dépôt local.
Étant donné qu'il s'agit du dépôt "principal" à utiliser, on l'appellera //origin//, par convention.

<syntaxhighlight lang="bash">
git remote add origin URL_REPO
# Récupération de ses informations
git fetch origin
</syntaxhighlight>

Ce serveur distant est "vide": il n'a aucune branche. On va donc enregistrer notre branche sur le serveur

<syntaxhighlight lang="bash">
git push origin master
</syntaxhighlight>

À partir de cette commande, la branche locale //master// sera liée à la branche distante //origin/master//.
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.

===Méthode moins simple: bare first===

Si on commence dans par le serveur "vide", il faudra le cloner au lieu de le définir comme un dépôt distant.

<syntaxhighlight lang="bash">
# Création du dépôt vide
git init --bare server-repo
</syntaxhighlight>

On considère que ce dépôt est accessible à l'URL URL_REPO

<syntaxhighlight lang="bash">
# Clonage du dépôt
git clone URL_REPO clone-repo
</syntaxhighlight>

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.
Le dépôt distant est automatiquement appelé //origin//.

<syntaxhighlight lang="bash">
# Commit dans le dépôt local
cd clone-repo
echo hello > readme.rst
git add readme.rst
git commit et ses dépendances
</syntaxhighlight>

Comme dans la méthode simple, il faut pousser la branche master vers le dépôt distant:

<syntaxhighlight lang="bash">
git push origin master
</syntaxhighlight>

===De l'importance des README===

Il est très important d'avoir au moins 2 fichiers dans votre dépôt Git:

* LICENSE: contenant le texte **complet** de la licence de votre projet
* README: décrivant votre projet et comment l'utiliser. Ce fichier doit rappeler le nom de la licence de votre projet

Il est aussi recommandé d'avoir les fichiers suivants:

* AUTHORS: contenant la liste des noms/pseudos et e-mails des auteurs de commits ou de code inclus dans ce projet
* INSTALL: contenant la liste des dépendances de ce projet et des commandes à utiliser pour le compiler et l'installer

Les fichiers LICENSE sont des fichiers textes bruts.
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)

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]

=Séance 2a: Intégration en continue=

===GitHub & [[Travis-CI]]===

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.
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.

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.

Pour utiliser [[Travis-CI]]:

# Créez compte individuel sur GitHub https://github.com
# ''Fork''ez le dépôt https://github.com/heroku/node-js-getting-started
# Ajoutez un collaborateur (i.e. votre binôme) au projet ''forké'', via les paramètres (''settings'') de ce projet
# 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.
# Activez le service Travis-CI: identifiez-vous (''sign in'') sur https://travis-ci.org/ avec votre compte GitHub
# Activez le service pour les projets sur lesquels vous souhaitez appliquer les principes d'intégration continue

[[Travis-CI]] utilise un fichier nommé '''.travis.yml''' (attention: fichier caché sous Unix) pour se configurer et choisir les opérations à effectuer.
Ce fichier doit se trouver à la racine de votre dépôt Git.

Faites un '''Commit''' puis un '''Push''' du fichier '''.travis.yml''' ci-dessous.

<pre>
language: node_js
node_js:
- "0.11"
- "0.10"
- "0.8"
- "0.6"
- iojs
- iojs-v1.0.2

</pre>

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]].

Ajoutez dans le fichier '''package.json''' la section suivante:
<pre>
"devDependencies": {
"jshint": "^2.6.0"
},
"scripts": {
"test": "./node_modules/jshint/bin/jshint index.js"
}
</pre>
et incrémentez le numéro de version.

Faites un '''Commit''' puis un '''Push''' des fichiers touchés.

'''Remarque:'''
'''jshint''' peut être lancé localement avec les commandes suivantes:
<pre>
sudo npm install jshint
jshint index.js
</pre>

A lire
* http://docs.travis-ci.com/user/languages/javascript-with-nodejs/
* https://github.com/docdis/learn-travis/blob/master/README.md

=Séance 2b: Livraison en continue=

==[[Heroku]]==
[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.

# Créez un compte gratuit sur [https://signup.heroku.com Heroku]
# Forkez le dépôt https://github.com/heroku/node-js-getting-started
# Dans Heroku, créez une nouvelle app Node.js, et liez-la au repository Github créé à l'étape précédente
# Choisissez l'option "Déploiement automatique" depuis la branche **master**
# Modifiez le fichier index.js pour afficher la version de service dans la page HTML
<pre>
var fs = require('fs');
var package = JSON.parse(fs.readFileSync('./package.json', 'utf8'));
var version=package.version;
...
response.send('Hello World! (current version: '+version+')');
...
</pre>

Incrémentez le numéro de version dans le fichier ''package.json''

Faites un '''Commit''' puis un '''Push''' des fichiers touchés.

Naviguez l'application sur Heroku

# Modifiez le fichier index.js pour franciser le message dans la page HTML
<pre>
...
response.send('Bonjour Tout Le Monde! (version courante: '+version+')');
...
</pre>

Incrémentez le numéro de version dans le fichier '''package.json''

Faites un '''Commit''' puis un '''Push''' des fichiers touchés.

Naviguez l'application sur Heroku

=Séance 3: Builders=

==[[Ant]]==

==[[Maven]]==

[http://maven.apache.org/download.cgi Charger et installer Maven 3].

Debian/Ubuntu & friends:
<pre>
sudo apt-get update && sudo apt-get install maven
</pre>

<pre>
mvn -version
</pre>

Faites une copie du projet, basée sur Maven:

# Dans votre dépôt Git, créez un dossier '''cron4j-mvn''': il contiendra le projet Cron4J avec la structure Maven
# 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):
#:<pre>mvn archetype:generate -DarchetypeGroupId=org.apache.maven.archetypes -DarchetypeArtifactId=maven-archetype-quickstart</pre>
# Cette commande crée un projet avec un fichier ''pom.xml'', et une classe et un test modèles: supprimez ces modèles
# Copiez les sources de Cron4J depuis le dossier '''cron4j-original''' dans le dossier '''src/main/java''' de votre projet Maven
# Faites un essai de compilation:
#:<pre>mvn clean verify</pre>
# 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])
# 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.

==Tests Unitaires avec JUnit 4==
Survoller le tutoriel [http://www.vogella.com/tutorials/JUnit/article.html Unit Testing with JUnit]

# Veillez à bien utiliser la dépendance JUnit 4.8.2 dans pom.xml
# Ajouter le test unitaire suivant au projet, dans le fichier '''src/test/it/sauronsoftware/SchedulingPatternTest.java
<pre>
package it.sauronsoftware;

import it.sauronsoftware.cron4j.SchedulingPattern;
import it.sauronsoftware.cron4j.InvalidPatternException;

import static org.junit.Assert.assertEquals;
import static org.junit.Assert.assertTrue;

import org.junit.AfterClass;
import org.junit.BeforeClass;
import org.junit.Test;

public class SchedulingPatternTest {

@BeforeClass
public static void testSetup() {
}

@AfterClass
public static void testCleanup() {
// Teardown for data used by the unit tests
}

@Test(expected = InvalidPatternException.class)
public void testExceptionIsThrown() {
SchedulingPattern sp = new SchedulingPattern("0 5 * *");
}

@Test
public void testPattern() {
String pattern;
pattern="0 5 * * *|8 10 * * *|22 17 * * *";
assertTrue(pattern + "is correct", SchedulingPattern.validate(pattern));
pattern="0 5 * *";
assertTrue(pattern + "is correct", SchedulingPattern.validate(pattern));
}
}
</pre>

# Committez et Pushez ce nouveau fichier, pour que Travis lance les tests dès que possible
# Lancez les tests unitaires avec <pre>mvn test</pre> Ce test va '''échouer''': corrigez le.
# Committez et Pushez la version corrigée des tests: Travis enverra un mail pour indiquer si les tests échouent ou non
#: '''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.
# Naviguez sur http://travis-ci.org pour vérifier les builds effectués.
# Créez des tests unitaires supplémentaire du i.s.c.CronParser

===[[Maven]] avec [[Travis-CI]]===

===Git (suite)===

# Forkez le projet '''tagl''' d'un autre binome (i.e. autre que ''donsez/tagl'')
#: '''Attention:''' donnez lui un nom différent (e.g. ''tagl-licensing'')
# Clonez ce nouveau dépôt
# Lancez une compilation pour valider l'état du projet (bonne pratique)
#:<pre>mvn clean verify</pre>
# Situez vous dans une nouvelle branch git:
#:<pre>git checkout -b add-license</pre>
# Ajoutez une bannière de licence dans le fichier '''cron4j-mvn/pom.xml'''
# Lancez une nouvelle compilation pour valider vos modifications
# 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)
# Via le site de GitHub, proposez un "Pull Request" au projet initial

Vous pouvez ensuite supprimer le clone de ce fork.
Lorsque le ''pull request'' aura été accepté, vous pourrez supprimer votre fork (''tagl-licensing'') de votre compte GitHub.

===Contrôle Continu===

Dans votre dépôt ''tagl''.

# Ajoutez le plugin [http://mojo.codehaus.org/cobertura-maven-plugin/usage.html Cobertura] à votre projet Maven.
## 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''
## Le plugin ne s'exécute automatiquement pas durant la compilation, il faut utiliser la commande : <pre>mvn cobertura:cobertura</pre>
## '''Bonus:''' Modifiez le fichier ''pom.xml'' pour que le ''goal'' '''cobertura''' soit exécuté pendant la ''phase'' '''package'''.
# Répondez aux questions : ''Mais qu'est ce que la couverture de code ? En quoi c'est utile ?''
# 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.
# Regardez les exemples d'utilisation de cron4j dans cron4j-original/examples
# À rendre : pom.xml

===Bonus Track===

====Clone SVN -> Git====

Source: http://www.yterium.net/Migrer-un-projet-SVN-vers-GIT

<syntaxhighlight lang="bash">
# Cloner le dépôt SVN en dépôt Git (conservation historique)
$ git svn clone svn://svn.code.sf.net/p/cron4j/code/trunk cron4j-original
$ cd cron4j-original
# Test compilation
$ ant jar
$ cd ..
</syntaxhighlight>

====Préparation TAGL====

<syntaxhighlight lang="bash">
# Clone du dépôt TAGL
$ git clone git@github.com:donsez/tagl.git
$ cd tagl
# "Fetch" du dépôt local cloné précédemment
$ git fetch file://$(pwd)/../cron4j-original
# Fusion de ce qui vient d'être fetché
$ git merge FETCH_HEAD
# Envoi sur le serveur
$ git push
</syntaxhighlight>

====Cherry-picking: reprise des modifications d'un collègue====

On considère que:

* votre dépôt Git distant est à l'adresse URL_DEPOT
* votre collègue a un dépôt Git à l'adresse URL_COLLEGUE

<syntaxhighlight lang="bash">
# Dossier temporaire
cd /tmp

# Clone de votre dépôt
git clone URL_DEPOT mon_depot

# Déplacement dans votre dépôt
cd mon_depot

# Définition du dépôt distant
git remote add collegue URL_COLLEGUE

# Récupération des infos du dépôt du collègue
git fetch collegue

# Maintenant, on peut voir les branches du collègue
git branch -a

# On peut fusionner avec une branche
git merge collegue/master

# Si vous avez des conflits, éditez les fichiers concernés,
# et committez avec git commit

# Push vers votre dépôt distant
git push origin

# Optionnel: supprimez la référence vers le dépôt du collègue
git remote rm collegue
</syntaxhighlight>

====Archetype webapp====
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].

<syntaxhighlight lang="bash">
mvn -Djetty.port=9999 jetty:run
</syntaxhighlight>

Naviguez sur http://localhost:9999/monsite

====Scrum tools====
Ces 3 services peuvent être couplé à votre dépôt GitHub pour votre gestion de projet agile avec [[Scrum]] :
* http://www.acunote.com/
* http://backlogtool.com/
* http://www.scrumdo.com/

L'activation se fait via ''Settings > Webhooks & Services > Configure services''.

=Séance 4: AOP & AspectJ=

Dans votre dépôt Git, projet ''cron4j-mvn''.

# Ajoutez le [http://mojo.codehaus.org/aspectj-maven-plugin/ plugin Maven pour AspectJ] au pom.xml
# Ajoutez un aspect de trace à l'invocation des méthodes '''run()''' de l'interface java.lang.Runnable (uniquement pour les objets ''schedulé''s)
#: Affichez une trace avant et après l'exécution de la tâche
# 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 "* * * * *")
#: Lors de l'exécution de '''mvn test''', vous devez voir apparaître les traces préparées dans votre aspect.

Liens utiles:
* [http://ridgetopsolutions.com/blog/2013/02/12/getting-started-with-aspectj-and-maven/ Getting started with AspectJ and Maven]

===Contrôle continu===

# 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.

=Séance 5: Pelix & iPOPO=

Pelix est une plate-forme d'application à services (SOA).
iPOPO est un modèle de composants orientés services (SOCM).

La documentation de Pelix et iPOPO est disponible sur https://ipopo.coderxpress.net/

===Installation de iPOPO===

* Cloner le dépôt Git depuis https://github.com/tcalmant/ipopo
* Se placer dans la branche ''dev''
* Pour installer iPOPO, lancer la commande :

sudo python setup.py install

===Shell Pelix===

Pour lancer un shell Pelix, utilisez la commande:

python -m pelix.shell.console

Les commandes disponibles sont décrites ici: [https://ipopo.coderxpress.net/wiki/doku.php?id=ipopo:refcards:shell Shell Commands]

===Rappels de Python===

* Pas de déclaration du type d'une variable
* Les méthodes d'une classe ont toute comme premier paramètre ''self'', équivalent du ''this'' en Java.
* Blocs définis par indentation (4 espaces ou 1 tab)
* Une ligne finissant par ':' démarre toujours un bloc

<syntaxhighlight lang="python">
# Import d'un module
import pelix

# Définition d'une classe
class MaClasse:
# Constructeur
def __init__(self):
self.default = "stanger"
print("Classe construite")

# Méthode, avec un argument
def sayHello(self, name):
if not name:
# Nom vide ou nul
return "Hello, " + str(self.default)
else:
# Nom valide
return "Hello, " + str(name)

objet = MaClasse()
print(objet.sayHello(""))
print(objet.sayHello("World"))
</syntaxhighlight>

===Service Ping-Pong===

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:".

Exemple:

pong = Pong()
pong.pong("Hello") # <-- Retourne "PONG:Hello"

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:"

Exemple:

ping = Ping()
ping.ping("Hello") # <-- Retourne "PING:PONG:Hello"

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"
* Définir une classe ''Activator'', décorée avec ''@BundleActivator''
* Enregistrer le service dans la méthode ''Activator.start'' et le désenregistrer dans ''Activator.stop''
* S'inspirer du fichier "ipopo/samples/remote/provider.py"

Dans un shell Pelix, installer et démarrer le bundle 'pong' et vérifier que le service est bien inscrit avec la commande ''sl''

4.Transformer la classe ''Ping'' dans ''ping.py'' en un composant iPOPO
* L'objet Pong utilisé dans ''ping()'' doit être un service injecté par iPOPO (''@Requires'')
* Appeler la méthode ''ping()'' dès que le service Pong est injecté (''@BindField'') ou disparait (''@UnbindField'')
* S'inspirer du fichier "ipopo/samples/remote/consumer.py"

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é.

5. Mettre à jour le bundle ''pong''
* Remplacer le préfixe "PONG" par "NI"
* Dans le shell Pelix, mettre à jour le bundle ''pong'' sans redémarrer la plate-forme (commande ''udpate'').
* Vérifier les traces dans le shell pour valider la mise à jour du service.

===Remote Services===

* Ajouter les propriétés permettant l'export du service Pong dans ''pong.py'' (s'inspirer de ''provider.py'')

* Lancer deux shells iPOPO (dans deux terminaux)
* Dans chaque shell iPOPO, installer les bundles:
** ''pelix.remote.dispatcher'': Exportateur de services
** ''pelix.remote.registry''; Importateur de services
** ''pelix.remote.discovery.multicast'': Découverte de services via Multicast
** ''pelix.remote.xml_rpc'': Transport XML-RPC
** ''pelix.http.basic'': Serveur HTTP

Attention: il peut être nécessaire de désactiver votre pare-feu pour que les Remote Services fonctionnent

* Instancier les composants depuis le shell iPOPO, dans chaque framework:
** 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)
** Multicast Discovery: ''instantiate pelix-remote-discovery-multicast-factory multicast-discovery''
** XML-RPC Exporter: ''instantiate pelix-xmlrpc-exporter-factory xml-rpc-exporter''
** XML-RPC Importer: ''instantiate pelix-xmlrpc-exporter-factory xml-rpc-importer''

* Installer le bundle ''ping'' dans un des frameworks et le bundle ''pong'' dans l'autre.
* Le composant ping peut appeler le service pong, qui est dans l'autre framework.

* Voir le code de ''run_remote.py'' pour voir comment démarrer un framework Pelix et installer des bundles depuis Python.
* Jouer un peu avec ''run_remote.py'' (voir ''run_remote.py --help'')

=Séance 6=
[[Tutorial OSGi avec Apache Felix]]

=Séance 7=
Faire un projet PDE pour un bundle cron4j.gogo (indépendant de cron4j.bundle)

Utilisation de https://eclipse.org/tycho/

TAGL/TP

2015-02-26T16:46:49Z

MatthieuCaneill: /* Git (suite) */

Travaux pratiques de l'UE [[TAGL]].

Anciennes versions : [[TAGL/TP 2014]]

=Séance 1 : Gestion de versions=
==Git==

Création d'un dépôt Git local

===Méthode simple: init first===

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".
Cette méthode est la plus simple, car on dispose immédiatement d'un répertoire de travail.

<syntaxhighlight lang="bash">
# Création d'un dépôt Git dans le dossier simple-repo
git init simple-repo

# Création d'un README
cd simple-repo
echo "Hello, World" > README

# Ajout du versionnement du fichier README
git add README

# Commit
git commit
</syntaxhighlight>

À ce niveau, on a un dépôt Git complètement fonctionnel.
Cependant, il est intéressant de pousser ses modifications vers un autre dépôt, sur une autre machine.
On va donc créer un dépôt bare sur une autre machine (ou autre dossier pour l'exemple)

<syntaxhighlight lang="bash">
git init --bare server-repo
</syntaxhighlight>

On considère que l'URL pour accéder à ce dépôt est URL_REPO.
On va d'abord ajouter ce dépôt serveur à la liste des dépôts connu-repos de votre dépôt local.
Étant donné qu'il s'agit du dépôt "principal" à utiliser, on l'appellera //origin//, par convention.

<syntaxhighlight lang="bash">
git remote add origin URL_REPO
# Récupération de ses informations
git fetch origin
</syntaxhighlight>

Ce serveur distant est "vide": il n'a aucune branche. On va donc enregistrer notre branche sur le serveur

<syntaxhighlight lang="bash">
git push origin master
</syntaxhighlight>

À partir de cette commande, la branche locale //master// sera liée à la branche distante //origin/master//.
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.

===Méthode moins simple: bare first===

Si on commence dans par le serveur "vide", il faudra le cloner au lieu de le définir comme un dépôt distant.

<syntaxhighlight lang="bash">
# Création du dépôt vide
git init --bare server-repo
</syntaxhighlight>

On considère que ce dépôt est accessible à l'URL URL_REPO

<syntaxhighlight lang="bash">
# Clonage du dépôt
git clone URL_REPO clone-repo
</syntaxhighlight>

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.
Le dépôt distant est automatiquement appelé //origin//.

<syntaxhighlight lang="bash">
# Commit dans le dépôt local
cd clone-repo
echo hello > readme.rst
git add readme.rst
git commit et ses dépendances
</syntaxhighlight>

Comme dans la méthode simple, il faut pousser la branche master vers le dépôt distant:

<syntaxhighlight lang="bash">
git push origin master
</syntaxhighlight>

===De l'importance des README===

Il est très important d'avoir au moins 2 fichiers dans votre dépôt Git:

* LICENSE: contenant le texte **complet** de la licence de votre projet
* README: décrivant votre projet et comment l'utiliser. Ce fichier doit rappeler le nom de la licence de votre projet

Il est aussi recommandé d'avoir les fichiers suivants:

* AUTHORS: contenant la liste des noms/pseudos et e-mails des auteurs de commits ou de code inclus dans ce projet
* INSTALL: contenant la liste des dépendances de ce projet et des commandes à utiliser pour le compiler et l'installer

Les fichiers LICENSE sont des fichiers textes bruts.
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)

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]

=Séance 2a: Intégration en continue=

===GitHub & [[Travis-CI]]===

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.
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.

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.

Pour utiliser [[Travis-CI]]:

# Créez compte individuel sur GitHub https://github.com
# ''Fork''ez le dépôt https://github.com/heroku/node-js-getting-started
# Ajoutez un collaborateur (i.e. votre binôme) au projet ''forké'', via les paramètres (''settings'') de ce projet
# 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.
# Activez le service Travis-CI: identifiez-vous (''sign in'') sur https://travis-ci.org/ avec votre compte GitHub
# Activez le service pour les projets sur lesquels vous souhaitez appliquer les principes d'intégration continue

[[Travis-CI]] utilise un fichier nommé '''.travis.yml''' (attention: fichier caché sous Unix) pour se configurer et choisir les opérations à effectuer.
Ce fichier doit se trouver à la racine de votre dépôt Git.

Faites un '''Commit''' puis un '''Push''' du fichier '''.travis.yml''' ci-dessous.

<pre>
language: node_js
node_js:
- "0.11"
- "0.10"
- "0.8"
- "0.6"
- iojs
- iojs-v1.0.2

</pre>

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]].

Ajoutez dans le fichier '''package.json''' la section suivante:
<pre>
"devDependencies": {
"jshint": "^2.6.0"
},
"scripts": {
"test": "./node_modules/jshint/bin/jshint index.js"
}
</pre>
et incrémentez le numéro de version.

Faites un '''Commit''' puis un '''Push''' des fichiers touchés.

'''Remarque:'''
'''jshint''' peut être lancé localement avec les commandes suivantes:
<pre>
sudo npm install jshint
jshint index.js
</pre>

A lire
* http://docs.travis-ci.com/user/languages/javascript-with-nodejs/
* https://github.com/docdis/learn-travis/blob/master/README.md

=Séance 2b: Livraison en continue=

==[[Heroku]]==
[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.

# Créez un compte gratuit sur [https://signup.heroku.com Heroku]
# Forkez le dépôt https://github.com/heroku/node-js-getting-started
# Dans Heroku, créez une nouvelle app Node.js, et liez-la au repository Github créé à l'étape précédente
# Choisissez l'option "Déploiement automatique" depuis la branche **master**
# Modifiez le fichier index.js pour afficher la version de service dans la page HTML
<pre>
var fs = require('fs');
var package = JSON.parse(fs.readFileSync('./package.json', 'utf8'));
var version=package.version;
...
response.send('Hello World! (current version: '+version+')');
...
</pre>

Incrémentez le numéro de version dans le fichier ''package.json''

Faites un '''Commit''' puis un '''Push''' des fichiers touchés.

Naviguez l'application sur Heroku

# Modifiez le fichier index.js pour franciser le message dans la page HTML
<pre>
...
response.send('Bonjour Tout Le Monde! (version courante: '+version+')');
...
</pre>

Incrémentez le numéro de version dans le fichier '''package.json''

Faites un '''Commit''' puis un '''Push''' des fichiers touchés.

Naviguez l'application sur Heroku

=Séance 3: Builders=

==[[Ant]]==

==[[Maven]]==

[http://maven.apache.org/download.cgi Charger et installer Maven 3].

Debian/Ubuntu & friends:
<pre>
sudo apt-get update && sudo apt-get install maven
</pre>

<pre>
mvn -version
</pre>

Faites une copie du projet, basée sur Maven:

# Dans votre dépôt Git, créez un dossier '''cron4j-mvn''': il contiendra le projet Cron4J avec la structure Maven
# 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):
#:<pre>mvn archetype:generate -DarchetypeGroupId=org.apache.maven.archetypes -DarchetypeArtifactId=maven-archetype-quickstart</pre>
# Cette commande crée un projet avec un fichier ''pom.xml'', et une classe et un test modèles: supprimez ces modèles
# Copiez les sources de Cron4J depuis le dossier '''cron4j-original''' dans le dossier '''src/main/java''' de votre projet Maven
# Faites un essai de compilation:
#:<pre>mvn clean verify</pre>
# 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])
# 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.

==Tests Unitaires avec JUnit 4==
Survoller le tutoriel [http://www.vogella.com/tutorials/JUnit/article.html Unit Testing with JUnit]

# Veillez à bien utiliser la dépendance JUnit 4.8.2 dans pom.xml
# Ajouter le test unitaire suivant au projet, dans le fichier '''src/test/it/sauronsoftware/SchedulingPatternTest.java
<pre>
package it.sauronsoftware;

import it.sauronsoftware.cron4j.SchedulingPattern;
import it.sauronsoftware.cron4j.InvalidPatternException;

import static org.junit.Assert.assertEquals;
import static org.junit.Assert.assertTrue;

import org.junit.AfterClass;
import org.junit.BeforeClass;
import org.junit.Test;

public class SchedulingPatternTest {

@BeforeClass
public static void testSetup() {
}

@AfterClass
public static void testCleanup() {
// Teardown for data used by the unit tests
}

@Test(expected = InvalidPatternException.class)
public void testExceptionIsThrown() {
SchedulingPattern sp = new SchedulingPattern("0 5 * *");
}

@Test
public void testPattern() {
String pattern;
pattern="0 5 * * *|8 10 * * *|22 17 * * *";
assertTrue(pattern + "is correct", SchedulingPattern.validate(pattern));
pattern="0 5 * *";
assertTrue(pattern + "is correct", SchedulingPattern.validate(pattern));
}
}
</pre>

# Committez et Pushez ce nouveau fichier, pour que Travis lance les tests dès que possible
# Lancez les tests unitaires avec <pre>mvn test</pre> Ce test va '''échouer''': corrigez le.
# Committez et Pushez la version corrigée des tests: Travis enverra un mail pour indiquer si les tests échouent ou non
#: '''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.
# Naviguez sur http://travis-ci.org pour vérifier les builds effectués.
# Créez des tests unitaires supplémentaire du i.s.c.CronParser

===[[Maven]] avec [[Travis-CI]]===

===Git (suite)===

# Forkez le projet '''tagl''' d'un autre binome (i.e. autre que ''donsez/tagl'')
#: '''Attention:''' donnez lui un nom différent (e.g. ''tagl-licensing'')
# Clonez ce nouveau dépôt
# Lancez une compilation pour valider l'état du projet (bonne pratique)
#:<pre>mvn clean verify</pre>
# Situez vous dans une nouvelle branch git:
#:<pre>git checkout -b add-license</pre>
# Ajoutez une bannière de licence dans le fichier '''cron4j-mvn/pom.xml'''
# Lancez une nouvelle compilation pour valider vos modifications
# 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)
# Via le site de GitHub, proposez un "Pull Request" au projet initial

Vous pouvez ensuite supprimer le clone de ce fork.
Lorsque le ''pull request'' aura été accepté, vous pourrez supprimer votre fork (''tagl-licensing'') de votre compte GitHub.

===Contrôle Continu===

Dans votre dépôt ''tagl''.

# Ajoutez le plugin [http://mojo.codehaus.org/cobertura-maven-plugin/usage.html Cobertura] à votre projet Maven.
## 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''
## Le plugin ne s'exécute automatiquement pas durant la compilation, il faut utiliser la commande : <pre>mvn cobertura:cobertura</pre>
## '''Bonus:''' Modifiez le fichier ''pom.xml'' pour que le ''goal'' '''cobertura''' soit exécuté pendant la ''phase'' '''package'''.
# Répondez aux questions : ''Mais qu'est ce que la couverture de code ? En quoi c'est utile ?''
# 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.
# Regardez les exemples d'utilisation de cron4j dans cron4j-original/examples

===Bonus Track===

====Clone SVN -> Git====

Source: http://www.yterium.net/Migrer-un-projet-SVN-vers-GIT

<syntaxhighlight lang="bash">
# Cloner le dépôt SVN en dépôt Git (conservation historique)
$ git svn clone svn://svn.code.sf.net/p/cron4j/code/trunk cron4j-original
$ cd cron4j-original
# Test compilation
$ ant jar
$ cd ..
</syntaxhighlight>

====Préparation TAGL====

<syntaxhighlight lang="bash">
# Clone du dépôt TAGL
$ git clone git@github.com:donsez/tagl.git
$ cd tagl
# "Fetch" du dépôt local cloné précédemment
$ git fetch file://$(pwd)/../cron4j-original
# Fusion de ce qui vient d'être fetché
$ git merge FETCH_HEAD
# Envoi sur le serveur
$ git push
</syntaxhighlight>

====Cherry-picking: reprise des modifications d'un collègue====

On considère que:

* votre dépôt Git distant est à l'adresse URL_DEPOT
* votre collègue a un dépôt Git à l'adresse URL_COLLEGUE

<syntaxhighlight lang="bash">
# Dossier temporaire
cd /tmp

# Clone de votre dépôt
git clone URL_DEPOT mon_depot

# Déplacement dans votre dépôt
cd mon_depot

# Définition du dépôt distant
git remote add collegue URL_COLLEGUE

# Récupération des infos du dépôt du collègue
git fetch collegue

# Maintenant, on peut voir les branches du collègue
git branch -a

# On peut fusionner avec une branche
git merge collegue/master

# Si vous avez des conflits, éditez les fichiers concernés,
# et committez avec git commit

# Push vers votre dépôt distant
git push origin

# Optionnel: supprimez la référence vers le dépôt du collègue
git remote rm collegue
</syntaxhighlight>

====Archetype webapp====
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].

<syntaxhighlight lang="bash">
mvn -Djetty.port=9999 jetty:run
</syntaxhighlight>

Naviguez sur http://localhost:9999/monsite

====Scrum tools====
Ces 3 services peuvent être couplé à votre dépôt GitHub pour votre gestion de projet agile avec [[Scrum]] :
* http://www.acunote.com/
* http://backlogtool.com/
* http://www.scrumdo.com/

L'activation se fait via ''Settings > Webhooks & Services > Configure services''.

=Séance 4: AOP & AspectJ=

Dans votre dépôt Git, projet ''cron4j-mvn''.

# Ajoutez le [http://mojo.codehaus.org/aspectj-maven-plugin/ plugin Maven pour AspectJ] au pom.xml
# Ajoutez un aspect de trace à l'invocation des méthodes '''run()''' de l'interface java.lang.Runnable (uniquement pour les objets ''schedulé''s)
#: Affichez une trace avant et après l'exécution de la tâche
# 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 "* * * * *")
#: Lors de l'exécution de '''mvn test''', vous devez voir apparaître les traces préparées dans votre aspect.

Liens utiles:
* [http://ridgetopsolutions.com/blog/2013/02/12/getting-started-with-aspectj-and-maven/ Getting started with AspectJ and Maven]

===Contrôle continu===

# 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.

=Séance 5: Pelix & iPOPO=

Pelix est une plate-forme d'application à services (SOA).
iPOPO est un modèle de composants orientés services (SOCM).

La documentation de Pelix et iPOPO est disponible sur https://ipopo.coderxpress.net/

===Installation de iPOPO===

* Cloner le dépôt Git depuis https://github.com/tcalmant/ipopo
* Se placer dans la branche ''dev''
* Pour installer iPOPO, lancer la commande :

sudo python setup.py install

===Shell Pelix===

Pour lancer un shell Pelix, utilisez la commande:

python -m pelix.shell.console

Les commandes disponibles sont décrites ici: [https://ipopo.coderxpress.net/wiki/doku.php?id=ipopo:refcards:shell Shell Commands]

===Rappels de Python===

* Pas de déclaration du type d'une variable
* Les méthodes d'une classe ont toute comme premier paramètre ''self'', équivalent du ''this'' en Java.
* Blocs définis par indentation (4 espaces ou 1 tab)
* Une ligne finissant par ':' démarre toujours un bloc

<syntaxhighlight lang="python">
# Import d'un module
import pelix

# Définition d'une classe
class MaClasse:
# Constructeur
def __init__(self):
self.default = "stanger"
print("Classe construite")

# Méthode, avec un argument
def sayHello(self, name):
if not name:
# Nom vide ou nul
return "Hello, " + str(self.default)
else:
# Nom valide
return "Hello, " + str(name)

objet = MaClasse()
print(objet.sayHello(""))
print(objet.sayHello("World"))
</syntaxhighlight>

===Service Ping-Pong===

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:".

Exemple:

pong = Pong()
pong.pong("Hello") # <-- Retourne "PONG:Hello"

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:"

Exemple:

ping = Ping()
ping.ping("Hello") # <-- Retourne "PING:PONG:Hello"

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"
* Définir une classe ''Activator'', décorée avec ''@BundleActivator''
* Enregistrer le service dans la méthode ''Activator.start'' et le désenregistrer dans ''Activator.stop''
* S'inspirer du fichier "ipopo/samples/remote/provider.py"

Dans un shell Pelix, installer et démarrer le bundle 'pong' et vérifier que le service est bien inscrit avec la commande ''sl''

4.Transformer la classe ''Ping'' dans ''ping.py'' en un composant iPOPO
* L'objet Pong utilisé dans ''ping()'' doit être un service injecté par iPOPO (''@Requires'')
* Appeler la méthode ''ping()'' dès que le service Pong est injecté (''@BindField'') ou disparait (''@UnbindField'')
* S'inspirer du fichier "ipopo/samples/remote/consumer.py"

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é.

5. Mettre à jour le bundle ''pong''
* Remplacer le préfixe "PONG" par "NI"
* Dans le shell Pelix, mettre à jour le bundle ''pong'' sans redémarrer la plate-forme (commande ''udpate'').
* Vérifier les traces dans le shell pour valider la mise à jour du service.

===Remote Services===

* Ajouter les propriétés permettant l'export du service Pong dans ''pong.py'' (s'inspirer de ''provider.py'')

* Lancer deux shells iPOPO (dans deux terminaux)
* Dans chaque shell iPOPO, installer les bundles:
** ''pelix.remote.dispatcher'': Exportateur de services
** ''pelix.remote.registry''; Importateur de services
** ''pelix.remote.discovery.multicast'': Découverte de services via Multicast
** ''pelix.remote.xml_rpc'': Transport XML-RPC
** ''pelix.http.basic'': Serveur HTTP

Attention: il peut être nécessaire de désactiver votre pare-feu pour que les Remote Services fonctionnent

* Instancier les composants depuis le shell iPOPO, dans chaque framework:
** 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)
** Multicast Discovery: ''instantiate pelix-remote-discovery-multicast-factory multicast-discovery''
** XML-RPC Exporter: ''instantiate pelix-xmlrpc-exporter-factory xml-rpc-exporter''
** XML-RPC Importer: ''instantiate pelix-xmlrpc-exporter-factory xml-rpc-importer''

* Installer le bundle ''ping'' dans un des frameworks et le bundle ''pong'' dans l'autre.
* Le composant ping peut appeler le service pong, qui est dans l'autre framework.

* Voir le code de ''run_remote.py'' pour voir comment démarrer un framework Pelix et installer des bundles depuis Python.
* Jouer un peu avec ''run_remote.py'' (voir ''run_remote.py --help'')

=Séance 6=
[[Tutorial OSGi avec Apache Felix]]

=Séance 7=
Faire un projet PDE pour un bundle cron4j.gogo (indépendant de cron4j.bundle)

Utilisation de https://eclipse.org/tycho/

TAGL/TP

2015-02-26T16:46:08Z

MatthieuCaneill: /* Git (suite) */

Travaux pratiques de l'UE [[TAGL]].

Anciennes versions : [[TAGL/TP 2014]]

=Séance 1 : Gestion de versions=
==Git==

Création d'un dépôt Git local

===Méthode simple: init first===

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".
Cette méthode est la plus simple, car on dispose immédiatement d'un répertoire de travail.

<syntaxhighlight lang="bash">
# Création d'un dépôt Git dans le dossier simple-repo
git init simple-repo

# Création d'un README
cd simple-repo
echo "Hello, World" > README

# Ajout du versionnement du fichier README
git add README

# Commit
git commit
</syntaxhighlight>

À ce niveau, on a un dépôt Git complètement fonctionnel.
Cependant, il est intéressant de pousser ses modifications vers un autre dépôt, sur une autre machine.
On va donc créer un dépôt bare sur une autre machine (ou autre dossier pour l'exemple)

<syntaxhighlight lang="bash">
git init --bare server-repo
</syntaxhighlight>

On considère que l'URL pour accéder à ce dépôt est URL_REPO.
On va d'abord ajouter ce dépôt serveur à la liste des dépôts connu-repos de votre dépôt local.
Étant donné qu'il s'agit du dépôt "principal" à utiliser, on l'appellera //origin//, par convention.

<syntaxhighlight lang="bash">
git remote add origin URL_REPO
# Récupération de ses informations
git fetch origin
</syntaxhighlight>

Ce serveur distant est "vide": il n'a aucune branche. On va donc enregistrer notre branche sur le serveur

<syntaxhighlight lang="bash">
git push origin master
</syntaxhighlight>

À partir de cette commande, la branche locale //master// sera liée à la branche distante //origin/master//.
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.

===Méthode moins simple: bare first===

Si on commence dans par le serveur "vide", il faudra le cloner au lieu de le définir comme un dépôt distant.

<syntaxhighlight lang="bash">
# Création du dépôt vide
git init --bare server-repo
</syntaxhighlight>

On considère que ce dépôt est accessible à l'URL URL_REPO

<syntaxhighlight lang="bash">
# Clonage du dépôt
git clone URL_REPO clone-repo
</syntaxhighlight>

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.
Le dépôt distant est automatiquement appelé //origin//.

<syntaxhighlight lang="bash">
# Commit dans le dépôt local
cd clone-repo
echo hello > readme.rst
git add readme.rst
git commit et ses dépendances
</syntaxhighlight>

Comme dans la méthode simple, il faut pousser la branche master vers le dépôt distant:

<syntaxhighlight lang="bash">
git push origin master
</syntaxhighlight>

===De l'importance des README===

Il est très important d'avoir au moins 2 fichiers dans votre dépôt Git:

* LICENSE: contenant le texte **complet** de la licence de votre projet
* README: décrivant votre projet et comment l'utiliser. Ce fichier doit rappeler le nom de la licence de votre projet

Il est aussi recommandé d'avoir les fichiers suivants:

* AUTHORS: contenant la liste des noms/pseudos et e-mails des auteurs de commits ou de code inclus dans ce projet
* INSTALL: contenant la liste des dépendances de ce projet et des commandes à utiliser pour le compiler et l'installer

Les fichiers LICENSE sont des fichiers textes bruts.
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)

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]

=Séance 2a: Intégration en continue=

===GitHub & [[Travis-CI]]===

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.
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.

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.

Pour utiliser [[Travis-CI]]:

# Créez compte individuel sur GitHub https://github.com
# ''Fork''ez le dépôt https://github.com/heroku/node-js-getting-started
# Ajoutez un collaborateur (i.e. votre binôme) au projet ''forké'', via les paramètres (''settings'') de ce projet
# 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.
# Activez le service Travis-CI: identifiez-vous (''sign in'') sur https://travis-ci.org/ avec votre compte GitHub
# Activez le service pour les projets sur lesquels vous souhaitez appliquer les principes d'intégration continue

[[Travis-CI]] utilise un fichier nommé '''.travis.yml''' (attention: fichier caché sous Unix) pour se configurer et choisir les opérations à effectuer.
Ce fichier doit se trouver à la racine de votre dépôt Git.

Faites un '''Commit''' puis un '''Push''' du fichier '''.travis.yml''' ci-dessous.

<pre>
language: node_js
node_js:
- "0.11"
- "0.10"
- "0.8"
- "0.6"
- iojs
- iojs-v1.0.2

</pre>

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]].

Ajoutez dans le fichier '''package.json''' la section suivante:
<pre>
"devDependencies": {
"jshint": "^2.6.0"
},
"scripts": {
"test": "./node_modules/jshint/bin/jshint index.js"
}
</pre>
et incrémentez le numéro de version.

Faites un '''Commit''' puis un '''Push''' des fichiers touchés.

'''Remarque:'''
'''jshint''' peut être lancé localement avec les commandes suivantes:
<pre>
sudo npm install jshint
jshint index.js
</pre>

A lire
* http://docs.travis-ci.com/user/languages/javascript-with-nodejs/
* https://github.com/docdis/learn-travis/blob/master/README.md

=Séance 2b: Livraison en continue=

==[[Heroku]]==
[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.

# Créez un compte gratuit sur [https://signup.heroku.com Heroku]
# Forkez le dépôt https://github.com/heroku/node-js-getting-started
# Dans Heroku, créez une nouvelle app Node.js, et liez-la au repository Github créé à l'étape précédente
# Choisissez l'option "Déploiement automatique" depuis la branche **master**
# Modifiez le fichier index.js pour afficher la version de service dans la page HTML
<pre>
var fs = require('fs');
var package = JSON.parse(fs.readFileSync('./package.json', 'utf8'));
var version=package.version;
...
response.send('Hello World! (current version: '+version+')');
...
</pre>

Incrémentez le numéro de version dans le fichier ''package.json''

Faites un '''Commit''' puis un '''Push''' des fichiers touchés.

Naviguez l'application sur Heroku

# Modifiez le fichier index.js pour franciser le message dans la page HTML
<pre>
...
response.send('Bonjour Tout Le Monde! (version courante: '+version+')');
...
</pre>

Incrémentez le numéro de version dans le fichier '''package.json''

Faites un '''Commit''' puis un '''Push''' des fichiers touchés.

Naviguez l'application sur Heroku

=Séance 3: Builders=

==[[Ant]]==

==[[Maven]]==

[http://maven.apache.org/download.cgi Charger et installer Maven 3].

Debian/Ubuntu & friends:
<pre>
sudo apt-get update && sudo apt-get install maven
</pre>

<pre>
mvn -version
</pre>

Faites une copie du projet, basée sur Maven:

# Dans votre dépôt Git, créez un dossier '''cron4j-mvn''': il contiendra le projet Cron4J avec la structure Maven
# 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):
#:<pre>mvn archetype:generate -DarchetypeGroupId=org.apache.maven.archetypes -DarchetypeArtifactId=maven-archetype-quickstart</pre>
# Cette commande crée un projet avec un fichier ''pom.xml'', et une classe et un test modèles: supprimez ces modèles
# Copiez les sources de Cron4J depuis le dossier '''cron4j-original''' dans le dossier '''src/main/java''' de votre projet Maven
# Faites un essai de compilation:
#:<pre>mvn clean verify</pre>
# 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])
# 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.

==Tests Unitaires avec JUnit 4==
Survoller le tutoriel [http://www.vogella.com/tutorials/JUnit/article.html Unit Testing with JUnit]

# Veillez à bien utiliser la dépendance JUnit 4.8.2 dans pom.xml
# Ajouter le test unitaire suivant au projet, dans le fichier '''src/test/it/sauronsoftware/SchedulingPatternTest.java
<pre>
package it.sauronsoftware;

import it.sauronsoftware.cron4j.SchedulingPattern;
import it.sauronsoftware.cron4j.InvalidPatternException;

import static org.junit.Assert.assertEquals;
import static org.junit.Assert.assertTrue;

import org.junit.AfterClass;
import org.junit.BeforeClass;
import org.junit.Test;

public class SchedulingPatternTest {

@BeforeClass
public static void testSetup() {
}

@AfterClass
public static void testCleanup() {
// Teardown for data used by the unit tests
}

@Test(expected = InvalidPatternException.class)
public void testExceptionIsThrown() {
SchedulingPattern sp = new SchedulingPattern("0 5 * *");
}

@Test
public void testPattern() {
String pattern;
pattern="0 5 * * *|8 10 * * *|22 17 * * *";
assertTrue(pattern + "is correct", SchedulingPattern.validate(pattern));
pattern="0 5 * *";
assertTrue(pattern + "is correct", SchedulingPattern.validate(pattern));
}
}
</pre>

# Committez et Pushez ce nouveau fichier, pour que Travis lance les tests dès que possible
# Lancez les tests unitaires avec <pre>mvn test</pre> Ce test va '''échouer''': corrigez le.
# Committez et Pushez la version corrigée des tests: Travis enverra un mail pour indiquer si les tests échouent ou non
#: '''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.
# Naviguez sur http://travis-ci.org pour vérifier les builds effectués.
# Créez des tests unitaires supplémentaire du i.s.c.CronParser

===[[Maven]] avec [[Travis-CI]]===

===Git (suite)===

# Forkez le projet '''tagl''' d'un autre binome (i.e. autre que ''donsez/tagl'')
#: '''Attention:''' donnez lui un nom différent (e.g. ''tagl-licensing'')
# Clonez ce nouveau dépôt
# Lancez une compilation pour valider l'état du projet (bonne pratique)
#:<pre>mvn clean verify</pre>
# Situez vous dans une nouvelle branch git:
#:<pre>git checkout -b add-license</pre>
# Ajoutez une bannière de licence dans le fichier '''cron4j-mvn/pom.xml'''
# Lancez une nouvelle compilation pour valider vos modifications
# Commitez et pushez (vers votre fork de ce dépôt, i.e. ''tagl-licensing'') (pour pusher une branche nouvellement créée: git push -u origin add-license)
# Via le site de GitHub, proposez un "Pull Request" au projet initial

Vous pouvez ensuite supprimer le clone de ce fork.
Lorsque le ''pull request'' aura été accepté, vous pourrez supprimer votre fork (''tagl-licensing'') de votre compte GitHub.

===Contrôle Continu===

Dans votre dépôt ''tagl''.

# Ajoutez le plugin [http://mojo.codehaus.org/cobertura-maven-plugin/usage.html Cobertura] à votre projet Maven.
## 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''
## Le plugin ne s'exécute automatiquement pas durant la compilation, il faut utiliser la commande : <pre>mvn cobertura:cobertura</pre>
## '''Bonus:''' Modifiez le fichier ''pom.xml'' pour que le ''goal'' '''cobertura''' soit exécuté pendant la ''phase'' '''package'''.
# Répondez aux questions : ''Mais qu'est ce que la couverture de code ? En quoi c'est utile ?''
# 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.
# Regardez les exemples d'utilisation de cron4j dans cron4j-original/examples

===Bonus Track===

====Clone SVN -> Git====

Source: http://www.yterium.net/Migrer-un-projet-SVN-vers-GIT

<syntaxhighlight lang="bash">
# Cloner le dépôt SVN en dépôt Git (conservation historique)
$ git svn clone svn://svn.code.sf.net/p/cron4j/code/trunk cron4j-original
$ cd cron4j-original
# Test compilation
$ ant jar
$ cd ..
</syntaxhighlight>

====Préparation TAGL====

<syntaxhighlight lang="bash">
# Clone du dépôt TAGL
$ git clone git@github.com:donsez/tagl.git
$ cd tagl
# "Fetch" du dépôt local cloné précédemment
$ git fetch file://$(pwd)/../cron4j-original
# Fusion de ce qui vient d'être fetché
$ git merge FETCH_HEAD
# Envoi sur le serveur
$ git push
</syntaxhighlight>

====Cherry-picking: reprise des modifications d'un collègue====

On considère que:

* votre dépôt Git distant est à l'adresse URL_DEPOT
* votre collègue a un dépôt Git à l'adresse URL_COLLEGUE

<syntaxhighlight lang="bash">
# Dossier temporaire
cd /tmp

# Clone de votre dépôt
git clone URL_DEPOT mon_depot

# Déplacement dans votre dépôt
cd mon_depot

# Définition du dépôt distant
git remote add collegue URL_COLLEGUE

# Récupération des infos du dépôt du collègue
git fetch collegue

# Maintenant, on peut voir les branches du collègue
git branch -a

# On peut fusionner avec une branche
git merge collegue/master

# Si vous avez des conflits, éditez les fichiers concernés,
# et committez avec git commit

# Push vers votre dépôt distant
git push origin

# Optionnel: supprimez la référence vers le dépôt du collègue
git remote rm collegue
</syntaxhighlight>

====Archetype webapp====
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].

<syntaxhighlight lang="bash">
mvn -Djetty.port=9999 jetty:run
</syntaxhighlight>

Naviguez sur http://localhost:9999/monsite

====Scrum tools====
Ces 3 services peuvent être couplé à votre dépôt GitHub pour votre gestion de projet agile avec [[Scrum]] :
* http://www.acunote.com/
* http://backlogtool.com/
* http://www.scrumdo.com/

L'activation se fait via ''Settings > Webhooks & Services > Configure services''.

=Séance 4: AOP & AspectJ=

Dans votre dépôt Git, projet ''cron4j-mvn''.

# Ajoutez le [http://mojo.codehaus.org/aspectj-maven-plugin/ plugin Maven pour AspectJ] au pom.xml
# Ajoutez un aspect de trace à l'invocation des méthodes '''run()''' de l'interface java.lang.Runnable (uniquement pour les objets ''schedulé''s)
#: Affichez une trace avant et après l'exécution de la tâche
# 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 "* * * * *")
#: Lors de l'exécution de '''mvn test''', vous devez voir apparaître les traces préparées dans votre aspect.

Liens utiles:
* [http://ridgetopsolutions.com/blog/2013/02/12/getting-started-with-aspectj-and-maven/ Getting started with AspectJ and Maven]

===Contrôle continu===

# 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.

=Séance 5: Pelix & iPOPO=

Pelix est une plate-forme d'application à services (SOA).
iPOPO est un modèle de composants orientés services (SOCM).

La documentation de Pelix et iPOPO est disponible sur https://ipopo.coderxpress.net/

===Installation de iPOPO===

* Cloner le dépôt Git depuis https://github.com/tcalmant/ipopo
* Se placer dans la branche ''dev''
* Pour installer iPOPO, lancer la commande :

sudo python setup.py install

===Shell Pelix===

Pour lancer un shell Pelix, utilisez la commande:

python -m pelix.shell.console

Les commandes disponibles sont décrites ici: [https://ipopo.coderxpress.net/wiki/doku.php?id=ipopo:refcards:shell Shell Commands]

===Rappels de Python===

* Pas de déclaration du type d'une variable
* Les méthodes d'une classe ont toute comme premier paramètre ''self'', équivalent du ''this'' en Java.
* Blocs définis par indentation (4 espaces ou 1 tab)
* Une ligne finissant par ':' démarre toujours un bloc

<syntaxhighlight lang="python">
# Import d'un module
import pelix

# Définition d'une classe
class MaClasse:
# Constructeur
def __init__(self):
self.default = "stanger"
print("Classe construite")

# Méthode, avec un argument
def sayHello(self, name):
if not name:
# Nom vide ou nul
return "Hello, " + str(self.default)
else:
# Nom valide
return "Hello, " + str(name)

objet = MaClasse()
print(objet.sayHello(""))
print(objet.sayHello("World"))
</syntaxhighlight>

===Service Ping-Pong===

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:".

Exemple:

pong = Pong()
pong.pong("Hello") # <-- Retourne "PONG:Hello"

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:"

Exemple:

ping = Ping()
ping.ping("Hello") # <-- Retourne "PING:PONG:Hello"

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"
* Définir une classe ''Activator'', décorée avec ''@BundleActivator''
* Enregistrer le service dans la méthode ''Activator.start'' et le désenregistrer dans ''Activator.stop''
* S'inspirer du fichier "ipopo/samples/remote/provider.py"

Dans un shell Pelix, installer et démarrer le bundle 'pong' et vérifier que le service est bien inscrit avec la commande ''sl''

4.Transformer la classe ''Ping'' dans ''ping.py'' en un composant iPOPO
* L'objet Pong utilisé dans ''ping()'' doit être un service injecté par iPOPO (''@Requires'')
* Appeler la méthode ''ping()'' dès que le service Pong est injecté (''@BindField'') ou disparait (''@UnbindField'')
* S'inspirer du fichier "ipopo/samples/remote/consumer.py"

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é.

5. Mettre à jour le bundle ''pong''
* Remplacer le préfixe "PONG" par "NI"
* Dans le shell Pelix, mettre à jour le bundle ''pong'' sans redémarrer la plate-forme (commande ''udpate'').
* Vérifier les traces dans le shell pour valider la mise à jour du service.

===Remote Services===

* Ajouter les propriétés permettant l'export du service Pong dans ''pong.py'' (s'inspirer de ''provider.py'')

* Lancer deux shells iPOPO (dans deux terminaux)
* Dans chaque shell iPOPO, installer les bundles:
** ''pelix.remote.dispatcher'': Exportateur de services
** ''pelix.remote.registry''; Importateur de services
** ''pelix.remote.discovery.multicast'': Découverte de services via Multicast
** ''pelix.remote.xml_rpc'': Transport XML-RPC
** ''pelix.http.basic'': Serveur HTTP

Attention: il peut être nécessaire de désactiver votre pare-feu pour que les Remote Services fonctionnent

* Instancier les composants depuis le shell iPOPO, dans chaque framework:
** 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)
** Multicast Discovery: ''instantiate pelix-remote-discovery-multicast-factory multicast-discovery''
** XML-RPC Exporter: ''instantiate pelix-xmlrpc-exporter-factory xml-rpc-exporter''
** XML-RPC Importer: ''instantiate pelix-xmlrpc-exporter-factory xml-rpc-importer''

* Installer le bundle ''ping'' dans un des frameworks et le bundle ''pong'' dans l'autre.
* Le composant ping peut appeler le service pong, qui est dans l'autre framework.

* Voir le code de ''run_remote.py'' pour voir comment démarrer un framework Pelix et installer des bundles depuis Python.
* Jouer un peu avec ''run_remote.py'' (voir ''run_remote.py --help'')

=Séance 6=
[[Tutorial OSGi avec Apache Felix]]

=Séance 7=
Faire un projet PDE pour un bundle cron4j.gogo (indépendant de cron4j.bundle)

Utilisation de https://eclipse.org/tycho/

TAGL/TP

2015-02-26T16:38:30Z

MatthieuCaneill: /* Tests Unitaires avec JUnit 4 */

Travaux pratiques de l'UE [[TAGL]].

Anciennes versions : [[TAGL/TP 2014]]

=Séance 1 : Gestion de versions=
==Git==

Création d'un dépôt Git local

===Méthode simple: init first===

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".
Cette méthode est la plus simple, car on dispose immédiatement d'un répertoire de travail.

<syntaxhighlight lang="bash">
# Création d'un dépôt Git dans le dossier simple-repo
git init simple-repo

# Création d'un README
cd simple-repo
echo "Hello, World" > README

# Ajout du versionnement du fichier README
git add README

# Commit
git commit
</syntaxhighlight>

À ce niveau, on a un dépôt Git complètement fonctionnel.
Cependant, il est intéressant de pousser ses modifications vers un autre dépôt, sur une autre machine.
On va donc créer un dépôt bare sur une autre machine (ou autre dossier pour l'exemple)

<syntaxhighlight lang="bash">
git init --bare server-repo
</syntaxhighlight>

On considère que l'URL pour accéder à ce dépôt est URL_REPO.
On va d'abord ajouter ce dépôt serveur à la liste des dépôts connu-repos de votre dépôt local.
Étant donné qu'il s'agit du dépôt "principal" à utiliser, on l'appellera //origin//, par convention.

<syntaxhighlight lang="bash">
git remote add origin URL_REPO
# Récupération de ses informations
git fetch origin
</syntaxhighlight>

Ce serveur distant est "vide": il n'a aucune branche. On va donc enregistrer notre branche sur le serveur

<syntaxhighlight lang="bash">
git push origin master
</syntaxhighlight>

À partir de cette commande, la branche locale //master// sera liée à la branche distante //origin/master//.
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.

===Méthode moins simple: bare first===

Si on commence dans par le serveur "vide", il faudra le cloner au lieu de le définir comme un dépôt distant.

<syntaxhighlight lang="bash">
# Création du dépôt vide
git init --bare server-repo
</syntaxhighlight>

On considère que ce dépôt est accessible à l'URL URL_REPO

<syntaxhighlight lang="bash">
# Clonage du dépôt
git clone URL_REPO clone-repo
</syntaxhighlight>

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.
Le dépôt distant est automatiquement appelé //origin//.

<syntaxhighlight lang="bash">
# Commit dans le dépôt local
cd clone-repo
echo hello > readme.rst
git add readme.rst
git commit et ses dépendances
</syntaxhighlight>

Comme dans la méthode simple, il faut pousser la branche master vers le dépôt distant:

<syntaxhighlight lang="bash">
git push origin master
</syntaxhighlight>

===De l'importance des README===

Il est très important d'avoir au moins 2 fichiers dans votre dépôt Git:

* LICENSE: contenant le texte **complet** de la licence de votre projet
* README: décrivant votre projet et comment l'utiliser. Ce fichier doit rappeler le nom de la licence de votre projet

Il est aussi recommandé d'avoir les fichiers suivants:

* AUTHORS: contenant la liste des noms/pseudos et e-mails des auteurs de commits ou de code inclus dans ce projet
* INSTALL: contenant la liste des dépendances de ce projet et des commandes à utiliser pour le compiler et l'installer

Les fichiers LICENSE sont des fichiers textes bruts.
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)

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]

=Séance 2a: Intégration en continue=

===GitHub & [[Travis-CI]]===

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.
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.

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.

Pour utiliser [[Travis-CI]]:

# Créez compte individuel sur GitHub https://github.com
# ''Fork''ez le dépôt https://github.com/heroku/node-js-getting-started
# Ajoutez un collaborateur (i.e. votre binôme) au projet ''forké'', via les paramètres (''settings'') de ce projet
# 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.
# Activez le service Travis-CI: identifiez-vous (''sign in'') sur https://travis-ci.org/ avec votre compte GitHub
# Activez le service pour les projets sur lesquels vous souhaitez appliquer les principes d'intégration continue

[[Travis-CI]] utilise un fichier nommé '''.travis.yml''' (attention: fichier caché sous Unix) pour se configurer et choisir les opérations à effectuer.
Ce fichier doit se trouver à la racine de votre dépôt Git.

Faites un '''Commit''' puis un '''Push''' du fichier '''.travis.yml''' ci-dessous.

<pre>
language: node_js
node_js:
- "0.11"
- "0.10"
- "0.8"
- "0.6"
- iojs
- iojs-v1.0.2

</pre>

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]].

Ajoutez dans le fichier '''package.json''' la section suivante:
<pre>
"devDependencies": {
"jshint": "^2.6.0"
},
"scripts": {
"test": "./node_modules/jshint/bin/jshint index.js"
}
</pre>
et incrémentez le numéro de version.

Faites un '''Commit''' puis un '''Push''' des fichiers touchés.

'''Remarque:'''
'''jshint''' peut être lancé localement avec les commandes suivantes:
<pre>
sudo npm install jshint
jshint index.js
</pre>

A lire
* http://docs.travis-ci.com/user/languages/javascript-with-nodejs/
* https://github.com/docdis/learn-travis/blob/master/README.md

=Séance 2b: Livraison en continue=

==[[Heroku]]==
[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.

# Créez un compte gratuit sur [https://signup.heroku.com Heroku]
# Forkez le dépôt https://github.com/heroku/node-js-getting-started
# Dans Heroku, créez une nouvelle app Node.js, et liez-la au repository Github créé à l'étape précédente
# Choisissez l'option "Déploiement automatique" depuis la branche **master**
# Modifiez le fichier index.js pour afficher la version de service dans la page HTML
<pre>
var fs = require('fs');
var package = JSON.parse(fs.readFileSync('./package.json', 'utf8'));
var version=package.version;
...
response.send('Hello World! (current version: '+version+')');
...
</pre>

Incrémentez le numéro de version dans le fichier ''package.json''

Faites un '''Commit''' puis un '''Push''' des fichiers touchés.

Naviguez l'application sur Heroku

# Modifiez le fichier index.js pour franciser le message dans la page HTML
<pre>
...
response.send('Bonjour Tout Le Monde! (version courante: '+version+')');
...
</pre>

Incrémentez le numéro de version dans le fichier '''package.json''

Faites un '''Commit''' puis un '''Push''' des fichiers touchés.

Naviguez l'application sur Heroku

=Séance 3: Builders=

==[[Ant]]==

==[[Maven]]==

[http://maven.apache.org/download.cgi Charger et installer Maven 3].

Debian/Ubuntu & friends:
<pre>
sudo apt-get update && sudo apt-get install maven
</pre>

<pre>
mvn -version
</pre>

Faites une copie du projet, basée sur Maven:

# Dans votre dépôt Git, créez un dossier '''cron4j-mvn''': il contiendra le projet Cron4J avec la structure Maven
# 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):
#:<pre>mvn archetype:generate -DarchetypeGroupId=org.apache.maven.archetypes -DarchetypeArtifactId=maven-archetype-quickstart</pre>
# Cette commande crée un projet avec un fichier ''pom.xml'', et une classe et un test modèles: supprimez ces modèles
# Copiez les sources de Cron4J depuis le dossier '''cron4j-original''' dans le dossier '''src/main/java''' de votre projet Maven
# Faites un essai de compilation:
#:<pre>mvn clean verify</pre>
# 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])
# 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.

==Tests Unitaires avec JUnit 4==
Survoller le tutoriel [http://www.vogella.com/tutorials/JUnit/article.html Unit Testing with JUnit]

# Veillez à bien utiliser la dépendance JUnit 4.8.2 dans pom.xml
# Ajouter le test unitaire suivant au projet, dans le fichier '''src/test/it/sauronsoftware/SchedulingPatternTest.java
<pre>
package it.sauronsoftware;

import it.sauronsoftware.cron4j.SchedulingPattern;
import it.sauronsoftware.cron4j.InvalidPatternException;

import static org.junit.Assert.assertEquals;
import static org.junit.Assert.assertTrue;

import org.junit.AfterClass;
import org.junit.BeforeClass;
import org.junit.Test;

public class SchedulingPatternTest {

@BeforeClass
public static void testSetup() {
}

@AfterClass
public static void testCleanup() {
// Teardown for data used by the unit tests
}

@Test(expected = InvalidPatternException.class)
public void testExceptionIsThrown() {
SchedulingPattern sp = new SchedulingPattern("0 5 * *");
}

@Test
public void testPattern() {
String pattern;
pattern="0 5 * * *|8 10 * * *|22 17 * * *";
assertTrue(pattern + "is correct", SchedulingPattern.validate(pattern));
pattern="0 5 * *";
assertTrue(pattern + "is correct", SchedulingPattern.validate(pattern));
}
}
</pre>

# Committez et Pushez ce nouveau fichier, pour que Travis lance les tests dès que possible
# Lancez les tests unitaires avec <pre>mvn test</pre> Ce test va '''échouer''': corrigez le.
# Committez et Pushez la version corrigée des tests: Travis enverra un mail pour indiquer si les tests échouent ou non
#: '''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.
# Naviguez sur http://travis-ci.org pour vérifier les builds effectués.
# Créez des tests unitaires supplémentaire du i.s.c.CronParser

===[[Maven]] avec [[Travis-CI]]===

===Git (suite)===

# Forkez le projet '''tagl''' d'un autre binome (i.e. autre que ''donsez/tagl'')
#: '''Attention:''' donnez lui un nom différent (e.g. ''tagl-licensing'')
# Clonez ce nouveau dépôt
# Lancez une compilation pour valider l'état du projet (bonne pratique)
#:<pre>mvn clean verify</pre>
# Ajoutez une bannière de licence dans le fichier '''cron4j-mvn/pom.xml'''
# Lancez une nouvelle compilation pour valider vos modifications
# Commitez et pushez (vers votre fork de ce dépôt, i.e. ''tagl-licensing'')
# Via le site de GitHub, proposez un "Pull Request" au projet initial

Vous pouvez ensuite supprimer le clone de ce fork.
Lorsque le ''pull request'' aura été accepté, vous pourrez supprimer votre fork (''tagl-licensing'') de votre compte GitHub.

===Contrôle Continu===

Dans votre dépôt ''tagl''.

# Ajoutez le plugin [http://mojo.codehaus.org/cobertura-maven-plugin/usage.html Cobertura] à votre projet Maven.
## 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''
## Le plugin ne s'exécute automatiquement pas durant la compilation, il faut utiliser la commande : <pre>mvn cobertura:cobertura</pre>
## '''Bonus:''' Modifiez le fichier ''pom.xml'' pour que le ''goal'' '''cobertura''' soit exécuté pendant la ''phase'' '''package'''.
# Répondez aux questions : ''Mais qu'est ce que la couverture de code ? En quoi c'est utile ?''
# 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.
# Regardez les exemples d'utilisation de cron4j dans cron4j-original/examples

===Bonus Track===

====Clone SVN -> Git====

Source: http://www.yterium.net/Migrer-un-projet-SVN-vers-GIT

<syntaxhighlight lang="bash">
# Cloner le dépôt SVN en dépôt Git (conservation historique)
$ git svn clone svn://svn.code.sf.net/p/cron4j/code/trunk cron4j-original
$ cd cron4j-original
# Test compilation
$ ant jar
$ cd ..
</syntaxhighlight>

====Préparation TAGL====

<syntaxhighlight lang="bash">
# Clone du dépôt TAGL
$ git clone git@github.com:donsez/tagl.git
$ cd tagl
# "Fetch" du dépôt local cloné précédemment
$ git fetch file://$(pwd)/../cron4j-original
# Fusion de ce qui vient d'être fetché
$ git merge FETCH_HEAD
# Envoi sur le serveur
$ git push
</syntaxhighlight>

====Cherry-picking: reprise des modifications d'un collègue====

On considère que:

* votre dépôt Git distant est à l'adresse URL_DEPOT
* votre collègue a un dépôt Git à l'adresse URL_COLLEGUE

<syntaxhighlight lang="bash">
# Dossier temporaire
cd /tmp

# Clone de votre dépôt
git clone URL_DEPOT mon_depot

# Déplacement dans votre dépôt
cd mon_depot

# Définition du dépôt distant
git remote add collegue URL_COLLEGUE

# Récupération des infos du dépôt du collègue
git fetch collegue

# Maintenant, on peut voir les branches du collègue
git branch -a

# On peut fusionner avec une branche
git merge collegue/master

# Si vous avez des conflits, éditez les fichiers concernés,
# et committez avec git commit

# Push vers votre dépôt distant
git push origin

# Optionnel: supprimez la référence vers le dépôt du collègue
git remote rm collegue
</syntaxhighlight>

====Archetype webapp====
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].

<syntaxhighlight lang="bash">
mvn -Djetty.port=9999 jetty:run
</syntaxhighlight>

Naviguez sur http://localhost:9999/monsite

====Scrum tools====
Ces 3 services peuvent être couplé à votre dépôt GitHub pour votre gestion de projet agile avec [[Scrum]] :
* http://www.acunote.com/
* http://backlogtool.com/
* http://www.scrumdo.com/

L'activation se fait via ''Settings > Webhooks & Services > Configure services''.

=Séance 4: AOP & AspectJ=

Dans votre dépôt Git, projet ''cron4j-mvn''.

# Ajoutez le [http://mojo.codehaus.org/aspectj-maven-plugin/ plugin Maven pour AspectJ] au pom.xml
# Ajoutez un aspect de trace à l'invocation des méthodes '''run()''' de l'interface java.lang.Runnable (uniquement pour les objets ''schedulé''s)
#: Affichez une trace avant et après l'exécution de la tâche
# 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 "* * * * *")
#: Lors de l'exécution de '''mvn test''', vous devez voir apparaître les traces préparées dans votre aspect.

Liens utiles:
* [http://ridgetopsolutions.com/blog/2013/02/12/getting-started-with-aspectj-and-maven/ Getting started with AspectJ and Maven]

===Contrôle continu===

# 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.

=Séance 5: Pelix & iPOPO=

Pelix est une plate-forme d'application à services (SOA).
iPOPO est un modèle de composants orientés services (SOCM).

La documentation de Pelix et iPOPO est disponible sur https://ipopo.coderxpress.net/

===Installation de iPOPO===

* Cloner le dépôt Git depuis https://github.com/tcalmant/ipopo
* Se placer dans la branche ''dev''
* Pour installer iPOPO, lancer la commande :

sudo python setup.py install

===Shell Pelix===

Pour lancer un shell Pelix, utilisez la commande:

python -m pelix.shell.console

Les commandes disponibles sont décrites ici: [https://ipopo.coderxpress.net/wiki/doku.php?id=ipopo:refcards:shell Shell Commands]

===Rappels de Python===

* Pas de déclaration du type d'une variable
* Les méthodes d'une classe ont toute comme premier paramètre ''self'', équivalent du ''this'' en Java.
* Blocs définis par indentation (4 espaces ou 1 tab)
* Une ligne finissant par ':' démarre toujours un bloc

<syntaxhighlight lang="python">
# Import d'un module
import pelix

# Définition d'une classe
class MaClasse:
# Constructeur
def __init__(self):
self.default = "stanger"
print("Classe construite")

# Méthode, avec un argument
def sayHello(self, name):
if not name:
# Nom vide ou nul
return "Hello, " + str(self.default)
else:
# Nom valide
return "Hello, " + str(name)

objet = MaClasse()
print(objet.sayHello(""))
print(objet.sayHello("World"))
</syntaxhighlight>

===Service Ping-Pong===

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:".

Exemple:

pong = Pong()
pong.pong("Hello") # <-- Retourne "PONG:Hello"

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:"

Exemple:

ping = Ping()
ping.ping("Hello") # <-- Retourne "PING:PONG:Hello"

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"
* Définir une classe ''Activator'', décorée avec ''@BundleActivator''
* Enregistrer le service dans la méthode ''Activator.start'' et le désenregistrer dans ''Activator.stop''
* S'inspirer du fichier "ipopo/samples/remote/provider.py"

Dans un shell Pelix, installer et démarrer le bundle 'pong' et vérifier que le service est bien inscrit avec la commande ''sl''

4.Transformer la classe ''Ping'' dans ''ping.py'' en un composant iPOPO
* L'objet Pong utilisé dans ''ping()'' doit être un service injecté par iPOPO (''@Requires'')
* Appeler la méthode ''ping()'' dès que le service Pong est injecté (''@BindField'') ou disparait (''@UnbindField'')
* S'inspirer du fichier "ipopo/samples/remote/consumer.py"

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é.

5. Mettre à jour le bundle ''pong''
* Remplacer le préfixe "PONG" par "NI"
* Dans le shell Pelix, mettre à jour le bundle ''pong'' sans redémarrer la plate-forme (commande ''udpate'').
* Vérifier les traces dans le shell pour valider la mise à jour du service.

===Remote Services===

* Ajouter les propriétés permettant l'export du service Pong dans ''pong.py'' (s'inspirer de ''provider.py'')

* Lancer deux shells iPOPO (dans deux terminaux)
* Dans chaque shell iPOPO, installer les bundles:
** ''pelix.remote.dispatcher'': Exportateur de services
** ''pelix.remote.registry''; Importateur de services
** ''pelix.remote.discovery.multicast'': Découverte de services via Multicast
** ''pelix.remote.xml_rpc'': Transport XML-RPC
** ''pelix.http.basic'': Serveur HTTP

Attention: il peut être nécessaire de désactiver votre pare-feu pour que les Remote Services fonctionnent

* Instancier les composants depuis le shell iPOPO, dans chaque framework:
** 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)
** Multicast Discovery: ''instantiate pelix-remote-discovery-multicast-factory multicast-discovery''
** XML-RPC Exporter: ''instantiate pelix-xmlrpc-exporter-factory xml-rpc-exporter''
** XML-RPC Importer: ''instantiate pelix-xmlrpc-exporter-factory xml-rpc-importer''

* Installer le bundle ''ping'' dans un des frameworks et le bundle ''pong'' dans l'autre.
* Le composant ping peut appeler le service pong, qui est dans l'autre framework.

* Voir le code de ''run_remote.py'' pour voir comment démarrer un framework Pelix et installer des bundles depuis Python.
* Jouer un peu avec ''run_remote.py'' (voir ''run_remote.py --help'')

=Séance 6=
[[Tutorial OSGi avec Apache Felix]]

=Séance 7=
Faire un projet PDE pour un bundle cron4j.gogo (indépendant de cron4j.bundle)

Utilisation de https://eclipse.org/tycho/

TAGL/TP

2015-02-26T16:21:30Z

MatthieuCaneill: /* Maven */

Travaux pratiques de l'UE [[TAGL]].

Anciennes versions : [[TAGL/TP 2014]]

=Séance 1 : Gestion de versions=
==Git==

Création d'un dépôt Git local

===Méthode simple: init first===

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".
Cette méthode est la plus simple, car on dispose immédiatement d'un répertoire de travail.

<syntaxhighlight lang="bash">
# Création d'un dépôt Git dans le dossier simple-repo
git init simple-repo

# Création d'un README
cd simple-repo
echo "Hello, World" > README

# Ajout du versionnement du fichier README
git add README

# Commit
git commit
</syntaxhighlight>

À ce niveau, on a un dépôt Git complètement fonctionnel.
Cependant, il est intéressant de pousser ses modifications vers un autre dépôt, sur une autre machine.
On va donc créer un dépôt bare sur une autre machine (ou autre dossier pour l'exemple)

<syntaxhighlight lang="bash">
git init --bare server-repo
</syntaxhighlight>

On considère que l'URL pour accéder à ce dépôt est URL_REPO.
On va d'abord ajouter ce dépôt serveur à la liste des dépôts connu-repos de votre dépôt local.
Étant donné qu'il s'agit du dépôt "principal" à utiliser, on l'appellera //origin//, par convention.

<syntaxhighlight lang="bash">
git remote add origin URL_REPO
# Récupération de ses informations
git fetch origin
</syntaxhighlight>

Ce serveur distant est "vide": il n'a aucune branche. On va donc enregistrer notre branche sur le serveur

<syntaxhighlight lang="bash">
git push origin master
</syntaxhighlight>

À partir de cette commande, la branche locale //master// sera liée à la branche distante //origin/master//.
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.

===Méthode moins simple: bare first===

Si on commence dans par le serveur "vide", il faudra le cloner au lieu de le définir comme un dépôt distant.

<syntaxhighlight lang="bash">
# Création du dépôt vide
git init --bare server-repo
</syntaxhighlight>

On considère que ce dépôt est accessible à l'URL URL_REPO

<syntaxhighlight lang="bash">
# Clonage du dépôt
git clone URL_REPO clone-repo
</syntaxhighlight>

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.
Le dépôt distant est automatiquement appelé //origin//.

<syntaxhighlight lang="bash">
# Commit dans le dépôt local
cd clone-repo
echo hello > readme.rst
git add readme.rst
git commit et ses dépendances
</syntaxhighlight>

Comme dans la méthode simple, il faut pousser la branche master vers le dépôt distant:

<syntaxhighlight lang="bash">
git push origin master
</syntaxhighlight>

===De l'importance des README===

Il est très important d'avoir au moins 2 fichiers dans votre dépôt Git:

* LICENSE: contenant le texte **complet** de la licence de votre projet
* README: décrivant votre projet et comment l'utiliser. Ce fichier doit rappeler le nom de la licence de votre projet

Il est aussi recommandé d'avoir les fichiers suivants:

* AUTHORS: contenant la liste des noms/pseudos et e-mails des auteurs de commits ou de code inclus dans ce projet
* INSTALL: contenant la liste des dépendances de ce projet et des commandes à utiliser pour le compiler et l'installer

Les fichiers LICENSE sont des fichiers textes bruts.
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)

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]

=Séance 2a: Intégration en continue=

===GitHub & [[Travis-CI]]===

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.
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.

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.

Pour utiliser [[Travis-CI]]:

# Créez compte individuel sur GitHub https://github.com
# ''Fork''ez le dépôt https://github.com/heroku/node-js-getting-started
# Ajoutez un collaborateur (i.e. votre binôme) au projet ''forké'', via les paramètres (''settings'') de ce projet
# 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.
# Activez le service Travis-CI: identifiez-vous (''sign in'') sur https://travis-ci.org/ avec votre compte GitHub
# Activez le service pour les projets sur lesquels vous souhaitez appliquer les principes d'intégration continue

[[Travis-CI]] utilise un fichier nommé '''.travis.yml''' (attention: fichier caché sous Unix) pour se configurer et choisir les opérations à effectuer.
Ce fichier doit se trouver à la racine de votre dépôt Git.

Faites un '''Commit''' puis un '''Push''' du fichier '''.travis.yml''' ci-dessous.

<pre>
language: node_js
node_js:
- "0.11"
- "0.10"
- "0.8"
- "0.6"
- iojs
- iojs-v1.0.2

</pre>

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]].

Ajoutez dans le fichier '''package.json''' la section suivante:
<pre>
"devDependencies": {
"jshint": "^2.6.0"
},
"scripts": {
"test": "./node_modules/jshint/bin/jshint index.js"
}
</pre>
et incrémentez le numéro de version.

Faites un '''Commit''' puis un '''Push''' des fichiers touchés.

'''Remarque:'''
'''jshint''' peut être lancé localement avec les commandes suivantes:
<pre>
sudo npm install jshint
jshint index.js
</pre>

A lire
* http://docs.travis-ci.com/user/languages/javascript-with-nodejs/
* https://github.com/docdis/learn-travis/blob/master/README.md

=Séance 2b: Livraison en continue=

==[[Heroku]]==
[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.

# Créez un compte gratuit sur [https://signup.heroku.com Heroku]
# Forkez le dépôt https://github.com/heroku/node-js-getting-started
# Dans Heroku, créez une nouvelle app Node.js, et liez-la au repository Github créé à l'étape précédente
# Choisissez l'option "Déploiement automatique" depuis la branche **master**
# Modifiez le fichier index.js pour afficher la version de service dans la page HTML
<pre>
var fs = require('fs');
var package = JSON.parse(fs.readFileSync('./package.json', 'utf8'));
var version=package.version;
...
response.send('Hello World! (current version: '+version+')');
...
</pre>

Incrémentez le numéro de version dans le fichier ''package.json''

Faites un '''Commit''' puis un '''Push''' des fichiers touchés.

Naviguez l'application sur Heroku

# Modifiez le fichier index.js pour franciser le message dans la page HTML
<pre>
...
response.send('Bonjour Tout Le Monde! (version courante: '+version+')');
...
</pre>

Incrémentez le numéro de version dans le fichier '''package.json''

Faites un '''Commit''' puis un '''Push''' des fichiers touchés.

Naviguez l'application sur Heroku

=Séance 3: Builders=

==[[Ant]]==

==[[Maven]]==

[http://maven.apache.org/download.cgi Charger et installer Maven 3].

Debian/Ubuntu & friends:
<pre>
sudo apt-get update && sudo apt-get install maven
</pre>

<pre>
mvn -version
</pre>

Faites une copie du projet, basée sur Maven:

# Dans votre dépôt Git, créez un dossier '''cron4j-mvn''': il contiendra le projet Cron4J avec la structure Maven
# 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):
#:<pre>mvn archetype:generate -DarchetypeGroupId=org.apache.maven.archetypes -DarchetypeArtifactId=maven-archetype-quickstart</pre>
# Cette commande crée un projet avec un fichier ''pom.xml'', et une classe et un test modèles: supprimez ces modèles
# Copiez les sources de Cron4J depuis le dossier '''cron4j-original''' dans le dossier '''src/main/java''' de votre projet Maven
# Faites un essai de compilation:
#:<pre>mvn clean verify</pre>
# 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])
# 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.

==Tests Unitaires avec JUnit 4==
Survoller le tutoriel [http://www.vogella.com/tutorials/JUnit/article.html Unit Testing with JUnit]

# Ajouter le test unitaire suivant au projet, dans le fichier '''src/test/it/sauronsoftware/SchedulingPatternTest.java
<pre>
package it.sauronsoftware;

import it.sauronsoftware.cron4j.SchedulingPattern;
import it.sauronsoftware.cron4j.InvalidPatternException;

import static org.junit.Assert.assertEquals;
import static org.junit.Assert.assertTrue;

import org.junit.AfterClass;
import org.junit.BeforeClass;
import org.junit.Test;

public class SchedulingPatternTest {

@BeforeClass
public static void testSetup() {
}

@AfterClass
public static void testCleanup() {
// Teardown for data used by the unit tests
}

@Test(expected = InvalidPatternException.class)
public void testExceptionIsThrown() {
SchedulingPattern sp = new SchedulingPattern("0 5 * *");
}

@Test
public void testPattern() {
String pattern;
pattern="0 5 * * *|8 10 * * *|22 17 * * *";
assertTrue(pattern + "is correct", SchedulingPattern.validate(pattern));
pattern="0 5 * *";
assertTrue(pattern + "is correct", SchedulingPattern.validate(pattern));
}
}
</pre>

# Committez et Pushez ce nouveau fichier, pour que Travis lance les tests dès que possible
# Lancez les tests unitaires avec <pre>mvn test</pre> Ce test va '''échouer''': corrigez le.
# Committez et Pushez la version corrigée des tests: Travis enverra un mail pour indiquer si les tests échouent ou non
#: '''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.
# Naviguez sur http://travis-ci.org pour vérifier les builds effectués.
# Créez des tests unitaires supplémentaire du i.s.c.CronParser

===[[Maven]] avec [[Travis-CI]]===

===Git (suite)===

# Forkez le projet '''tagl''' d'un autre binome (i.e. autre que ''donsez/tagl'')
#: '''Attention:''' donnez lui un nom différent (e.g. ''tagl-licensing'')
# Clonez ce nouveau dépôt
# Lancez une compilation pour valider l'état du projet (bonne pratique)
#:<pre>mvn clean verify</pre>
# Ajoutez une bannière de licence dans le fichier '''cron4j-mvn/pom.xml'''
# Lancez une nouvelle compilation pour valider vos modifications
# Commitez et pushez (vers votre fork de ce dépôt, i.e. ''tagl-licensing'')
# Via le site de GitHub, proposez un "Pull Request" au projet initial

Vous pouvez ensuite supprimer le clone de ce fork.
Lorsque le ''pull request'' aura été accepté, vous pourrez supprimer votre fork (''tagl-licensing'') de votre compte GitHub.

===Contrôle Continu===

Dans votre dépôt ''tagl''.

# Ajoutez le plugin [http://mojo.codehaus.org/cobertura-maven-plugin/usage.html Cobertura] à votre projet Maven.
## 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''
## Le plugin ne s'exécute automatiquement pas durant la compilation, il faut utiliser la commande : <pre>mvn cobertura:cobertura</pre>
## '''Bonus:''' Modifiez le fichier ''pom.xml'' pour que le ''goal'' '''cobertura''' soit exécuté pendant la ''phase'' '''package'''.
# Répondez aux questions : ''Mais qu'est ce que la couverture de code ? En quoi c'est utile ?''
# 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.
# Regardez les exemples d'utilisation de cron4j dans cron4j-original/examples

===Bonus Track===

====Clone SVN -> Git====

Source: http://www.yterium.net/Migrer-un-projet-SVN-vers-GIT

<syntaxhighlight lang="bash">
# Cloner le dépôt SVN en dépôt Git (conservation historique)
$ git svn clone svn://svn.code.sf.net/p/cron4j/code/trunk cron4j-original
$ cd cron4j-original
# Test compilation
$ ant jar
$ cd ..
</syntaxhighlight>

====Préparation TAGL====

<syntaxhighlight lang="bash">
# Clone du dépôt TAGL
$ git clone git@github.com:donsez/tagl.git
$ cd tagl
# "Fetch" du dépôt local cloné précédemment
$ git fetch file://$(pwd)/../cron4j-original
# Fusion de ce qui vient d'être fetché
$ git merge FETCH_HEAD
# Envoi sur le serveur
$ git push
</syntaxhighlight>

====Cherry-picking: reprise des modifications d'un collègue====

On considère que:

* votre dépôt Git distant est à l'adresse URL_DEPOT
* votre collègue a un dépôt Git à l'adresse URL_COLLEGUE

<syntaxhighlight lang="bash">
# Dossier temporaire
cd /tmp

# Clone de votre dépôt
git clone URL_DEPOT mon_depot

# Déplacement dans votre dépôt
cd mon_depot

# Définition du dépôt distant
git remote add collegue URL_COLLEGUE

# Récupération des infos du dépôt du collègue
git fetch collegue

# Maintenant, on peut voir les branches du collègue
git branch -a

# On peut fusionner avec une branche
git merge collegue/master

# Si vous avez des conflits, éditez les fichiers concernés,
# et committez avec git commit

# Push vers votre dépôt distant
git push origin

# Optionnel: supprimez la référence vers le dépôt du collègue
git remote rm collegue
</syntaxhighlight>

====Archetype webapp====
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].

<syntaxhighlight lang="bash">
mvn -Djetty.port=9999 jetty:run
</syntaxhighlight>

Naviguez sur http://localhost:9999/monsite

====Scrum tools====
Ces 3 services peuvent être couplé à votre dépôt GitHub pour votre gestion de projet agile avec [[Scrum]] :
* http://www.acunote.com/
* http://backlogtool.com/
* http://www.scrumdo.com/

L'activation se fait via ''Settings > Webhooks & Services > Configure services''.

=Séance 4: AOP & AspectJ=

Dans votre dépôt Git, projet ''cron4j-mvn''.

# Ajoutez le [http://mojo.codehaus.org/aspectj-maven-plugin/ plugin Maven pour AspectJ] au pom.xml
# Ajoutez un aspect de trace à l'invocation des méthodes '''run()''' de l'interface java.lang.Runnable (uniquement pour les objets ''schedulé''s)
#: Affichez une trace avant et après l'exécution de la tâche
# 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 "* * * * *")
#: Lors de l'exécution de '''mvn test''', vous devez voir apparaître les traces préparées dans votre aspect.

Liens utiles:
* [http://ridgetopsolutions.com/blog/2013/02/12/getting-started-with-aspectj-and-maven/ Getting started with AspectJ and Maven]

===Contrôle continu===

# 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.

=Séance 5: Pelix & iPOPO=

Pelix est une plate-forme d'application à services (SOA).
iPOPO est un modèle de composants orientés services (SOCM).

La documentation de Pelix et iPOPO est disponible sur https://ipopo.coderxpress.net/

===Installation de iPOPO===

* Cloner le dépôt Git depuis https://github.com/tcalmant/ipopo
* Se placer dans la branche ''dev''
* Pour installer iPOPO, lancer la commande :

sudo python setup.py install

===Shell Pelix===

Pour lancer un shell Pelix, utilisez la commande:

python -m pelix.shell.console

Les commandes disponibles sont décrites ici: [https://ipopo.coderxpress.net/wiki/doku.php?id=ipopo:refcards:shell Shell Commands]

===Rappels de Python===

* Pas de déclaration du type d'une variable
* Les méthodes d'une classe ont toute comme premier paramètre ''self'', équivalent du ''this'' en Java.
* Blocs définis par indentation (4 espaces ou 1 tab)
* Une ligne finissant par ':' démarre toujours un bloc

<syntaxhighlight lang="python">
# Import d'un module
import pelix

# Définition d'une classe
class MaClasse:
# Constructeur
def __init__(self):
self.default = "stanger"
print("Classe construite")

# Méthode, avec un argument
def sayHello(self, name):
if not name:
# Nom vide ou nul
return "Hello, " + str(self.default)
else:
# Nom valide
return "Hello, " + str(name)

objet = MaClasse()
print(objet.sayHello(""))
print(objet.sayHello("World"))
</syntaxhighlight>

===Service Ping-Pong===

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:".

Exemple:

pong = Pong()
pong.pong("Hello") # <-- Retourne "PONG:Hello"

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:"

Exemple:

ping = Ping()
ping.ping("Hello") # <-- Retourne "PING:PONG:Hello"

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"
* Définir une classe ''Activator'', décorée avec ''@BundleActivator''
* Enregistrer le service dans la méthode ''Activator.start'' et le désenregistrer dans ''Activator.stop''
* S'inspirer du fichier "ipopo/samples/remote/provider.py"

Dans un shell Pelix, installer et démarrer le bundle 'pong' et vérifier que le service est bien inscrit avec la commande ''sl''

4.Transformer la classe ''Ping'' dans ''ping.py'' en un composant iPOPO
* L'objet Pong utilisé dans ''ping()'' doit être un service injecté par iPOPO (''@Requires'')
* Appeler la méthode ''ping()'' dès que le service Pong est injecté (''@BindField'') ou disparait (''@UnbindField'')
* S'inspirer du fichier "ipopo/samples/remote/consumer.py"

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é.

5. Mettre à jour le bundle ''pong''
* Remplacer le préfixe "PONG" par "NI"
* Dans le shell Pelix, mettre à jour le bundle ''pong'' sans redémarrer la plate-forme (commande ''udpate'').
* Vérifier les traces dans le shell pour valider la mise à jour du service.

===Remote Services===

* Ajouter les propriétés permettant l'export du service Pong dans ''pong.py'' (s'inspirer de ''provider.py'')

* Lancer deux shells iPOPO (dans deux terminaux)
* Dans chaque shell iPOPO, installer les bundles:
** ''pelix.remote.dispatcher'': Exportateur de services
** ''pelix.remote.registry''; Importateur de services
** ''pelix.remote.discovery.multicast'': Découverte de services via Multicast
** ''pelix.remote.xml_rpc'': Transport XML-RPC
** ''pelix.http.basic'': Serveur HTTP

Attention: il peut être nécessaire de désactiver votre pare-feu pour que les Remote Services fonctionnent

* Instancier les composants depuis le shell iPOPO, dans chaque framework:
** 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)
** Multicast Discovery: ''instantiate pelix-remote-discovery-multicast-factory multicast-discovery''
** XML-RPC Exporter: ''instantiate pelix-xmlrpc-exporter-factory xml-rpc-exporter''
** XML-RPC Importer: ''instantiate pelix-xmlrpc-exporter-factory xml-rpc-importer''

* Installer le bundle ''ping'' dans un des frameworks et le bundle ''pong'' dans l'autre.
* Le composant ping peut appeler le service pong, qui est dans l'autre framework.

* Voir le code de ''run_remote.py'' pour voir comment démarrer un framework Pelix et installer des bundles depuis Python.
* Jouer un peu avec ''run_remote.py'' (voir ''run_remote.py --help'')

=Séance 6=
[[Tutorial OSGi avec Apache Felix]]

=Séance 7=
Faire un projet PDE pour un bundle cron4j.gogo (indépendant de cron4j.bundle)

Utilisation de https://eclipse.org/tycho/

TAGL/TP

2015-02-26T16:20:23Z

MatthieuCaneill: /* Maven */

Travaux pratiques de l'UE [[TAGL]].

Anciennes versions : [[TAGL/TP 2014]]

=Séance 1 : Gestion de versions=
==Git==

Création d'un dépôt Git local

===Méthode simple: init first===

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".
Cette méthode est la plus simple, car on dispose immédiatement d'un répertoire de travail.

<syntaxhighlight lang="bash">
# Création d'un dépôt Git dans le dossier simple-repo
git init simple-repo

# Création d'un README
cd simple-repo
echo "Hello, World" > README

# Ajout du versionnement du fichier README
git add README

# Commit
git commit
</syntaxhighlight>

À ce niveau, on a un dépôt Git complètement fonctionnel.
Cependant, il est intéressant de pousser ses modifications vers un autre dépôt, sur une autre machine.
On va donc créer un dépôt bare sur une autre machine (ou autre dossier pour l'exemple)

<syntaxhighlight lang="bash">
git init --bare server-repo
</syntaxhighlight>

On considère que l'URL pour accéder à ce dépôt est URL_REPO.
On va d'abord ajouter ce dépôt serveur à la liste des dépôts connu-repos de votre dépôt local.
Étant donné qu'il s'agit du dépôt "principal" à utiliser, on l'appellera //origin//, par convention.

<syntaxhighlight lang="bash">
git remote add origin URL_REPO
# Récupération de ses informations
git fetch origin
</syntaxhighlight>

Ce serveur distant est "vide": il n'a aucune branche. On va donc enregistrer notre branche sur le serveur

<syntaxhighlight lang="bash">
git push origin master
</syntaxhighlight>

À partir de cette commande, la branche locale //master// sera liée à la branche distante //origin/master//.
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.

===Méthode moins simple: bare first===

Si on commence dans par le serveur "vide", il faudra le cloner au lieu de le définir comme un dépôt distant.

<syntaxhighlight lang="bash">
# Création du dépôt vide
git init --bare server-repo
</syntaxhighlight>

On considère que ce dépôt est accessible à l'URL URL_REPO

<syntaxhighlight lang="bash">
# Clonage du dépôt
git clone URL_REPO clone-repo
</syntaxhighlight>

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.
Le dépôt distant est automatiquement appelé //origin//.

<syntaxhighlight lang="bash">
# Commit dans le dépôt local
cd clone-repo
echo hello > readme.rst
git add readme.rst
git commit et ses dépendances
</syntaxhighlight>

Comme dans la méthode simple, il faut pousser la branche master vers le dépôt distant:

<syntaxhighlight lang="bash">
git push origin master
</syntaxhighlight>

===De l'importance des README===

Il est très important d'avoir au moins 2 fichiers dans votre dépôt Git:

* LICENSE: contenant le texte **complet** de la licence de votre projet
* README: décrivant votre projet et comment l'utiliser. Ce fichier doit rappeler le nom de la licence de votre projet

Il est aussi recommandé d'avoir les fichiers suivants:

* AUTHORS: contenant la liste des noms/pseudos et e-mails des auteurs de commits ou de code inclus dans ce projet
* INSTALL: contenant la liste des dépendances de ce projet et des commandes à utiliser pour le compiler et l'installer

Les fichiers LICENSE sont des fichiers textes bruts.
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)

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]

=Séance 2a: Intégration en continue=

===GitHub & [[Travis-CI]]===

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.
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.

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.

Pour utiliser [[Travis-CI]]:

# Créez compte individuel sur GitHub https://github.com
# ''Fork''ez le dépôt https://github.com/heroku/node-js-getting-started
# Ajoutez un collaborateur (i.e. votre binôme) au projet ''forké'', via les paramètres (''settings'') de ce projet
# 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.
# Activez le service Travis-CI: identifiez-vous (''sign in'') sur https://travis-ci.org/ avec votre compte GitHub
# Activez le service pour les projets sur lesquels vous souhaitez appliquer les principes d'intégration continue

[[Travis-CI]] utilise un fichier nommé '''.travis.yml''' (attention: fichier caché sous Unix) pour se configurer et choisir les opérations à effectuer.
Ce fichier doit se trouver à la racine de votre dépôt Git.

Faites un '''Commit''' puis un '''Push''' du fichier '''.travis.yml''' ci-dessous.

<pre>
language: node_js
node_js:
- "0.11"
- "0.10"
- "0.8"
- "0.6"
- iojs
- iojs-v1.0.2

</pre>

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]].

Ajoutez dans le fichier '''package.json''' la section suivante:
<pre>
"devDependencies": {
"jshint": "^2.6.0"
},
"scripts": {
"test": "./node_modules/jshint/bin/jshint index.js"
}
</pre>
et incrémentez le numéro de version.

Faites un '''Commit''' puis un '''Push''' des fichiers touchés.

'''Remarque:'''
'''jshint''' peut être lancé localement avec les commandes suivantes:
<pre>
sudo npm install jshint
jshint index.js
</pre>

A lire
* http://docs.travis-ci.com/user/languages/javascript-with-nodejs/
* https://github.com/docdis/learn-travis/blob/master/README.md

=Séance 2b: Livraison en continue=

==[[Heroku]]==
[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.

# Créez un compte gratuit sur [https://signup.heroku.com Heroku]
# Forkez le dépôt https://github.com/heroku/node-js-getting-started
# Dans Heroku, créez une nouvelle app Node.js, et liez-la au repository Github créé à l'étape précédente
# Choisissez l'option "Déploiement automatique" depuis la branche **master**
# Modifiez le fichier index.js pour afficher la version de service dans la page HTML
<pre>
var fs = require('fs');
var package = JSON.parse(fs.readFileSync('./package.json', 'utf8'));
var version=package.version;
...
response.send('Hello World! (current version: '+version+')');
...
</pre>

Incrémentez le numéro de version dans le fichier ''package.json''

Faites un '''Commit''' puis un '''Push''' des fichiers touchés.

Naviguez l'application sur Heroku

# Modifiez le fichier index.js pour franciser le message dans la page HTML
<pre>
...
response.send('Bonjour Tout Le Monde! (version courante: '+version+')');
...
</pre>

Incrémentez le numéro de version dans le fichier '''package.json''

Faites un '''Commit''' puis un '''Push''' des fichiers touchés.

Naviguez l'application sur Heroku

=Séance 3: Builders=

==[[Ant]]==

==[[Maven]]==

[http://maven.apache.org/download.cgi Charger et installer Maven 3].

Debian/Ubuntu & friends:
<pre>
sudo apt-get update && sudo apt-get install maven
</pre>

<pre>
mvn -version
</pre>

Faites une copie du projet, basée sur Maven:

# Dans votre dépôt Git, créez un dossier '''cron4j-mvn''': il contiendra le projet Cron4J avec la structure Maven
# 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):
#:<pre>mvn archetype:generate -DarchetypeGroupId=org.apache.maven.archetypes -DarchetypeArtifactId=maven-archetype-quickstart</pre>
groupId: it.sauronsoftware.cron4j, artifactId: cron4j
# Cette commande crée un projet avec un fichier ''pom.xml'', et une classe et un test modèles: supprimez ces modèles
# Copiez les sources de Cron4J depuis le dossier '''cron4j-original''' dans le dossier '''src/main/java''' de votre projet Maven
# Faites un essai de compilation:
#:<pre>mvn clean verify</pre>
# 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])
# 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.

==Tests Unitaires avec JUnit 4==
Survoller le tutoriel [http://www.vogella.com/tutorials/JUnit/article.html Unit Testing with JUnit]

# Ajouter le test unitaire suivant au projet, dans le fichier '''src/test/it/sauronsoftware/SchedulingPatternTest.java
<pre>
package it.sauronsoftware;

import it.sauronsoftware.cron4j.SchedulingPattern;
import it.sauronsoftware.cron4j.InvalidPatternException;

import static org.junit.Assert.assertEquals;
import static org.junit.Assert.assertTrue;

import org.junit.AfterClass;
import org.junit.BeforeClass;
import org.junit.Test;

public class SchedulingPatternTest {

@BeforeClass
public static void testSetup() {
}

@AfterClass
public static void testCleanup() {
// Teardown for data used by the unit tests
}

@Test(expected = InvalidPatternException.class)
public void testExceptionIsThrown() {
SchedulingPattern sp = new SchedulingPattern("0 5 * *");
}

@Test
public void testPattern() {
String pattern;
pattern="0 5 * * *|8 10 * * *|22 17 * * *";
assertTrue(pattern + "is correct", SchedulingPattern.validate(pattern));
pattern="0 5 * *";
assertTrue(pattern + "is correct", SchedulingPattern.validate(pattern));
}
}
</pre>

# Committez et Pushez ce nouveau fichier, pour que Travis lance les tests dès que possible
# Lancez les tests unitaires avec <pre>mvn test</pre> Ce test va '''échouer''': corrigez le.
# Committez et Pushez la version corrigée des tests: Travis enverra un mail pour indiquer si les tests échouent ou non
#: '''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.
# Naviguez sur http://travis-ci.org pour vérifier les builds effectués.
# Créez des tests unitaires supplémentaire du i.s.c.CronParser

===[[Maven]] avec [[Travis-CI]]===

===Git (suite)===

# Forkez le projet '''tagl''' d'un autre binome (i.e. autre que ''donsez/tagl'')
#: '''Attention:''' donnez lui un nom différent (e.g. ''tagl-licensing'')
# Clonez ce nouveau dépôt
# Lancez une compilation pour valider l'état du projet (bonne pratique)
#:<pre>mvn clean verify</pre>
# Ajoutez une bannière de licence dans le fichier '''cron4j-mvn/pom.xml'''
# Lancez une nouvelle compilation pour valider vos modifications
# Commitez et pushez (vers votre fork de ce dépôt, i.e. ''tagl-licensing'')
# Via le site de GitHub, proposez un "Pull Request" au projet initial

Vous pouvez ensuite supprimer le clone de ce fork.
Lorsque le ''pull request'' aura été accepté, vous pourrez supprimer votre fork (''tagl-licensing'') de votre compte GitHub.

===Contrôle Continu===

Dans votre dépôt ''tagl''.

# Ajoutez le plugin [http://mojo.codehaus.org/cobertura-maven-plugin/usage.html Cobertura] à votre projet Maven.
## 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''
## Le plugin ne s'exécute automatiquement pas durant la compilation, il faut utiliser la commande : <pre>mvn cobertura:cobertura</pre>
## '''Bonus:''' Modifiez le fichier ''pom.xml'' pour que le ''goal'' '''cobertura''' soit exécuté pendant la ''phase'' '''package'''.
# Répondez aux questions : ''Mais qu'est ce que la couverture de code ? En quoi c'est utile ?''
# 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.
# Regardez les exemples d'utilisation de cron4j dans cron4j-original/examples

===Bonus Track===

====Clone SVN -> Git====

Source: http://www.yterium.net/Migrer-un-projet-SVN-vers-GIT

<syntaxhighlight lang="bash">
# Cloner le dépôt SVN en dépôt Git (conservation historique)
$ git svn clone svn://svn.code.sf.net/p/cron4j/code/trunk cron4j-original
$ cd cron4j-original
# Test compilation
$ ant jar
$ cd ..
</syntaxhighlight>

====Préparation TAGL====

<syntaxhighlight lang="bash">
# Clone du dépôt TAGL
$ git clone git@github.com:donsez/tagl.git
$ cd tagl
# "Fetch" du dépôt local cloné précédemment
$ git fetch file://$(pwd)/../cron4j-original
# Fusion de ce qui vient d'être fetché
$ git merge FETCH_HEAD
# Envoi sur le serveur
$ git push
</syntaxhighlight>

====Cherry-picking: reprise des modifications d'un collègue====

On considère que:

* votre dépôt Git distant est à l'adresse URL_DEPOT
* votre collègue a un dépôt Git à l'adresse URL_COLLEGUE

<syntaxhighlight lang="bash">
# Dossier temporaire
cd /tmp

# Clone de votre dépôt
git clone URL_DEPOT mon_depot

# Déplacement dans votre dépôt
cd mon_depot

# Définition du dépôt distant
git remote add collegue URL_COLLEGUE

# Récupération des infos du dépôt du collègue
git fetch collegue

# Maintenant, on peut voir les branches du collègue
git branch -a

# On peut fusionner avec une branche
git merge collegue/master

# Si vous avez des conflits, éditez les fichiers concernés,
# et committez avec git commit

# Push vers votre dépôt distant
git push origin

# Optionnel: supprimez la référence vers le dépôt du collègue
git remote rm collegue
</syntaxhighlight>

====Archetype webapp====
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].

<syntaxhighlight lang="bash">
mvn -Djetty.port=9999 jetty:run
</syntaxhighlight>

Naviguez sur http://localhost:9999/monsite

====Scrum tools====
Ces 3 services peuvent être couplé à votre dépôt GitHub pour votre gestion de projet agile avec [[Scrum]] :
* http://www.acunote.com/
* http://backlogtool.com/
* http://www.scrumdo.com/

L'activation se fait via ''Settings > Webhooks & Services > Configure services''.

=Séance 4: AOP & AspectJ=

Dans votre dépôt Git, projet ''cron4j-mvn''.

# Ajoutez le [http://mojo.codehaus.org/aspectj-maven-plugin/ plugin Maven pour AspectJ] au pom.xml
# Ajoutez un aspect de trace à l'invocation des méthodes '''run()''' de l'interface java.lang.Runnable (uniquement pour les objets ''schedulé''s)
#: Affichez une trace avant et après l'exécution de la tâche
# 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 "* * * * *")
#: Lors de l'exécution de '''mvn test''', vous devez voir apparaître les traces préparées dans votre aspect.

Liens utiles:
* [http://ridgetopsolutions.com/blog/2013/02/12/getting-started-with-aspectj-and-maven/ Getting started with AspectJ and Maven]

===Contrôle continu===

# 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.

=Séance 5: Pelix & iPOPO=

Pelix est une plate-forme d'application à services (SOA).
iPOPO est un modèle de composants orientés services (SOCM).

La documentation de Pelix et iPOPO est disponible sur https://ipopo.coderxpress.net/

===Installation de iPOPO===

* Cloner le dépôt Git depuis https://github.com/tcalmant/ipopo
* Se placer dans la branche ''dev''
* Pour installer iPOPO, lancer la commande :

sudo python setup.py install

===Shell Pelix===

Pour lancer un shell Pelix, utilisez la commande:

python -m pelix.shell.console

Les commandes disponibles sont décrites ici: [https://ipopo.coderxpress.net/wiki/doku.php?id=ipopo:refcards:shell Shell Commands]

===Rappels de Python===

* Pas de déclaration du type d'une variable
* Les méthodes d'une classe ont toute comme premier paramètre ''self'', équivalent du ''this'' en Java.
* Blocs définis par indentation (4 espaces ou 1 tab)
* Une ligne finissant par ':' démarre toujours un bloc

<syntaxhighlight lang="python">
# Import d'un module
import pelix

# Définition d'une classe
class MaClasse:
# Constructeur
def __init__(self):
self.default = "stanger"
print("Classe construite")

# Méthode, avec un argument
def sayHello(self, name):
if not name:
# Nom vide ou nul
return "Hello, " + str(self.default)
else:
# Nom valide
return "Hello, " + str(name)

objet = MaClasse()
print(objet.sayHello(""))
print(objet.sayHello("World"))
</syntaxhighlight>

===Service Ping-Pong===

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:".

Exemple:

pong = Pong()
pong.pong("Hello") # <-- Retourne "PONG:Hello"

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:"

Exemple:

ping = Ping()
ping.ping("Hello") # <-- Retourne "PING:PONG:Hello"

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"
* Définir une classe ''Activator'', décorée avec ''@BundleActivator''
* Enregistrer le service dans la méthode ''Activator.start'' et le désenregistrer dans ''Activator.stop''
* S'inspirer du fichier "ipopo/samples/remote/provider.py"

Dans un shell Pelix, installer et démarrer le bundle 'pong' et vérifier que le service est bien inscrit avec la commande ''sl''

4.Transformer la classe ''Ping'' dans ''ping.py'' en un composant iPOPO
* L'objet Pong utilisé dans ''ping()'' doit être un service injecté par iPOPO (''@Requires'')
* Appeler la méthode ''ping()'' dès que le service Pong est injecté (''@BindField'') ou disparait (''@UnbindField'')
* S'inspirer du fichier "ipopo/samples/remote/consumer.py"

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é.

5. Mettre à jour le bundle ''pong''
* Remplacer le préfixe "PONG" par "NI"
* Dans le shell Pelix, mettre à jour le bundle ''pong'' sans redémarrer la plate-forme (commande ''udpate'').
* Vérifier les traces dans le shell pour valider la mise à jour du service.

===Remote Services===

* Ajouter les propriétés permettant l'export du service Pong dans ''pong.py'' (s'inspirer de ''provider.py'')

* Lancer deux shells iPOPO (dans deux terminaux)
* Dans chaque shell iPOPO, installer les bundles:
** ''pelix.remote.dispatcher'': Exportateur de services
** ''pelix.remote.registry''; Importateur de services
** ''pelix.remote.discovery.multicast'': Découverte de services via Multicast
** ''pelix.remote.xml_rpc'': Transport XML-RPC
** ''pelix.http.basic'': Serveur HTTP

Attention: il peut être nécessaire de désactiver votre pare-feu pour que les Remote Services fonctionnent

* Instancier les composants depuis le shell iPOPO, dans chaque framework:
** 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)
** Multicast Discovery: ''instantiate pelix-remote-discovery-multicast-factory multicast-discovery''
** XML-RPC Exporter: ''instantiate pelix-xmlrpc-exporter-factory xml-rpc-exporter''
** XML-RPC Importer: ''instantiate pelix-xmlrpc-exporter-factory xml-rpc-importer''

* Installer le bundle ''ping'' dans un des frameworks et le bundle ''pong'' dans l'autre.
* Le composant ping peut appeler le service pong, qui est dans l'autre framework.

* Voir le code de ''run_remote.py'' pour voir comment démarrer un framework Pelix et installer des bundles depuis Python.
* Jouer un peu avec ''run_remote.py'' (voir ''run_remote.py --help'')

=Séance 6=
[[Tutorial OSGi avec Apache Felix]]

=Séance 7=
Faire un projet PDE pour un bundle cron4j.gogo (indépendant de cron4j.bundle)

Utilisation de https://eclipse.org/tycho/

TAGL/TP

2015-02-26T14:38:01Z

MatthieuCaneill: /* Maven */

Travaux pratiques de l'UE [[TAGL]].

Anciennes versions : [[TAGL/TP 2014]]

=Séance 1 : Gestion de versions=
==Git==

Création d'un dépôt Git local

===Méthode simple: init first===

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".
Cette méthode est la plus simple, car on dispose immédiatement d'un répertoire de travail.

<syntaxhighlight lang="bash">
# Création d'un dépôt Git dans le dossier simple-repo
git init simple-repo

# Création d'un README
cd simple-repo
echo "Hello, World" > README

# Ajout du versionnement du fichier README
git add README

# Commit
git commit
</syntaxhighlight>

À ce niveau, on a un dépôt Git complètement fonctionnel.
Cependant, il est intéressant de pousser ses modifications vers un autre dépôt, sur une autre machine.
On va donc créer un dépôt bare sur une autre machine (ou autre dossier pour l'exemple)

<syntaxhighlight lang="bash">
git init --bare server-repo
</syntaxhighlight>

On considère que l'URL pour accéder à ce dépôt est URL_REPO.
On va d'abord ajouter ce dépôt serveur à la liste des dépôts connu-repos de votre dépôt local.
Étant donné qu'il s'agit du dépôt "principal" à utiliser, on l'appellera //origin//, par convention.

<syntaxhighlight lang="bash">
git remote add origin URL_REPO
# Récupération de ses informations
git fetch origin
</syntaxhighlight>

Ce serveur distant est "vide": il n'a aucune branche. On va donc enregistrer notre branche sur le serveur

<syntaxhighlight lang="bash">
git push origin master
</syntaxhighlight>

À partir de cette commande, la branche locale //master// sera liée à la branche distante //origin/master//.
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.

===Méthode moins simple: bare first===

Si on commence dans par le serveur "vide", il faudra le cloner au lieu de le définir comme un dépôt distant.

<syntaxhighlight lang="bash">
# Création du dépôt vide
git init --bare server-repo
</syntaxhighlight>

On considère que ce dépôt est accessible à l'URL URL_REPO

<syntaxhighlight lang="bash">
# Clonage du dépôt
git clone URL_REPO clone-repo
</syntaxhighlight>

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.
Le dépôt distant est automatiquement appelé //origin//.

<syntaxhighlight lang="bash">
# Commit dans le dépôt local
cd clone-repo
echo hello > readme.rst
git add readme.rst
git commit et ses dépendances
</syntaxhighlight>

Comme dans la méthode simple, il faut pousser la branche master vers le dépôt distant:

<syntaxhighlight lang="bash">
git push origin master
</syntaxhighlight>

===De l'importance des README===

Il est très important d'avoir au moins 2 fichiers dans votre dépôt Git:

* LICENSE: contenant le texte **complet** de la licence de votre projet
* README: décrivant votre projet et comment l'utiliser. Ce fichier doit rappeler le nom de la licence de votre projet

Il est aussi recommandé d'avoir les fichiers suivants:

* AUTHORS: contenant la liste des noms/pseudos et e-mails des auteurs de commits ou de code inclus dans ce projet
* INSTALL: contenant la liste des dépendances de ce projet et des commandes à utiliser pour le compiler et l'installer

Les fichiers LICENSE sont des fichiers textes bruts.
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)

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]

=Séance 2a: Intégration en continue=

===GitHub & [[Travis-CI]]===

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.
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.

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.

Pour utiliser [[Travis-CI]]:

# Créez compte individuel sur GitHub https://github.com
# ''Fork''ez le dépôt https://github.com/heroku/node-js-getting-started
# Ajoutez un collaborateur (i.e. votre binôme) au projet ''forké'', via les paramètres (''settings'') de ce projet
# 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.
# Activez le service Travis-CI: identifiez-vous (''sign in'') sur https://travis-ci.org/ avec votre compte GitHub
# Activez le service pour les projets sur lesquels vous souhaitez appliquer les principes d'intégration continue

[[Travis-CI]] utilise un fichier nommé '''.travis.yml''' (attention: fichier caché sous Unix) pour se configurer et choisir les opérations à effectuer.
Ce fichier doit se trouver à la racine de votre dépôt Git.

Faites un '''Commit''' puis un '''Push''' du fichier '''.travis.yml''' ci-dessous.

<pre>
language: node_js
node_js:
- "0.11"
- "0.10"
- "0.8"
- "0.6"
- iojs
- iojs-v1.0.2

</pre>

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]].

Ajoutez dans le fichier '''package.json''' la section suivante:
<pre>
"devDependencies": {
"jshint": "^2.6.0"
},
"scripts": {
"test": "./node_modules/jshint/bin/jshint index.js"
}
</pre>
et incrémentez le numéro de version.

Faites un '''Commit''' puis un '''Push''' des fichiers touchés.

'''Remarque:'''
'''jshint''' peut être lancé localement avec les commandes suivantes:
<pre>
sudo npm install jshint
jshint index.js
</pre>

A lire
* http://docs.travis-ci.com/user/languages/javascript-with-nodejs/
* https://github.com/docdis/learn-travis/blob/master/README.md

=Séance 2b: Livraison en continue=

==[[Heroku]]==
[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.

# Créez un compte gratuit sur [https://signup.heroku.com Heroku]
# Forkez le dépôt https://github.com/heroku/node-js-getting-started
# Dans Heroku, créez une nouvelle app Node.js, et liez-la au repository Github créé à l'étape précédente
# Choisissez l'option "Déploiement automatique" depuis la branche **master**
# Modifiez le fichier index.js pour afficher la version de service dans la page HTML
<pre>
var fs = require('fs');
var package = JSON.parse(fs.readFileSync('./package.json', 'utf8'));
var version=package.version;
...
response.send('Hello World! (current version: '+version+')');
...
</pre>

Incrémentez le numéro de version dans le fichier ''package.json''

Faites un '''Commit''' puis un '''Push''' des fichiers touchés.

Naviguez l'application sur Heroku

# Modifiez le fichier index.js pour franciser le message dans la page HTML
<pre>
...
response.send('Bonjour Tout Le Monde! (version courante: '+version+')');
...
</pre>

Incrémentez le numéro de version dans le fichier '''package.json''

Faites un '''Commit''' puis un '''Push''' des fichiers touchés.

Naviguez l'application sur Heroku

=Séance 3: Builders=

==[[Ant]]==

==[[Maven]]==

[http://maven.apache.org/download.cgi Charger et installer Maven 3].

Debian/Ubuntu & friends:
<pre>
sudo apt-get update && sudo apt-get install maven
</pre>

<pre>
mvn -version
</pre>

Faites une copie du projet, basée sur Maven:

# Dans votre dépôt Git, créez un dossier '''cron4j-mvn''': il contiendra le projet Cron4J avec la structure Maven
# 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):
#:<pre>mvn archetype:generate -DarchetypeGroupId=org.apache.maven.archetypes -DarchetypeArtifactId=maven-archetype-quickstart</pre>
# Cette commande crée un projet avec un fichier ''pom.xml'', et une classe et un test modèles: supprimez ces modèles
# Copiez les sources de Cron4J depuis le dossier '''cron4j-original''' dans le dossier '''src/main/java''' de votre projet Maven
# Faites un essai de compilation:
#:<pre>mvn clean verify</pre>
# 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])
# 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.

==Tests Unitaires avec JUnit 4==
Survoller le tutoriel [http://www.vogella.com/tutorials/JUnit/article.html Unit Testing with JUnit]

# Ajouter le test unitaire suivant au projet, dans le fichier '''src/test/it/sauronsoftware/SchedulingPatternTest.java
<pre>
package it.sauronsoftware;

import it.sauronsoftware.cron4j.SchedulingPattern;
import it.sauronsoftware.cron4j.InvalidPatternException;

import static org.junit.Assert.assertEquals;
import static org.junit.Assert.assertTrue;

import org.junit.AfterClass;
import org.junit.BeforeClass;
import org.junit.Test;

public class SchedulingPatternTest {

@BeforeClass
public static void testSetup() {
}

@AfterClass
public static void testCleanup() {
// Teardown for data used by the unit tests
}

@Test(expected = InvalidPatternException.class)
public void testExceptionIsThrown() {
SchedulingPattern sp = new SchedulingPattern("0 5 * *");
}

@Test
public void testPattern() {
String pattern;
pattern="0 5 * * *|8 10 * * *|22 17 * * *";
assertTrue(pattern + "is correct", SchedulingPattern.validate(pattern));
pattern="0 5 * *";
assertTrue(pattern + "is correct", SchedulingPattern.validate(pattern));
}
}
</pre>

# Committez et Pushez ce nouveau fichier, pour que Travis lance les tests dès que possible
# Lancez les tests unitaires avec <pre>mvn test</pre> Ce test va '''échouer''': corrigez le.
# Committez et Pushez la version corrigée des tests: Travis enverra un mail pour indiquer si les tests échouent ou non
#: '''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.
# Naviguez sur http://travis-ci.org pour vérifier les builds effectués.
# Créez des tests unitaires supplémentaire du i.s.c.CronParser

===[[Maven]] avec [[Travis-CI]]===

===Git (suite)===

# Forkez le projet '''tagl''' d'un autre binome (i.e. autre que ''donsez/tagl'')
#: '''Attention:''' donnez lui un nom différent (e.g. ''tagl-licensing'')
# Clonez ce nouveau dépôt
# Lancez une compilation pour valider l'état du projet (bonne pratique)
#:<pre>mvn clean verify</pre>
# Ajoutez une bannière de licence dans le fichier '''cron4j-mvn/pom.xml'''
# Lancez une nouvelle compilation pour valider vos modifications
# Commitez et pushez (vers votre fork de ce dépôt, i.e. ''tagl-licensing'')
# Via le site de GitHub, proposez un "Pull Request" au projet initial

Vous pouvez ensuite supprimer le clone de ce fork.
Lorsque le ''pull request'' aura été accepté, vous pourrez supprimer votre fork (''tagl-licensing'') de votre compte GitHub.

===Contrôle Continu===

Dans votre dépôt ''tagl''.

# Ajoutez le plugin [http://mojo.codehaus.org/cobertura-maven-plugin/usage.html Cobertura] à votre projet Maven.
## 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''
## Le plugin ne s'exécute automatiquement pas durant la compilation, il faut utiliser la commande : <pre>mvn cobertura:cobertura</pre>
## '''Bonus:''' Modifiez le fichier ''pom.xml'' pour que le ''goal'' '''cobertura''' soit exécuté pendant la ''phase'' '''package'''.
# Répondez aux questions : ''Mais qu'est ce que la couverture de code ? En quoi c'est utile ?''
# 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.
# Regardez les exemples d'utilisation de cron4j dans cron4j-original/examples

===Bonus Track===

====Clone SVN -> Git====

Source: http://www.yterium.net/Migrer-un-projet-SVN-vers-GIT

<syntaxhighlight lang="bash">
# Cloner le dépôt SVN en dépôt Git (conservation historique)
$ git svn clone svn://svn.code.sf.net/p/cron4j/code/trunk cron4j-original
$ cd cron4j-original
# Test compilation
$ ant jar
$ cd ..
</syntaxhighlight>

====Préparation TAGL====

<syntaxhighlight lang="bash">
# Clone du dépôt TAGL
$ git clone git@github.com:donsez/tagl.git
$ cd tagl
# "Fetch" du dépôt local cloné précédemment
$ git fetch file://$(pwd)/../cron4j-original
# Fusion de ce qui vient d'être fetché
$ git merge FETCH_HEAD
# Envoi sur le serveur
$ git push
</syntaxhighlight>

====Cherry-picking: reprise des modifications d'un collègue====

On considère que:

* votre dépôt Git distant est à l'adresse URL_DEPOT
* votre collègue a un dépôt Git à l'adresse URL_COLLEGUE

<syntaxhighlight lang="bash">
# Dossier temporaire
cd /tmp

# Clone de votre dépôt
git clone URL_DEPOT mon_depot

# Déplacement dans votre dépôt
cd mon_depot

# Définition du dépôt distant
git remote add collegue URL_COLLEGUE

# Récupération des infos du dépôt du collègue
git fetch collegue

# Maintenant, on peut voir les branches du collègue
git branch -a

# On peut fusionner avec une branche
git merge collegue/master

# Si vous avez des conflits, éditez les fichiers concernés,
# et committez avec git commit

# Push vers votre dépôt distant
git push origin

# Optionnel: supprimez la référence vers le dépôt du collègue
git remote rm collegue
</syntaxhighlight>

====Archetype webapp====
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].

<syntaxhighlight lang="bash">
mvn -Djetty.port=9999 jetty:run
</syntaxhighlight>

Naviguez sur http://localhost:9999/monsite

====Scrum tools====
Ces 3 services peuvent être couplé à votre dépôt GitHub pour votre gestion de projet agile avec [[Scrum]] :
* http://www.acunote.com/
* http://backlogtool.com/
* http://www.scrumdo.com/

L'activation se fait via ''Settings > Webhooks & Services > Configure services''.

=Séance 4: AOP & AspectJ=

Dans votre dépôt Git, projet ''cron4j-mvn''.

# Ajoutez le [http://mojo.codehaus.org/aspectj-maven-plugin/ plugin Maven pour AspectJ] au pom.xml
# Ajoutez un aspect de trace à l'invocation des méthodes '''run()''' de l'interface java.lang.Runnable (uniquement pour les objets ''schedulé''s)
#: Affichez une trace avant et après l'exécution de la tâche
# 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 "* * * * *")
#: Lors de l'exécution de '''mvn test''', vous devez voir apparaître les traces préparées dans votre aspect.

Liens utiles:
* [http://ridgetopsolutions.com/blog/2013/02/12/getting-started-with-aspectj-and-maven/ Getting started with AspectJ and Maven]

===Contrôle continu===

# 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.

=Séance 5: Pelix & iPOPO=

Pelix est une plate-forme d'application à services (SOA).
iPOPO est un modèle de composants orientés services (SOCM).

La documentation de Pelix et iPOPO est disponible sur https://ipopo.coderxpress.net/

===Installation de iPOPO===

* Cloner le dépôt Git depuis https://github.com/tcalmant/ipopo
* Se placer dans la branche ''dev''
* Pour installer iPOPO, lancer la commande :

sudo python setup.py install

===Shell Pelix===

Pour lancer un shell Pelix, utilisez la commande:

python -m pelix.shell.console

Les commandes disponibles sont décrites ici: [https://ipopo.coderxpress.net/wiki/doku.php?id=ipopo:refcards:shell Shell Commands]

===Rappels de Python===

* Pas de déclaration du type d'une variable
* Les méthodes d'une classe ont toute comme premier paramètre ''self'', équivalent du ''this'' en Java.
* Blocs définis par indentation (4 espaces ou 1 tab)
* Une ligne finissant par ':' démarre toujours un bloc

<syntaxhighlight lang="python">
# Import d'un module
import pelix

# Définition d'une classe
class MaClasse:
# Constructeur
def __init__(self):
self.default = "stanger"
print("Classe construite")

# Méthode, avec un argument
def sayHello(self, name):
if not name:
# Nom vide ou nul
return "Hello, " + str(self.default)
else:
# Nom valide
return "Hello, " + str(name)

objet = MaClasse()
print(objet.sayHello(""))
print(objet.sayHello("World"))
</syntaxhighlight>

===Service Ping-Pong===

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:".

Exemple:

pong = Pong()
pong.pong("Hello") # <-- Retourne "PONG:Hello"

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:"

Exemple:

ping = Ping()
ping.ping("Hello") # <-- Retourne "PING:PONG:Hello"

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"
* Définir une classe ''Activator'', décorée avec ''@BundleActivator''
* Enregistrer le service dans la méthode ''Activator.start'' et le désenregistrer dans ''Activator.stop''
* S'inspirer du fichier "ipopo/samples/remote/provider.py"

Dans un shell Pelix, installer et démarrer le bundle 'pong' et vérifier que le service est bien inscrit avec la commande ''sl''

4.Transformer la classe ''Ping'' dans ''ping.py'' en un composant iPOPO
* L'objet Pong utilisé dans ''ping()'' doit être un service injecté par iPOPO (''@Requires'')
* Appeler la méthode ''ping()'' dès que le service Pong est injecté (''@BindField'') ou disparait (''@UnbindField'')
* S'inspirer du fichier "ipopo/samples/remote/consumer.py"

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é.

5. Mettre à jour le bundle ''pong''
* Remplacer le préfixe "PONG" par "NI"
* Dans le shell Pelix, mettre à jour le bundle ''pong'' sans redémarrer la plate-forme (commande ''udpate'').
* Vérifier les traces dans le shell pour valider la mise à jour du service.

===Remote Services===

* Ajouter les propriétés permettant l'export du service Pong dans ''pong.py'' (s'inspirer de ''provider.py'')

* Lancer deux shells iPOPO (dans deux terminaux)
* Dans chaque shell iPOPO, installer les bundles:
** ''pelix.remote.dispatcher'': Exportateur de services
** ''pelix.remote.registry''; Importateur de services
** ''pelix.remote.discovery.multicast'': Découverte de services via Multicast
** ''pelix.remote.xml_rpc'': Transport XML-RPC
** ''pelix.http.basic'': Serveur HTTP

Attention: il peut être nécessaire de désactiver votre pare-feu pour que les Remote Services fonctionnent

* Instancier les composants depuis le shell iPOPO, dans chaque framework:
** 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)
** Multicast Discovery: ''instantiate pelix-remote-discovery-multicast-factory multicast-discovery''
** XML-RPC Exporter: ''instantiate pelix-xmlrpc-exporter-factory xml-rpc-exporter''
** XML-RPC Importer: ''instantiate pelix-xmlrpc-exporter-factory xml-rpc-importer''

* Installer le bundle ''ping'' dans un des frameworks et le bundle ''pong'' dans l'autre.
* Le composant ping peut appeler le service pong, qui est dans l'autre framework.

* Voir le code de ''run_remote.py'' pour voir comment démarrer un framework Pelix et installer des bundles depuis Python.
* Jouer un peu avec ''run_remote.py'' (voir ''run_remote.py --help'')

=Séance 6=
[[Tutorial OSGi avec Apache Felix]]

=Séance 7=
Faire un projet PDE pour un bundle cron4j.gogo (indépendant de cron4j.bundle)

Utilisation de https://eclipse.org/tycho/

TAGL/TP

2015-02-17T09:41:35Z

MatthieuCaneill: /* Heruko */ lol heruko

Travaux pratiques de l'UE [[TAGL]].

Anciennes versions : [[TAGL/TP 2014]]

=Séance 1 : Gestion de versions=
==Git==

Création d'un dépôt Git local

===Méthode simple: init first===

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".
Cette méthode est la plus simple, car on dispose immédiatement d'un répertoire de travail.

<syntaxhighlight lang="bash">
# Création d'un dépôt Git dans le dossier simple-repo
git init simple-repo

# Création d'un README
cd simple-repo
echo "Hello, World" > README

# Ajout du versionnement du fichier README
git add README

# Commit
git commit
</syntaxhighlight>

À ce niveau, on a un dépôt Git complètement fonctionnel.
Cependant, il est intéressant de pousser ses modifications vers un autre dépôt, sur une autre machine.
On va donc créer un dépôt bare sur une autre machine (ou autre dossier pour l'exemple)

<syntaxhighlight lang="bash">
git init --bare server-repo
</syntaxhighlight>

On considère que l'URL pour accéder à ce dépôt est URL_REPO.
On va d'abord ajouter ce dépôt serveur à la liste des dépôts connu-repos de votre dépôt local.
Étant donné qu'il s'agit du dépôt "principal" à utiliser, on l'appellera //origin//, par convention.

<syntaxhighlight lang="bash">
git remote add origin URL_REPO
# Récupération de ses informations
git fetch origin
</syntaxhighlight>

Ce serveur distant est "vide": il n'a aucune branche. On va donc enregistrer notre branche sur le serveur

<syntaxhighlight lang="bash">
git push origin master
</syntaxhighlight>

À partir de cette commande, la branche locale //master// sera liée à la branche distante //origin/master//.
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.

===Méthode moins simple: bare first===

Si on commence dans par le serveur "vide", il faudra le cloner au lieu de le définir comme un dépôt distant.

<syntaxhighlight lang="bash">
# Création du dépôt vide
git init --bare server-repo
</syntaxhighlight>

On considère que ce dépôt est accessible à l'URL URL_REPO

<syntaxhighlight lang="bash">
# Clonage du dépôt
git clone URL_REPO clone-repo
</syntaxhighlight>

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.
Le dépôt distant est automatiquement appelé //origin//.

<syntaxhighlight lang="bash">
# Commit dans le dépôt local
cd clone-repo
echo hello > readme.rst
git add readme.rst
git commit et ses dépendances
</syntaxhighlight>

Comme dans la méthode simple, il faut pousser la branche master vers le dépôt distant:

<syntaxhighlight lang="bash">
git push origin master
</syntaxhighlight>

===De l'importance des README===

Il est très important d'avoir au moins 2 fichiers dans votre dépôt Git:

* LICENSE: contenant le texte **complet** de la licence de votre projet
* README: décrivant votre projet et comment l'utiliser. Ce fichier doit rappeler le nom de la licence de votre projet

Il est aussi recommandé d'avoir les fichiers suivants:

* AUTHORS: contenant la liste des noms/pseudos et e-mails des auteurs de commits ou de code inclus dans ce projet
* INSTALL: contenant la liste des dépendances de ce projet et des commandes à utiliser pour le compiler et l'installer

Les fichiers LICENSE sont des fichiers textes bruts.
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)

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]

=Séance 2a: Intégration en continue=

===GitHub & [[Travis-CI]]===

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.
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.

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.

Pour utiliser [[Travis-CI]]:

# Créez compte individuel sur GitHub https://github.com
# ''Fork''ez le projet TAGL '''cron4j''' depuis https://github.com/donsez/tagl
# Ajoutez un collaborateur (i.e. votre binôme) au projet ''forké'', via les paramètres (''settings'') de ce projet
# 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.
# Activez le service Travis-CI: identifiez-vous (''sign in'') sur https://travis-ci.org/ avec votre compte GitHub
# Activez le service pour les projets sur lesquels vous souhaitez appliquer les principes d'intégration continue

[[Travis-CI]] utilise un fichier nommé '''.travis.yml''' (attention: fichier caché sous Unix) pour se configurer et choisir les opérations à effectuer.
Ce fichier doit se trouver à la racine de votre dépôt Git.

Faites un '''Commit''' puis un '''Push''' du fichier '''.travis.yml''' ci-dessous.

<pre>
language: node_js
node_js:
- "0.11"
- "0.10"
- "0.8"
- "0.6"
- iojs
- iojs-v1.0.2

script:
- pushd cron4j-original && ant rel && popd
</pre>

(voir http://docs.travis-ci.com/user/languages/javascript-with-nodejs/)

Ce fichier indique que le projet dans ce dépôt doit être testé sur plusieurs versions de [[Node.js]], et que le script à exécuter pour lancer les tests est '''pushd cron4j-original && ant rel && popd'''.
[[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').

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.

Une fois ce fichier de configuration '''pushé''', Travis-CI se mettra en route dès le prochain '''push'''.

=Séance 2b: Livraison en continue=

==[[Heroku]]==
[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.

# Créez un compte gratuit sur [https://signup.heroku.com Heroku]
# Forkez le dépôt https://github.com/heroku/node-js-getting-started
# Dans Heroku, créez une nouvelle app Node.js, et liez-la au repository Github créé à l'étape précédente
# Choisissez l'option "Déploiement automatique" depuis la branche **master**
# Modifiez le fichier index.js pour afficher la version de service dans la page HTML
<pre>
var fs = require('fs');
var package = JSON.parse(fs.readFileSync('./package.json', 'utf8'));
var version=package.version;
...
response.send('Hello World! (current version: '+version+')');
...
</pre>

=Séance 3: Builders=

==[[Ant]]==

==[[Maven]]==

[http://maven.apache.org/download.cgi Charger et installer Maven 3].

<pre>
mvn -version
</pre>

Faites une copie du projet, basée sur Maven:

# Dans votre dépôt Git, créez un dossier '''cron4j-mvn''': il contiendra le projet Cron4J avec la structure Maven
# 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):
#:<pre>mvn archetype:generate -DarchetypeGroupId=org.apache.maven.archetypes -DarchetypeArtifactId=maven-archetype-quickstart</pre>
# Cette commande crée un projet avec un fichier ''pom.xml'', et une classe et un test modèles: supprimez ces modèles
# Copiez les sources de Cron4J depuis le dossier '''cron4j-original''' dans le dossier '''src/main/java''' de votre projet Maven
# Faites un essai de compilation:
#:<pre>mvn clean verify</pre>
# 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])
# 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.

==Tests Unitaires avec JUnit 4==
Survoller le tutoriel [http://www.vogella.com/tutorials/JUnit/article.html Unit Testing with JUnit]

# Ajouter le test unitaire suivant au projet, dans le fichier '''src/test/it/sauronsoftware/SchedulingPatternTest.java
<pre>
package it.sauronsoftware;

import it.sauronsoftware.cron4j.SchedulingPattern;
import it.sauronsoftware.cron4j.InvalidPatternException;

import static org.junit.Assert.assertEquals;
import static org.junit.Assert.assertTrue;

import org.junit.AfterClass;
import org.junit.BeforeClass;
import org.junit.Test;

public class SchedulingPatternTest {

@BeforeClass
public static void testSetup() {
}

@AfterClass
public static void testCleanup() {
// Teardown for data used by the unit tests
}

@Test(expected = InvalidPatternException.class)
public void testExceptionIsThrown() {
SchedulingPattern sp = new SchedulingPattern("0 5 * *");
}

@Test
public void testPattern() {
String pattern;
pattern="0 5 * * *|8 10 * * *|22 17 * * *";
assertTrue(pattern + "is correct", SchedulingPattern.validate(pattern));
pattern="0 5 * *";
assertTrue(pattern + "is correct", SchedulingPattern.validate(pattern));
}
}
</pre>

# Committez et Pushez ce nouveau fichier, pour que Travis lance les tests dès que possible
# Lancez les tests unitaires avec <pre>mvn test</pre> Ce test va '''échouer''': corrigez le.
# Committez et Pushez la version corrigée des tests: Travis enverra un mail pour indiquer si les tests échouent ou non
#: '''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.
# Naviguez sur http://travis-ci.org pour vérifier les builds effectués.
# Créez des tests unitaires supplémentaire du i.s.c.CronParser

===[[Maven]] avec [[Travis-CI]]===

===Git (suite)===

# Forkez le projet '''tagl''' d'un autre binome (i.e. autre que ''donsez/tagl'')
#: '''Attention:''' donnez lui un nom différent (e.g. ''tagl-licensing'')
# Clonez ce nouveau dépôt
# Lancez une compilation pour valider l'état du projet (bonne pratique)
#:<pre>mvn clean verify</pre>
# Ajoutez une bannière de licence dans le fichier '''cron4j-mvn/pom.xml'''
# Lancez une nouvelle compilation pour valider vos modifications
# Commitez et pushez (vers votre fork de ce dépôt, i.e. ''tagl-licensing'')
# Via le site de GitHub, proposez un "Pull Request" au projet initial

Vous pouvez ensuite supprimer le clone de ce fork.
Lorsque le ''pull request'' aura été accepté, vous pourrez supprimer votre fork (''tagl-licensing'') de votre compte GitHub.

===Contrôle Continu===

Dans votre dépôt ''tagl''.

# Ajoutez le plugin [http://mojo.codehaus.org/cobertura-maven-plugin/usage.html Cobertura] à votre projet Maven.
## 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''
## Le plugin ne s'exécute automatiquement pas durant la compilation, il faut utiliser la commande : <pre>mvn cobertura:cobertura</pre>
## '''Bonus:''' Modifiez le fichier ''pom.xml'' pour que le ''goal'' '''cobertura''' soit exécuté pendant la ''phase'' '''package'''.
# Répondez aux questions : ''Mais qu'est ce que la couverture de code ? En quoi c'est utile ?''
# 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.
# Regardez les exemples d'utilisation de cron4j dans cron4j-original/examples

===Bonus Track===

====Clone SVN -> Git====

Source: http://www.yterium.net/Migrer-un-projet-SVN-vers-GIT

<syntaxhighlight lang="bash">
# Cloner le dépôt SVN en dépôt Git (conservation historique)
$ git svn clone svn://svn.code.sf.net/p/cron4j/code/trunk cron4j-original
$ cd cron4j-original
# Test compilation
$ ant jar
$ cd ..
</syntaxhighlight>

====Préparation TAGL====

<syntaxhighlight lang="bash">
# Clone du dépôt TAGL
$ git clone git@github.com:donsez/tagl.git
$ cd tagl
# "Fetch" du dépôt local cloné précédemment
$ git fetch file://$(pwd)/../cron4j-original
# Fusion de ce qui vient d'être fetché
$ git merge FETCH_HEAD
# Envoi sur le serveur
$ git push
</syntaxhighlight>

====Cherry-picking: reprise des modifications d'un collègue====

On considère que:

* votre dépôt Git distant est à l'adresse URL_DEPOT
* votre collègue a un dépôt Git à l'adresse URL_COLLEGUE

<syntaxhighlight lang="bash">
# Dossier temporaire
cd /tmp

# Clone de votre dépôt
git clone URL_DEPOT mon_depot

# Déplacement dans votre dépôt
cd mon_depot

# Définition du dépôt distant
git remote add collegue URL_COLLEGUE

# Récupération des infos du dépôt du collègue
git fetch collegue

# Maintenant, on peut voir les branches du collègue
git branch -a

# On peut fusionner avec une branche
git merge collegue/master

# Si vous avez des conflits, éditez les fichiers concernés,
# et committez avec git commit

# Push vers votre dépôt distant
git push origin

# Optionnel: supprimez la référence vers le dépôt du collègue
git remote rm collegue
</syntaxhighlight>

====Archetype webapp====
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].

<syntaxhighlight lang="bash">
mvn -Djetty.port=9999 jetty:run
</syntaxhighlight>

Naviguez sur http://localhost:9999/monsite

====Scrum tools====
Ces 3 services peuvent être couplé à votre dépôt GitHub pour votre gestion de projet agile avec [[Scrum]] :
* http://www.acunote.com/
* http://backlogtool.com/
* http://www.scrumdo.com/

L'activation se fait via ''Settings > Webhooks & Services > Configure services''.

=Séance 4: AOP & AspectJ=

Dans votre dépôt Git, projet ''cron4j-mvn''.

# Ajoutez le [http://mojo.codehaus.org/aspectj-maven-plugin/ plugin Maven pour AspectJ] au pom.xml
# Ajoutez un aspect de trace à l'invocation des méthodes '''run()''' de l'interface java.lang.Runnable (uniquement pour les objets ''schedulé''s)
#: Affichez une trace avant et après l'exécution de la tâche
# 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 "* * * * *")
#: Lors de l'exécution de '''mvn test''', vous devez voir apparaître les traces préparées dans votre aspect.

Liens utiles:
* [http://ridgetopsolutions.com/blog/2013/02/12/getting-started-with-aspectj-and-maven/ Getting started with AspectJ and Maven]

===Contrôle continu===

# 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.

=Séance 5: Pelix & iPOPO=

Pelix est une plate-forme d'application à services (SOA).
iPOPO est un modèle de composants orientés services (SOCM).

La documentation de Pelix et iPOPO est disponible sur https://ipopo.coderxpress.net/

===Installation de iPOPO===

* Cloner le dépôt Git depuis https://github.com/tcalmant/ipopo
* Se placer dans la branche ''dev''
* Pour installer iPOPO, lancer la commande :

sudo python setup.py install

===Shell Pelix===

Pour lancer un shell Pelix, utilisez la commande:

python -m pelix.shell.console

Les commandes disponibles sont décrites ici: [https://ipopo.coderxpress.net/wiki/doku.php?id=ipopo:refcards:shell Shell Commands]

===Rappels de Python===

* Pas de déclaration du type d'une variable
* Les méthodes d'une classe ont toute comme premier paramètre ''self'', équivalent du ''this'' en Java.
* Blocs définis par indentation (4 espaces ou 1 tab)
* Une ligne finissant par ':' démarre toujours un bloc

<syntaxhighlight lang="python">
# Import d'un module
import pelix

# Définition d'une classe
class MaClasse:
# Constructeur
def __init__(self):
self.default = "stanger"
print("Classe construite")

# Méthode, avec un argument
def sayHello(self, name):
if not name:
# Nom vide ou nul
return "Hello, " + str(self.default)
else:
# Nom valide
return "Hello, " + str(name)

objet = MaClasse()
print(objet.sayHello(""))
print(objet.sayHello("World"))
</syntaxhighlight>

===Service Ping-Pong===

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:".

Exemple:

pong = Pong()
pong.pong("Hello") # <-- Retourne "PONG:Hello"

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:"

Exemple:

ping = Ping()
ping.ping("Hello") # <-- Retourne "PING:PONG:Hello"

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"
* Définir une classe ''Activator'', décorée avec ''@BundleActivator''
* Enregistrer le service dans la méthode ''Activator.start'' et le désenregistrer dans ''Activator.stop''
* S'inspirer du fichier "ipopo/samples/remote/provider.py"

Dans un shell Pelix, installer et démarrer le bundle 'pong' et vérifier que le service est bien inscrit avec la commande ''sl''

4.Transformer la classe ''Ping'' dans ''ping.py'' en un composant iPOPO
* L'objet Pong utilisé dans ''ping()'' doit être un service injecté par iPOPO (''@Requires'')
* Appeler la méthode ''ping()'' dès que le service Pong est injecté (''@BindField'') ou disparait (''@UnbindField'')
* S'inspirer du fichier "ipopo/samples/remote/consumer.py"

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é.

5. Mettre à jour le bundle ''pong''
* Remplacer le préfixe "PONG" par "NI"
* Dans le shell Pelix, mettre à jour le bundle ''pong'' sans redémarrer la plate-forme (commande ''udpate'').
* Vérifier les traces dans le shell pour valider la mise à jour du service.

===Remote Services===

* Ajouter les propriétés permettant l'export du service Pong dans ''pong.py'' (s'inspirer de ''provider.py'')

* Lancer deux shells iPOPO (dans deux terminaux)
* Dans chaque shell iPOPO, installer les bundles:
** ''pelix.remote.dispatcher'': Exportateur de services
** ''pelix.remote.registry''; Importateur de services
** ''pelix.remote.discovery.multicast'': Découverte de services via Multicast
** ''pelix.remote.xml_rpc'': Transport XML-RPC
** ''pelix.http.basic'': Serveur HTTP

Attention: il peut être nécessaire de désactiver votre pare-feu pour que les Remote Services fonctionnent

* Instancier les composants depuis le shell iPOPO, dans chaque framework:
** 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)
** Multicast Discovery: ''instantiate pelix-remote-discovery-multicast-factory multicast-discovery''
** XML-RPC Exporter: ''instantiate pelix-xmlrpc-exporter-factory xml-rpc-exporter''
** XML-RPC Importer: ''instantiate pelix-xmlrpc-exporter-factory xml-rpc-importer''

* Installer le bundle ''ping'' dans un des frameworks et le bundle ''pong'' dans l'autre.
* Le composant ping peut appeler le service pong, qui est dans l'autre framework.

* Voir le code de ''run_remote.py'' pour voir comment démarrer un framework Pelix et installer des bundles depuis Python.
* Jouer un peu avec ''run_remote.py'' (voir ''run_remote.py --help'')

=Séance 6=
[[Tutorial OSGi avec Apache Felix]]

=Séance 7=
Faire un projet PDE pour un bundle cron4j.gogo (indépendant de cron4j.bundle)

Utilisation de https://eclipse.org/tycho/

TAGL/TP

2015-02-17T09:40:55Z

MatthieuCaneill: /* Heruko */

Travaux pratiques de l'UE [[TAGL]].

Anciennes versions : [[TAGL/TP 2014]]

=Séance 1 : Gestion de versions=
==Git==

Création d'un dépôt Git local

===Méthode simple: init first===

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".
Cette méthode est la plus simple, car on dispose immédiatement d'un répertoire de travail.

<syntaxhighlight lang="bash">
# Création d'un dépôt Git dans le dossier simple-repo
git init simple-repo

# Création d'un README
cd simple-repo
echo "Hello, World" > README

# Ajout du versionnement du fichier README
git add README

# Commit
git commit
</syntaxhighlight>

À ce niveau, on a un dépôt Git complètement fonctionnel.
Cependant, il est intéressant de pousser ses modifications vers un autre dépôt, sur une autre machine.
On va donc créer un dépôt bare sur une autre machine (ou autre dossier pour l'exemple)

<syntaxhighlight lang="bash">
git init --bare server-repo
</syntaxhighlight>

On considère que l'URL pour accéder à ce dépôt est URL_REPO.
On va d'abord ajouter ce dépôt serveur à la liste des dépôts connu-repos de votre dépôt local.
Étant donné qu'il s'agit du dépôt "principal" à utiliser, on l'appellera //origin//, par convention.

<syntaxhighlight lang="bash">
git remote add origin URL_REPO
# Récupération de ses informations
git fetch origin
</syntaxhighlight>

Ce serveur distant est "vide": il n'a aucune branche. On va donc enregistrer notre branche sur le serveur

<syntaxhighlight lang="bash">
git push origin master
</syntaxhighlight>

À partir de cette commande, la branche locale //master// sera liée à la branche distante //origin/master//.
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.

===Méthode moins simple: bare first===

Si on commence dans par le serveur "vide", il faudra le cloner au lieu de le définir comme un dépôt distant.

<syntaxhighlight lang="bash">
# Création du dépôt vide
git init --bare server-repo
</syntaxhighlight>

On considère que ce dépôt est accessible à l'URL URL_REPO

<syntaxhighlight lang="bash">
# Clonage du dépôt
git clone URL_REPO clone-repo
</syntaxhighlight>

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.
Le dépôt distant est automatiquement appelé //origin//.

<syntaxhighlight lang="bash">
# Commit dans le dépôt local
cd clone-repo
echo hello > readme.rst
git add readme.rst
git commit et ses dépendances
</syntaxhighlight>

Comme dans la méthode simple, il faut pousser la branche master vers le dépôt distant:

<syntaxhighlight lang="bash">
git push origin master
</syntaxhighlight>

===De l'importance des README===

Il est très important d'avoir au moins 2 fichiers dans votre dépôt Git:

* LICENSE: contenant le texte **complet** de la licence de votre projet
* README: décrivant votre projet et comment l'utiliser. Ce fichier doit rappeler le nom de la licence de votre projet

Il est aussi recommandé d'avoir les fichiers suivants:

* AUTHORS: contenant la liste des noms/pseudos et e-mails des auteurs de commits ou de code inclus dans ce projet
* INSTALL: contenant la liste des dépendances de ce projet et des commandes à utiliser pour le compiler et l'installer

Les fichiers LICENSE sont des fichiers textes bruts.
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)

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]

=Séance 2a: Intégration en continue=

===GitHub & [[Travis-CI]]===

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.
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.

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.

Pour utiliser [[Travis-CI]]:

# Créez compte individuel sur GitHub https://github.com
# ''Fork''ez le projet TAGL '''cron4j''' depuis https://github.com/donsez/tagl
# Ajoutez un collaborateur (i.e. votre binôme) au projet ''forké'', via les paramètres (''settings'') de ce projet
# 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.
# Activez le service Travis-CI: identifiez-vous (''sign in'') sur https://travis-ci.org/ avec votre compte GitHub
# Activez le service pour les projets sur lesquels vous souhaitez appliquer les principes d'intégration continue

[[Travis-CI]] utilise un fichier nommé '''.travis.yml''' (attention: fichier caché sous Unix) pour se configurer et choisir les opérations à effectuer.
Ce fichier doit se trouver à la racine de votre dépôt Git.

Faites un '''Commit''' puis un '''Push''' du fichier '''.travis.yml''' ci-dessous.

<pre>
language: node_js
node_js:
- "0.11"
- "0.10"
- "0.8"
- "0.6"
- iojs
- iojs-v1.0.2

script:
- pushd cron4j-original && ant rel && popd
</pre>

(voir http://docs.travis-ci.com/user/languages/javascript-with-nodejs/)

Ce fichier indique que le projet dans ce dépôt doit être testé sur plusieurs versions de [[Node.js]], et que le script à exécuter pour lancer les tests est '''pushd cron4j-original && ant rel && popd'''.
[[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').

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.

Une fois ce fichier de configuration '''pushé''', Travis-CI se mettra en route dès le prochain '''push'''.

=Séance 2b: Livraison en continue=

==[[Heruko]]==
[https://www.heroku.com/ Heruko] 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.

# Créez un compte gratuit sur [https://signup.heroku.com Heruko]
# Forkez le dépôt https://github.com/heroku/node-js-getting-started
# Dans Heroku, créez une nouvelle app Node.js, et liez-la au repository Github créé à l'étape précédente
# Choisissez l'option "Déploiement automatique" depuis la branche **master**
# Modifiez le fichier index.js pour afficher la version de service dans la page HTML
<pre>
var fs = require('fs');
var package = JSON.parse(fs.readFileSync('./package.json', 'utf8'));
var version=package.version;
...
response.send('Hello World! (current version: '+version+')');
...
</pre>

=Séance 3: Builders=

==[[Ant]]==

==[[Maven]]==

[http://maven.apache.org/download.cgi Charger et installer Maven 3].

<pre>
mvn -version
</pre>

Faites une copie du projet, basée sur Maven:

# Dans votre dépôt Git, créez un dossier '''cron4j-mvn''': il contiendra le projet Cron4J avec la structure Maven
# 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):
#:<pre>mvn archetype:generate -DarchetypeGroupId=org.apache.maven.archetypes -DarchetypeArtifactId=maven-archetype-quickstart</pre>
# Cette commande crée un projet avec un fichier ''pom.xml'', et une classe et un test modèles: supprimez ces modèles
# Copiez les sources de Cron4J depuis le dossier '''cron4j-original''' dans le dossier '''src/main/java''' de votre projet Maven
# Faites un essai de compilation:
#:<pre>mvn clean verify</pre>
# 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])
# 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.

==Tests Unitaires avec JUnit 4==
Survoller le tutoriel [http://www.vogella.com/tutorials/JUnit/article.html Unit Testing with JUnit]

# Ajouter le test unitaire suivant au projet, dans le fichier '''src/test/it/sauronsoftware/SchedulingPatternTest.java
<pre>
package it.sauronsoftware;

import it.sauronsoftware.cron4j.SchedulingPattern;
import it.sauronsoftware.cron4j.InvalidPatternException;

import static org.junit.Assert.assertEquals;
import static org.junit.Assert.assertTrue;

import org.junit.AfterClass;
import org.junit.BeforeClass;
import org.junit.Test;

public class SchedulingPatternTest {

@BeforeClass
public static void testSetup() {
}

@AfterClass
public static void testCleanup() {
// Teardown for data used by the unit tests
}

@Test(expected = InvalidPatternException.class)
public void testExceptionIsThrown() {
SchedulingPattern sp = new SchedulingPattern("0 5 * *");
}

@Test
public void testPattern() {
String pattern;
pattern="0 5 * * *|8 10 * * *|22 17 * * *";
assertTrue(pattern + "is correct", SchedulingPattern.validate(pattern));
pattern="0 5 * *";
assertTrue(pattern + "is correct", SchedulingPattern.validate(pattern));
}
}
</pre>

# Committez et Pushez ce nouveau fichier, pour que Travis lance les tests dès que possible
# Lancez les tests unitaires avec <pre>mvn test</pre> Ce test va '''échouer''': corrigez le.
# Committez et Pushez la version corrigée des tests: Travis enverra un mail pour indiquer si les tests échouent ou non
#: '''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.
# Naviguez sur http://travis-ci.org pour vérifier les builds effectués.
# Créez des tests unitaires supplémentaire du i.s.c.CronParser

===[[Maven]] avec [[Travis-CI]]===

===Git (suite)===

# Forkez le projet '''tagl''' d'un autre binome (i.e. autre que ''donsez/tagl'')
#: '''Attention:''' donnez lui un nom différent (e.g. ''tagl-licensing'')
# Clonez ce nouveau dépôt
# Lancez une compilation pour valider l'état du projet (bonne pratique)
#:<pre>mvn clean verify</pre>
# Ajoutez une bannière de licence dans le fichier '''cron4j-mvn/pom.xml'''
# Lancez une nouvelle compilation pour valider vos modifications
# Commitez et pushez (vers votre fork de ce dépôt, i.e. ''tagl-licensing'')
# Via le site de GitHub, proposez un "Pull Request" au projet initial

Vous pouvez ensuite supprimer le clone de ce fork.
Lorsque le ''pull request'' aura été accepté, vous pourrez supprimer votre fork (''tagl-licensing'') de votre compte GitHub.

===Contrôle Continu===

Dans votre dépôt ''tagl''.

# Ajoutez le plugin [http://mojo.codehaus.org/cobertura-maven-plugin/usage.html Cobertura] à votre projet Maven.
## 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''
## Le plugin ne s'exécute automatiquement pas durant la compilation, il faut utiliser la commande : <pre>mvn cobertura:cobertura</pre>
## '''Bonus:''' Modifiez le fichier ''pom.xml'' pour que le ''goal'' '''cobertura''' soit exécuté pendant la ''phase'' '''package'''.
# Répondez aux questions : ''Mais qu'est ce que la couverture de code ? En quoi c'est utile ?''
# 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.
# Regardez les exemples d'utilisation de cron4j dans cron4j-original/examples

===Bonus Track===

====Clone SVN -> Git====

Source: http://www.yterium.net/Migrer-un-projet-SVN-vers-GIT

<syntaxhighlight lang="bash">
# Cloner le dépôt SVN en dépôt Git (conservation historique)
$ git svn clone svn://svn.code.sf.net/p/cron4j/code/trunk cron4j-original
$ cd cron4j-original
# Test compilation
$ ant jar
$ cd ..
</syntaxhighlight>

====Préparation TAGL====

<syntaxhighlight lang="bash">
# Clone du dépôt TAGL
$ git clone git@github.com:donsez/tagl.git
$ cd tagl
# "Fetch" du dépôt local cloné précédemment
$ git fetch file://$(pwd)/../cron4j-original
# Fusion de ce qui vient d'être fetché
$ git merge FETCH_HEAD
# Envoi sur le serveur
$ git push
</syntaxhighlight>

====Cherry-picking: reprise des modifications d'un collègue====

On considère que:

* votre dépôt Git distant est à l'adresse URL_DEPOT
* votre collègue a un dépôt Git à l'adresse URL_COLLEGUE

<syntaxhighlight lang="bash">
# Dossier temporaire
cd /tmp

# Clone de votre dépôt
git clone URL_DEPOT mon_depot

# Déplacement dans votre dépôt
cd mon_depot

# Définition du dépôt distant
git remote add collegue URL_COLLEGUE

# Récupération des infos du dépôt du collègue
git fetch collegue

# Maintenant, on peut voir les branches du collègue
git branch -a

# On peut fusionner avec une branche
git merge collegue/master

# Si vous avez des conflits, éditez les fichiers concernés,
# et committez avec git commit

# Push vers votre dépôt distant
git push origin

# Optionnel: supprimez la référence vers le dépôt du collègue
git remote rm collegue
</syntaxhighlight>

====Archetype webapp====
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].

<syntaxhighlight lang="bash">
mvn -Djetty.port=9999 jetty:run
</syntaxhighlight>

Naviguez sur http://localhost:9999/monsite

====Scrum tools====
Ces 3 services peuvent être couplé à votre dépôt GitHub pour votre gestion de projet agile avec [[Scrum]] :
* http://www.acunote.com/
* http://backlogtool.com/
* http://www.scrumdo.com/

L'activation se fait via ''Settings > Webhooks & Services > Configure services''.

=Séance 4: AOP & AspectJ=

Dans votre dépôt Git, projet ''cron4j-mvn''.

# Ajoutez le [http://mojo.codehaus.org/aspectj-maven-plugin/ plugin Maven pour AspectJ] au pom.xml
# Ajoutez un aspect de trace à l'invocation des méthodes '''run()''' de l'interface java.lang.Runnable (uniquement pour les objets ''schedulé''s)
#: Affichez une trace avant et après l'exécution de la tâche
# 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 "* * * * *")
#: Lors de l'exécution de '''mvn test''', vous devez voir apparaître les traces préparées dans votre aspect.

Liens utiles:
* [http://ridgetopsolutions.com/blog/2013/02/12/getting-started-with-aspectj-and-maven/ Getting started with AspectJ and Maven]

===Contrôle continu===

# 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.

=Séance 5: Pelix & iPOPO=

Pelix est une plate-forme d'application à services (SOA).
iPOPO est un modèle de composants orientés services (SOCM).

La documentation de Pelix et iPOPO est disponible sur https://ipopo.coderxpress.net/

===Installation de iPOPO===

* Cloner le dépôt Git depuis https://github.com/tcalmant/ipopo
* Se placer dans la branche ''dev''
* Pour installer iPOPO, lancer la commande :

sudo python setup.py install

===Shell Pelix===

Pour lancer un shell Pelix, utilisez la commande:

python -m pelix.shell.console

Les commandes disponibles sont décrites ici: [https://ipopo.coderxpress.net/wiki/doku.php?id=ipopo:refcards:shell Shell Commands]

===Rappels de Python===

* Pas de déclaration du type d'une variable
* Les méthodes d'une classe ont toute comme premier paramètre ''self'', équivalent du ''this'' en Java.
* Blocs définis par indentation (4 espaces ou 1 tab)
* Une ligne finissant par ':' démarre toujours un bloc

<syntaxhighlight lang="python">
# Import d'un module
import pelix

# Définition d'une classe
class MaClasse:
# Constructeur
def __init__(self):
self.default = "stanger"
print("Classe construite")

# Méthode, avec un argument
def sayHello(self, name):
if not name:
# Nom vide ou nul
return "Hello, " + str(self.default)
else:
# Nom valide
return "Hello, " + str(name)

objet = MaClasse()
print(objet.sayHello(""))
print(objet.sayHello("World"))
</syntaxhighlight>

===Service Ping-Pong===

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:".

Exemple:

pong = Pong()
pong.pong("Hello") # <-- Retourne "PONG:Hello"

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:"

Exemple:

ping = Ping()
ping.ping("Hello") # <-- Retourne "PING:PONG:Hello"

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"
* Définir une classe ''Activator'', décorée avec ''@BundleActivator''
* Enregistrer le service dans la méthode ''Activator.start'' et le désenregistrer dans ''Activator.stop''
* S'inspirer du fichier "ipopo/samples/remote/provider.py"

Dans un shell Pelix, installer et démarrer le bundle 'pong' et vérifier que le service est bien inscrit avec la commande ''sl''

4.Transformer la classe ''Ping'' dans ''ping.py'' en un composant iPOPO
* L'objet Pong utilisé dans ''ping()'' doit être un service injecté par iPOPO (''@Requires'')
* Appeler la méthode ''ping()'' dès que le service Pong est injecté (''@BindField'') ou disparait (''@UnbindField'')
* S'inspirer du fichier "ipopo/samples/remote/consumer.py"

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é.

5. Mettre à jour le bundle ''pong''
* Remplacer le préfixe "PONG" par "NI"
* Dans le shell Pelix, mettre à jour le bundle ''pong'' sans redémarrer la plate-forme (commande ''udpate'').
* Vérifier les traces dans le shell pour valider la mise à jour du service.

===Remote Services===

* Ajouter les propriétés permettant l'export du service Pong dans ''pong.py'' (s'inspirer de ''provider.py'')

* Lancer deux shells iPOPO (dans deux terminaux)
* Dans chaque shell iPOPO, installer les bundles:
** ''pelix.remote.dispatcher'': Exportateur de services
** ''pelix.remote.registry''; Importateur de services
** ''pelix.remote.discovery.multicast'': Découverte de services via Multicast
** ''pelix.remote.xml_rpc'': Transport XML-RPC
** ''pelix.http.basic'': Serveur HTTP

Attention: il peut être nécessaire de désactiver votre pare-feu pour que les Remote Services fonctionnent

* Instancier les composants depuis le shell iPOPO, dans chaque framework:
** 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)
** Multicast Discovery: ''instantiate pelix-remote-discovery-multicast-factory multicast-discovery''
** XML-RPC Exporter: ''instantiate pelix-xmlrpc-exporter-factory xml-rpc-exporter''
** XML-RPC Importer: ''instantiate pelix-xmlrpc-exporter-factory xml-rpc-importer''

* Installer le bundle ''ping'' dans un des frameworks et le bundle ''pong'' dans l'autre.
* Le composant ping peut appeler le service pong, qui est dans l'autre framework.

* Voir le code de ''run_remote.py'' pour voir comment démarrer un framework Pelix et installer des bundles depuis Python.
* Jouer un peu avec ''run_remote.py'' (voir ''run_remote.py --help'')

=Séance 6=
[[Tutorial OSGi avec Apache Felix]]

=Séance 7=
Faire un projet PDE pour un bundle cron4j.gogo (indépendant de cron4j.bundle)

Utilisation de https://eclipse.org/tycho/

TAGL/TP

2015-02-17T09:38:57Z

MatthieuCaneill: /* GitHub & Travis-CI */

Travaux pratiques de l'UE [[TAGL]].

Anciennes versions : [[TAGL/TP 2014]]

=Séance 1 : Gestion de versions=
==Git==

Création d'un dépôt Git local

===Méthode simple: init first===

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".
Cette méthode est la plus simple, car on dispose immédiatement d'un répertoire de travail.

<syntaxhighlight lang="bash">
# Création d'un dépôt Git dans le dossier simple-repo
git init simple-repo

# Création d'un README
cd simple-repo
echo "Hello, World" > README

# Ajout du versionnement du fichier README
git add README

# Commit
git commit
</syntaxhighlight>

À ce niveau, on a un dépôt Git complètement fonctionnel.
Cependant, il est intéressant de pousser ses modifications vers un autre dépôt, sur une autre machine.
On va donc créer un dépôt bare sur une autre machine (ou autre dossier pour l'exemple)

<syntaxhighlight lang="bash">
git init --bare server-repo
</syntaxhighlight>

On considère que l'URL pour accéder à ce dépôt est URL_REPO.
On va d'abord ajouter ce dépôt serveur à la liste des dépôts connu-repos de votre dépôt local.
Étant donné qu'il s'agit du dépôt "principal" à utiliser, on l'appellera //origin//, par convention.

<syntaxhighlight lang="bash">
git remote add origin URL_REPO
# Récupération de ses informations
git fetch origin
</syntaxhighlight>

Ce serveur distant est "vide": il n'a aucune branche. On va donc enregistrer notre branche sur le serveur

<syntaxhighlight lang="bash">
git push origin master
</syntaxhighlight>

À partir de cette commande, la branche locale //master// sera liée à la branche distante //origin/master//.
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.

===Méthode moins simple: bare first===

Si on commence dans par le serveur "vide", il faudra le cloner au lieu de le définir comme un dépôt distant.

<syntaxhighlight lang="bash">
# Création du dépôt vide
git init --bare server-repo
</syntaxhighlight>

On considère que ce dépôt est accessible à l'URL URL_REPO

<syntaxhighlight lang="bash">
# Clonage du dépôt
git clone URL_REPO clone-repo
</syntaxhighlight>

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.
Le dépôt distant est automatiquement appelé //origin//.

<syntaxhighlight lang="bash">
# Commit dans le dépôt local
cd clone-repo
echo hello > readme.rst
git add readme.rst
git commit et ses dépendances
</syntaxhighlight>

Comme dans la méthode simple, il faut pousser la branche master vers le dépôt distant:

<syntaxhighlight lang="bash">
git push origin master
</syntaxhighlight>

===De l'importance des README===

Il est très important d'avoir au moins 2 fichiers dans votre dépôt Git:

* LICENSE: contenant le texte **complet** de la licence de votre projet
* README: décrivant votre projet et comment l'utiliser. Ce fichier doit rappeler le nom de la licence de votre projet

Il est aussi recommandé d'avoir les fichiers suivants:

* AUTHORS: contenant la liste des noms/pseudos et e-mails des auteurs de commits ou de code inclus dans ce projet
* INSTALL: contenant la liste des dépendances de ce projet et des commandes à utiliser pour le compiler et l'installer

Les fichiers LICENSE sont des fichiers textes bruts.
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)

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]

=Séance 2a: Intégration en continue=

===GitHub & [[Travis-CI]]===

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.
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.

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.

Pour utiliser [[Travis-CI]]:

# Créez compte individuel sur GitHub https://github.com
# ''Fork''ez le projet TAGL '''cron4j''' depuis https://github.com/donsez/tagl
# Ajoutez un collaborateur (i.e. votre binôme) au projet ''forké'', via les paramètres (''settings'') de ce projet
# 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.
# Activez le service Travis-CI: identifiez-vous (''sign in'') sur https://travis-ci.org/ avec votre compte GitHub
# Activez le service pour les projets sur lesquels vous souhaitez appliquer les principes d'intégration continue

[[Travis-CI]] utilise un fichier nommé '''.travis.yml''' (attention: fichier caché sous Unix) pour se configurer et choisir les opérations à effectuer.
Ce fichier doit se trouver à la racine de votre dépôt Git.

Faites un '''Commit''' puis un '''Push''' du fichier '''.travis.yml''' ci-dessous.

<pre>
language: node_js
node_js:
- "0.11"
- "0.10"
- "0.8"
- "0.6"
- iojs
- iojs-v1.0.2

script:
- pushd cron4j-original && ant rel && popd
</pre>

(voir http://docs.travis-ci.com/user/languages/javascript-with-nodejs/)

Ce fichier indique que le projet dans ce dépôt doit être testé sur plusieurs versions de [[Node.js]], et que le script à exécuter pour lancer les tests est '''pushd cron4j-original && ant rel && popd'''.
[[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').

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.

Une fois ce fichier de configuration '''pushé''', Travis-CI se mettra en route dès le prochain '''push'''.

=Séance 2b: Livraison en continue=

==[[Heruko]]==
[https://www.heroku.com/ Heruko] 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.

# Créez un compte gratuit sur [https://signup.heroku.com Heruko]
# Installez les lignes de commandes d'Heroku ([https://devcenter.heroku.com/articles/getting-started-with-nodejs#set-up Setup]).
# Ajoutez votre compte Heroku aux ''hooks'' de votre compte Github.
# Forkez le dépôt https://github.com/heroku/node-js-getting-started
# Modifiez le fichier index.js pour afficher la version de service dans la page HTML
<pre>
var fs = require('fs');
var package = JSON.parse(fs.readFileSync('./package.json', 'utf8'));
var version=package.version;
...
response.send('Hello World! (current version: '+version+')');
...
</pre>

'''Matthieu : à toi de rédiger, notamment le livraison automatique avec Travis-CI'''

=Séance 3: Builders=

==[[Ant]]==

==[[Maven]]==

[http://maven.apache.org/download.cgi Charger et installer Maven 3].

<pre>
mvn -version
</pre>

Faites une copie du projet, basée sur Maven:

# Dans votre dépôt Git, créez un dossier '''cron4j-mvn''': il contiendra le projet Cron4J avec la structure Maven
# 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):
#:<pre>mvn archetype:generate -DarchetypeGroupId=org.apache.maven.archetypes -DarchetypeArtifactId=maven-archetype-quickstart</pre>
# Cette commande crée un projet avec un fichier ''pom.xml'', et une classe et un test modèles: supprimez ces modèles
# Copiez les sources de Cron4J depuis le dossier '''cron4j-original''' dans le dossier '''src/main/java''' de votre projet Maven
# Faites un essai de compilation:
#:<pre>mvn clean verify</pre>
# 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])
# 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.

==Tests Unitaires avec JUnit 4==
Survoller le tutoriel [http://www.vogella.com/tutorials/JUnit/article.html Unit Testing with JUnit]

# Ajouter le test unitaire suivant au projet, dans le fichier '''src/test/it/sauronsoftware/SchedulingPatternTest.java
<pre>
package it.sauronsoftware;

import it.sauronsoftware.cron4j.SchedulingPattern;
import it.sauronsoftware.cron4j.InvalidPatternException;

import static org.junit.Assert.assertEquals;
import static org.junit.Assert.assertTrue;

import org.junit.AfterClass;
import org.junit.BeforeClass;
import org.junit.Test;

public class SchedulingPatternTest {

@BeforeClass
public static void testSetup() {
}

@AfterClass
public static void testCleanup() {
// Teardown for data used by the unit tests
}

@Test(expected = InvalidPatternException.class)
public void testExceptionIsThrown() {
SchedulingPattern sp = new SchedulingPattern("0 5 * *");
}

@Test
public void testPattern() {
String pattern;
pattern="0 5 * * *|8 10 * * *|22 17 * * *";
assertTrue(pattern + "is correct", SchedulingPattern.validate(pattern));
pattern="0 5 * *";
assertTrue(pattern + "is correct", SchedulingPattern.validate(pattern));
}
}
</pre>

# Committez et Pushez ce nouveau fichier, pour que Travis lance les tests dès que possible
# Lancez les tests unitaires avec <pre>mvn test</pre> Ce test va '''échouer''': corrigez le.
# Committez et Pushez la version corrigée des tests: Travis enverra un mail pour indiquer si les tests échouent ou non
#: '''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.
# Naviguez sur http://travis-ci.org pour vérifier les builds effectués.
# Créez des tests unitaires supplémentaire du i.s.c.CronParser

===[[Maven]] avec [[Travis-CI]]===

===Git (suite)===

# Forkez le projet '''tagl''' d'un autre binome (i.e. autre que ''donsez/tagl'')
#: '''Attention:''' donnez lui un nom différent (e.g. ''tagl-licensing'')
# Clonez ce nouveau dépôt
# Lancez une compilation pour valider l'état du projet (bonne pratique)
#:<pre>mvn clean verify</pre>
# Ajoutez une bannière de licence dans le fichier '''cron4j-mvn/pom.xml'''
# Lancez une nouvelle compilation pour valider vos modifications
# Commitez et pushez (vers votre fork de ce dépôt, i.e. ''tagl-licensing'')
# Via le site de GitHub, proposez un "Pull Request" au projet initial

Vous pouvez ensuite supprimer le clone de ce fork.
Lorsque le ''pull request'' aura été accepté, vous pourrez supprimer votre fork (''tagl-licensing'') de votre compte GitHub.

===Contrôle Continu===

Dans votre dépôt ''tagl''.

# Ajoutez le plugin [http://mojo.codehaus.org/cobertura-maven-plugin/usage.html Cobertura] à votre projet Maven.
## 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''
## Le plugin ne s'exécute automatiquement pas durant la compilation, il faut utiliser la commande : <pre>mvn cobertura:cobertura</pre>
## '''Bonus:''' Modifiez le fichier ''pom.xml'' pour que le ''goal'' '''cobertura''' soit exécuté pendant la ''phase'' '''package'''.
# Répondez aux questions : ''Mais qu'est ce que la couverture de code ? En quoi c'est utile ?''
# 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.
# Regardez les exemples d'utilisation de cron4j dans cron4j-original/examples

===Bonus Track===

====Clone SVN -> Git====

Source: http://www.yterium.net/Migrer-un-projet-SVN-vers-GIT

<syntaxhighlight lang="bash">
# Cloner le dépôt SVN en dépôt Git (conservation historique)
$ git svn clone svn://svn.code.sf.net/p/cron4j/code/trunk cron4j-original
$ cd cron4j-original
# Test compilation
$ ant jar
$ cd ..
</syntaxhighlight>

====Préparation TAGL====

<syntaxhighlight lang="bash">
# Clone du dépôt TAGL
$ git clone git@github.com:donsez/tagl.git
$ cd tagl
# "Fetch" du dépôt local cloné précédemment
$ git fetch file://$(pwd)/../cron4j-original
# Fusion de ce qui vient d'être fetché
$ git merge FETCH_HEAD
# Envoi sur le serveur
$ git push
</syntaxhighlight>

====Cherry-picking: reprise des modifications d'un collègue====

On considère que:

* votre dépôt Git distant est à l'adresse URL_DEPOT
* votre collègue a un dépôt Git à l'adresse URL_COLLEGUE

<syntaxhighlight lang="bash">
# Dossier temporaire
cd /tmp

# Clone de votre dépôt
git clone URL_DEPOT mon_depot

# Déplacement dans votre dépôt
cd mon_depot

# Définition du dépôt distant
git remote add collegue URL_COLLEGUE

# Récupération des infos du dépôt du collègue
git fetch collegue

# Maintenant, on peut voir les branches du collègue
git branch -a

# On peut fusionner avec une branche
git merge collegue/master

# Si vous avez des conflits, éditez les fichiers concernés,
# et committez avec git commit

# Push vers votre dépôt distant
git push origin

# Optionnel: supprimez la référence vers le dépôt du collègue
git remote rm collegue
</syntaxhighlight>

====Archetype webapp====
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].

<syntaxhighlight lang="bash">
mvn -Djetty.port=9999 jetty:run
</syntaxhighlight>

Naviguez sur http://localhost:9999/monsite

====Scrum tools====
Ces 3 services peuvent être couplé à votre dépôt GitHub pour votre gestion de projet agile avec [[Scrum]] :
* http://www.acunote.com/
* http://backlogtool.com/
* http://www.scrumdo.com/

L'activation se fait via ''Settings > Webhooks & Services > Configure services''.

=Séance 4: AOP & AspectJ=

Dans votre dépôt Git, projet ''cron4j-mvn''.

# Ajoutez le [http://mojo.codehaus.org/aspectj-maven-plugin/ plugin Maven pour AspectJ] au pom.xml
# Ajoutez un aspect de trace à l'invocation des méthodes '''run()''' de l'interface java.lang.Runnable (uniquement pour les objets ''schedulé''s)
#: Affichez une trace avant et après l'exécution de la tâche
# 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 "* * * * *")
#: Lors de l'exécution de '''mvn test''', vous devez voir apparaître les traces préparées dans votre aspect.

Liens utiles:
* [http://ridgetopsolutions.com/blog/2013/02/12/getting-started-with-aspectj-and-maven/ Getting started with AspectJ and Maven]

===Contrôle continu===

# 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.

=Séance 5: Pelix & iPOPO=

Pelix est une plate-forme d'application à services (SOA).
iPOPO est un modèle de composants orientés services (SOCM).

La documentation de Pelix et iPOPO est disponible sur https://ipopo.coderxpress.net/

===Installation de iPOPO===

* Cloner le dépôt Git depuis https://github.com/tcalmant/ipopo
* Se placer dans la branche ''dev''
* Pour installer iPOPO, lancer la commande :

sudo python setup.py install

===Shell Pelix===

Pour lancer un shell Pelix, utilisez la commande:

python -m pelix.shell.console

Les commandes disponibles sont décrites ici: [https://ipopo.coderxpress.net/wiki/doku.php?id=ipopo:refcards:shell Shell Commands]

===Rappels de Python===

* Pas de déclaration du type d'une variable
* Les méthodes d'une classe ont toute comme premier paramètre ''self'', équivalent du ''this'' en Java.
* Blocs définis par indentation (4 espaces ou 1 tab)
* Une ligne finissant par ':' démarre toujours un bloc

<syntaxhighlight lang="python">
# Import d'un module
import pelix

# Définition d'une classe
class MaClasse:
# Constructeur
def __init__(self):
self.default = "stanger"
print("Classe construite")

# Méthode, avec un argument
def sayHello(self, name):
if not name:
# Nom vide ou nul
return "Hello, " + str(self.default)
else:
# Nom valide
return "Hello, " + str(name)

objet = MaClasse()
print(objet.sayHello(""))
print(objet.sayHello("World"))
</syntaxhighlight>

===Service Ping-Pong===

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:".

Exemple:

pong = Pong()
pong.pong("Hello") # <-- Retourne "PONG:Hello"

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:"

Exemple:

ping = Ping()
ping.ping("Hello") # <-- Retourne "PING:PONG:Hello"

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"
* Définir une classe ''Activator'', décorée avec ''@BundleActivator''
* Enregistrer le service dans la méthode ''Activator.start'' et le désenregistrer dans ''Activator.stop''
* S'inspirer du fichier "ipopo/samples/remote/provider.py"

Dans un shell Pelix, installer et démarrer le bundle 'pong' et vérifier que le service est bien inscrit avec la commande ''sl''

4.Transformer la classe ''Ping'' dans ''ping.py'' en un composant iPOPO
* L'objet Pong utilisé dans ''ping()'' doit être un service injecté par iPOPO (''@Requires'')
* Appeler la méthode ''ping()'' dès que le service Pong est injecté (''@BindField'') ou disparait (''@UnbindField'')
* S'inspirer du fichier "ipopo/samples/remote/consumer.py"

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é.

5. Mettre à jour le bundle ''pong''
* Remplacer le préfixe "PONG" par "NI"
* Dans le shell Pelix, mettre à jour le bundle ''pong'' sans redémarrer la plate-forme (commande ''udpate'').
* Vérifier les traces dans le shell pour valider la mise à jour du service.

===Remote Services===

* Ajouter les propriétés permettant l'export du service Pong dans ''pong.py'' (s'inspirer de ''provider.py'')

* Lancer deux shells iPOPO (dans deux terminaux)
* Dans chaque shell iPOPO, installer les bundles:
** ''pelix.remote.dispatcher'': Exportateur de services
** ''pelix.remote.registry''; Importateur de services
** ''pelix.remote.discovery.multicast'': Découverte de services via Multicast
** ''pelix.remote.xml_rpc'': Transport XML-RPC
** ''pelix.http.basic'': Serveur HTTP

Attention: il peut être nécessaire de désactiver votre pare-feu pour que les Remote Services fonctionnent

* Instancier les composants depuis le shell iPOPO, dans chaque framework:
** 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)
** Multicast Discovery: ''instantiate pelix-remote-discovery-multicast-factory multicast-discovery''
** XML-RPC Exporter: ''instantiate pelix-xmlrpc-exporter-factory xml-rpc-exporter''
** XML-RPC Importer: ''instantiate pelix-xmlrpc-exporter-factory xml-rpc-importer''

* Installer le bundle ''ping'' dans un des frameworks et le bundle ''pong'' dans l'autre.
* Le composant ping peut appeler le service pong, qui est dans l'autre framework.

* Voir le code de ''run_remote.py'' pour voir comment démarrer un framework Pelix et installer des bundles depuis Python.
* Jouer un peu avec ''run_remote.py'' (voir ''run_remote.py --help'')

=Séance 6=
[[Tutorial OSGi avec Apache Felix]]

=Séance 7=
Faire un projet PDE pour un bundle cron4j.gogo (indépendant de cron4j.bundle)

Utilisation de https://eclipse.org/tycho/