TAGL/TP

Travaux pratiques de l'UE TAGL.

Séance 1

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.

# 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

À 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)

git init --bare server-repo

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.

git remote add origin URL_REPO
# Récupération de ses informations
git fetch origin

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

git push origin master

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

# Création du dépôt vide
git init --bare server-repo

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

# Clonage du dépôt
git clone URL_REPO clone-repo

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

# Commit dans le dépôt local
cd clone-repo
echo hello > readme.rst
git add readme.rst
git commit et ses dépendances

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

git push origin master

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 Markdown (.md) ou reStructuredText (.rst)

Un plug-in existe pour éditer des fichier reStructuredText dans Eclipse: ReST Editor, disponible sur le Marketplace Eclipse

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:

1. Créez compte individuel sur GitHub https://github.com
2. Forkez le projet TAGL cron4j depuis https://github.com/donsez/tagl
3. Ajoutez un collaborateur (i.e. votre binôme) au projet forké, via les paramètres (settings) de ce projet
4. 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.
5. Activez le service Travis-CI: identifiez-vous (sign in) sur https://travis-ci.org/ avec votre compte GitHub
6. 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.

language: java

jdk:
        - oraclejdk7
        - openjdk6
        - openjdk7

script:
        - pushd cron4j-original && ant rel && popd

Ce fichier indique que le projet dans ce dépôt doit être testé sur 3 versions de Java (Oracle Java 7, Open JDK 6 et Open JDK 7), et que le script à exécuter pour lancer les tests est pushd cron4j-original && ant rel && popd. 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.

Maven

Charger et installer Maven 3.

mvn -version

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

1. Dans votre dépôt Git, créez un dossier cron4j-mvn: il contiendra le projet Cron4J avec la structure Maven
2. Dans ce dossier, utilisez l'archetype Maven maven-archetype-quickstart (la version des sources de cron4j utilisés est la 2.5.5):

   mvn archetype:generate -DarchetypeGroupId=org.apache.maven.archetypes -DarchetypeArtifactId=maven-archetype-quickstart

3. Cette commande crée un projet avec un fichier pom.xml, et une classe et un test modèles: supprimez ces modèles
4. Copiez les sources de Cron4J depuis le dossier cron4j-original dans le dossier src/main/java de votre projet Maven
5. Faites un essai de compilation:

   mvn clean verify

6. 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 Unit Testing with JUnit

1. Ajouter le test unitaire suivant au projet, dans le fichier src/test/it/sauronsoftware/SchedulingPatternTest.java

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));
  }
}

1. Committez et Pushez ce nouveau fichier, pour que Travis lance les tests dès que possible
2. Lancez les tests unitaires avec

   mvn test

   Ce test va échouer: corrigez le.
3. 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.

4. Naviguez sur http://travis-ci.org pour vérifier les builds effectués.
5. Créez des tests unitaires supplémentaire du i.s.c.CronParser

Git (suite)

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

2. Clonez ce nouveau dépôt
3. Lancez une compilation pour valider l'état du projet (bonne pratique)

   mvn clean verify

4. Ajoutez une bannière de licence dans le fichier cron4j-mvn/pom.xml
5. Lancez une nouvelle compilation pour valider vos modifications
6. Commitez et pushez (vers votre fork de ce dépôt, i.e. tagl-licensing)
7. 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.

1. Ajoutez le plugin Cobertura à votre projet Maven.
2. Répondez aux questions : Mais qu'est ce que la couverture de code ? En quoi c'est utile ?
3. 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.
4. 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

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

Préparation TAGL

# 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

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

# 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

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 plugin maven Jetty.

mvn -Djetty.port=9999 jetty:run

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 2

AOP & AspectJ

Ajouter le plugin Maven pour AspectJ au pom.xml

Ajouter un aspect de trace à l'invocation des méthodes run() de l'interface java.lang.Runnable (uniquement pour les objets schedulés).

Contrôle continu

Compléter l'aspect de trace avec le positionnement du 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 3

@WIP

Injection de dépendances avec Guice

Séance 4

Tutorial OSGi avec Apache Felix

Séance 5

Faire un projet PDE pour un bundle cron4j.gogo (indépendant de cron4j.bundle)

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