TAGL/TP: Difference between revisions
(→Git) |
|||
Line 3: | Line 3: | ||
==Séance 1== |
==Séance 1== |
||
===Git=== |
===Git=== |
||
Création d'un dépôt Git local |
|||
<pre> |
|||
mkdir tagl |
|||
====Méthode simple: init first==== |
|||
cd tagl |
|||
mkdir testgit |
|||
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". |
|||
cd testgit |
|||
Cette méthode est la plus simple, car on dispose immédiatement d'un répertoire de travail. |
|||
⚫ | |||
cd .. |
|||
<syntaxhighlight lang="bash"> |
|||
git clone testgit testgit-work |
|||
# Création d'un dépôt Git dans le dossier simple-repo |
|||
cd testgit-work |
|||
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"> |
|||
⚫ | |||
</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 |
echo hello > readme.rst |
||
git add readme.rst |
git add readme.rst |
||
git commit |
git commit |
||
</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 |
git push origin master |
||
</syntaxhighlight> |
|||
</pre> |
|||
En parallèle : Installer dans votre Eclipse le plugin ReST Editor depuis le [https://marketplace.eclipse.org/content/rest-editor Marketplace Eclipse] |
En parallèle : Installer dans votre Eclipse le plugin ReST Editor depuis le [https://marketplace.eclipse.org/content/rest-editor Marketplace Eclipse] |
Revision as of 11:19, 19 February 2014
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
Comme dans la méthode simple, il faut pousser la branche master vers le dépôt distant:
git push origin master
En parallèle : Installer dans votre Eclipse le plugin ReST Editor depuis le Marketplace Eclipse
GitHub & Travis-CI
Créer compte individuel sur GitHub https://github.com
Forker le projet TAGL cron4j depuis https://github.com/donsez/tagl
Ajouter un collaborateur (ie votre binome) au projet forké
Activer le Email hook depuis les paramètres (settings) du dépôt.
Activer le Travis-CI hook' depuis https://travis-ci.org/ (sign in avec le compte GitHub)
Commit/Push .travis.yml pour Ant:
language: java jdk: - oraclejdk7 - openjdk6 - openjdk7 script: - pushd cron4j-original && ant rel && popd
Maven
mvn -version
Créer cron4j-mvn (layout + pom.xml) en réorganisant les sources de cron4j-original. Pour cela, vous utiliserez préalablement un archetype Maven simple ou quickstart. (la version de cron4j est la 2.5.5).
Modifier .travis.yml pour mvn -DskipTests=true clean install (Commit/Push)
Tests Unitaires avec JUnit 4
Survoller le tutoriel Unit Testing with JUnit
Ajouter le test unitaire suivant au layout du projet
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)); } }
Rechercher la dépendance JUnit 4 dans Maven Central
Ajouter la dépendance JUnit 4 au pom.xml
Lancer le build mvn test
Modifier .travis.yml pour mvn clean test (Commit/Push)
Regarder votre mail box.
Naviguer sur http://travis-ci.org pour vérifier les builds effectués.
Créer des tests unitaires du i.s.c.CronParser
Git (suite)
- Forker le projet cron4j-mvn d'un autre binome (ie l'origine)
- Ajouter une bannière de licence dans le pom.xml
- Lancer mvn clean install (bonne pratique)
- Commiter
- Faire un Push request vers l'origine
Contrôle Continu
Ajoutez au pom.xml le plugin Covertura pour la couverture de code.
Répondez aux questions : Mais qu'est ce que la couverture de code ? En quoi c'est utile ?
Ajoutez au pom.xml les plugins pour la gestion du site et des rapports (Javadoc, tests unitaires, tags list (FIXME, TODO, ...), ...): http://maven.apache.org/plugins/maven-site-plugin/ et d'autres.
Pour la prochaine séance, 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 :
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/