Réalisé par: Lakhdhar yessin Letaief Sana Ant,XDoclet,CVS Réalisé par: Lakhdhar yessin Letaief Sana

Contenu : ANT XDoclet CVS

ANT,XDoclet,CVS ANT (Another Neat Tool)

Plan Qu’est ce que ANT ? Purquoi ANT ? Comment ça marche ? Demo…

Qu’est ce que Ant? Un projet de l’ Apache Software Foundation. A l’origine,un sous-projet de l’Apache Jakarta Project. Un outil de construction d’application écrit en Java. Permet d’automatiser le processus de construction des projets.

Un processus de construction Récupérer des sources Génération , à partir de sources, de différents types de fichiers Compilation Problèmes: -Tâches répétitives -Perte de temps -Grands Projets -Complexité croissante, risques d'oubli Nécessité d’automatisation,d’un outil. Test Réorganisations de fichiers Déploiement Création de la documentation

Pourquoi Ant? Des outils existent: make , gnumake, nmake, jam…. Problème : Ces outils sont basés sur des scripts Shell dépendants du Système d’exploitation. Solution : ANT qui est : - Indépendant du Système d’exploitation. - Accepte des instructions sous la forme d’un document XML ce qui le rend extensible et facile à mettre à jour. - Open Source.

Comment ça marche ?

Build.xml <?xml version=" 1.0 "?> <project name=" test " default=" compile " basedir=" . "> <property name=" src " value " . "/> <property name=" build " value =" build "/> <target name=" init "> <mkdir dir=" ${build} "/> </target> <target name="compile " depend=" init "> <!-- compile the java code --> <javac srcdir=" ${src} " destdir="${build} "/> </target> </project>

<project name=" test " default=" compile " basedir=" . "> Elément principal, composé de 3 attributs: - name : nom du projet - default : étape de construction par défaut - basedir : dossier racine (sinon le dossier du build.xml) Il contient : -Principalement : un ensemble de balises <target> -Optionnellement : <desciption>…

Build.xml <?xml version=" 1.0 "?> <project name=" test" default=" compile " basedir=" . "> <property name=" src " value ". "/> <property name=" build " value =" build "/> <target name=" init "> <mkdir dir=" ${build} "/> </target> <target name="compile " depend=" init "> <!-- compile the java code --> <javac srcdir=" ${src} " destdi="${build} "/> </target> </project>

<property> ≈ variables <property name=« build » value =« build »/> - Name : nom de la propriété - Value : valeur de la propriété Le référencement d’une propriété se fait comme suit : ${nom_propriété} Permet l’accès à : - Des propriétés systèmes : Ant permet l’accès à toutes les propriétés système comme si prédéfinies avec <property>, Exemple : ${os.name}. -Des Propriétés prédéfinies : - basedir : chemin absolu du répertoire de travail (sinon le dossier du build.xml) - ant.file : chemin absolu du fichier build, - ant.project.name : le nom du projet courant (initialisé comme attribut dans<project>)…

Build.xml <?xml version=" 1.0 "?> <project name=" test " default=" compile " basedir=" . "> <property name=" src " value ". "/> <property name=" build " value =" build "/> <target name=" init "> <mkdir dir=" ${build} "/> </target> <target name="compile " depend=" init "> <!-- compile the java code --> <javac srcdir=" ${src}" destdir="${build}"/> </target> </project>

<target name=«compile » depends=« init »> Définit une séquence de tâches à exécuter et possède : 1) un attribut obligatoire -name: nom qui permet son référencement 2) des attributs optionnels: - depends :liste des étapes de construction dont dépends la séquence en question  doivent être exécutées en premier - if, unless :permet de conditionner l'exécution par l'existence d'une propriété Exemple : <target name="A"/> <target name="C" depends="B"/> <target name="B" depends="A"/> <target name="D" depends="C,B,A"/>

Build.xml Deux tâches (Tasks) <?xml version=" 1.0 "?> <project name=" test " default=" compile " basedir=" . "> <property name=" src " value ". "/> <property name=" build " value =" build "/> Deux tâches (Tasks) <target name=" init "> <mkdir dir=" ${build} "/> </target> <target name="compile " depend=" init "> <!-- compile the java code --> <javac srcdir=" ${src} " destdir="${build} "/> </target> </project>

Les Tasks Une tâche est une unité de traitements contenue dans une classe Java qui implémente l'interface org.apache.ant.Task Une tâche est obligatoirement incluse dans une cible. Représente le body des <targets> du code exécutable. Peuvent utiliser des références à des propriétés. Forme générale: <name attribute1="value1" attribute2="value2" ... /> Ant fournit en standard un certain nombre de tâches pour des traitements courants lors du développement en Java.

Quelques catégories de tâches : Archives Tasks Compile Tasks DeployC Tasks Documentation Tasks EJB Tasks Exécution Tasks SCM Tasks … jar : Créer une archive de type jar ear : Créer une archive contenant une application J2EE Gzip : Compresser dans une archive

Quelques catégories de tâches : Archives Tasks Compile Tasks Deployement Tasks Documentation Tasks EJB Tasks Exécution Tasks SCM Tasks … Javac : Compiler des sources Java JspC : Démarre le compilateur JSP.

Quelques catégories de tâches : Archives Tasks Compile Tasks Deployement Tasks Documentation Tasks EJB Tasks Exécution Tasks SCM Tasks … ServerDeploy : tâche pour démarrer le "hot" de l’outil de déploiement pour vendor-specific J2EE server.

Quelques catégories de tâches : Archives Tasks Compile Tasks Deployement Tasks Documentation Tasks EJB Tasks Exécution Tasks SCM Tasks … Javadoc : Génération de la documentation en utilisant l’outil javadoc Stylebook : Execute l’Apache Stylebook documentation generator

Quelques catégories de tâches : Archives Tasks Compile Tasks Deployement Tasks Documentation Tasks EJB Tasks Exécution Tasks SCM Tasks … ejbc : démarrer l’outil Weblogic's ejbc wlrun: démarre une instance weblogic wlstop: arrete une instance weblogic

Quelques catégories de tâches : Archives Tasks Compile Tasks Deployement Tasks Documentation Tasks EJB Tasks Exécution Tasks SCM Tasks … Ant : démarre Ant sur un fichier spécifié Exec : Exécute une commande système Sleep : suspendre l’exécution pour une période donnée

Quelques catégories de tâches : Archives Tasks Compile Tasks Deployement Tasks Documentation Tasks EJB Tasks Exécution Tasks SCM Tasks … Cvs : Gérer packages/modules récuCés à partir du répertoire référence (repository) CVS. CvsTagDiff : Générer une fichier XML montrant les changements entre deux tags ou dates enregistrés dans le CVS repository.

Quelques catégories de tâches : Archives Tasks Compile Tasks Deployement Tasks Documentation Tasks EJB Tasks Exécution Tasks SCM Tasks … Il reste encore une multitude de tâches(.NET Tasks, Mail Tasks, …) et la possibilité de créer ses propres tâches.

Integration dans les IDE : Eclipse WebSphere Studio Application Developer JBuilder 8 Enterprise Oracle9i JDeveloper NetBeans / Sun ONE Studio

Demo  Création de Task  Compilation,Packagin,Déploiement d’une application J2EE

ANT,XDoclet,CVS XDoclet

Plan : Présentation Caractéristiques Comment ça marche Récapitulatif Tasks Subtask XDoclet & ANT Pattern de génération de code Templates Récapitulatif Démo

Présentation: Xdoclet est un moteur de génération de code orienté attribut (repose sur des commentaires javadoc) . Conçu à l'origine comme un outil de création d'EJBs, il a évolué en un moteur de génération de code générique. Actuellement, XDoclet ne peut être utilisé que comme une étape de construction de programme (build process) en utilisant Jakarta Ant .

Présentation(2) : Quand est ce que XDoclet est utlisé ? Fichiers de déploiement de configuration Systèmes construits autour de composantes métier Systèmes multi tiers Systèmes Orientés Interfaces

Présentation(3) : Source : Test-Driven Developmentwith Spring and Hibernate,Matt Raible

Caractéristiques de XDoclet : Permet de se focaliser sur un seul fichier par composant Facilite la mise à jour des fichiers Evite le travail répétitif Amélioration de la productivité Optimisation de l’intégration Continue  XDoclet reconnaît une multitude de patterns J2EE largement reconnus Ex : Composant EJB  interfaces, value objects, struts forms.  Supporte les Serveurs et les outils les + répandus JBoss, BEA WebLogic, IBM WebSphere, Oracle IAS, Orion, Jonas,etc…  Extensible  Open Source

Comment ça marche? XDoclet permet le développement Orienté Attribut  basé sur des commantaires JavaDoc spécifiques. Une balise JavaDoc se présente sous la forme : /** * @author C.TOWN **/ De même un tag spécifique XDoclet se présente sous la forme : /** * @namespace:tag_name name="value" name2="value2" ... */

@namespace:tag_name name="value" name2="value2" ... Les namespaces : @namespace:tag_name name="value" name2="value2" ... namespace : représente un groupe de tags logiquement reliés (garantit l’absence de conflits de noms) voici quelques exemples d’espaces de noms : ejb : informations standard sur les EJB (non spécifiques). jboss ,Weblogic,webSphere: informations spécifiques au serveur d'application . soap : génère les decripteurs SOAP. struts : génère les fichiers struts-config.xml à partir de Form et Action. web : génère le fichier de configuration web.xml pour les Web Applications. ... Balises avec un nom et un jeu d’attributs optionnels  Concept similaire à celui de l’XML mais avec une syntaxe différente.

Exemple : MetaData XDoclet placée en commentaire pour la classe Les MetaData peuvent aussi être spécifiées pour une méthode

Exemple :  Comment sont générés les fichiers ? Exemple de tags pour le déploiement d’un bean entité élémentaire:  Comment sont générés les fichiers ?

Les tasks XDcolet : On utilise XDoclet pour générer du code , MAIS il est plus correcte de dire qu’on utilise des tasks XDoclet pour générer du code. Un task, ou une tâche est une application de génération de code de haut niveau. Les 7 tasks XDoclet de base: <ejbdoclet> : EJBs, Descripteurs de déploiements,… <webdoclet> : Développement Web,servets,taglibs,web frameworks <hibernatedoclet> : Configuration de Persistance Hibernate , MBeans… <jdodoclet> : JDO-metadata <jmxdoclet> : JMX-interfaces MBean, mlets, fichiers de configuration <doclet> : JDO-MetaData <documentdoclet> : Documentation de projet ,comme les listes TODO

Les subtasks XDcolet :  Comment est lancée la génération ? Une subtask est une procédure de génération de code élémentaire,fournis par un task.  le task fournit un contexte ou un groupement qui gère des subtasks plus ou moins « proches ». Exemple: Task : <ejbdoclet> : Subtasks: <deploymentdescriptor>  Génération du descripteur de déploiement <localinterface>  Génération d’interface locale …  Comment est lancée la génération ?

XDcolet et ANT (1): Les tasks XDoclet sont des tasks ou tâches de construction ANT. Pour récapituler :

XDcolet et ANT (2): <taskdef classpathref="xdoclet.classpath" <target name="Web_Module" description="Web"> <taskdef classpathref="xdoclet.classpath" classname="xdoclet.modules.web.WebDocletTask" name="webdoclet" /> <webdoclet destDir="src" verbose="true"> <fileset dir="src" includes="**/*Servlet.java"> </fileset> <deploymentdescriptor Servletspec="2.3" destDir="src/WEB-INF"> </deploymentdescriptor> <jbosswebxml Version="4.0" destDir="src/WEB-INF"> </jbosswebxml> </webdoclet> </target> Définition d’un task  <webdoclet>

XDcolet et ANT (2): task <taskdef classpathref="xdoclet.classpath" <target name="Web_Module" description="Web"> <taskdef classpathref="xdoclet.classpath" classname="xdoclet.modules.web.WebDocletTask" name="webdoclet" /> <webdoclet destDir="src" verbose="true"> <fileset dir="src" includes="**/*Servlet.java"> </fileset> <deploymentdescriptor Servletspec="2.3" destDir="src/WEB-INF"> </deploymentdescriptor> <jbosswebxml Version="4.0" destDir="src/WEB-INF"> </jbosswebxml> </webdoclet> </target> Définition d’un task  <webdoclet> task

XDcolet et ANT (2): task <taskdef classpathref="xdoclet.classpath" <target name="Web_Module" description="Web"> <taskdef classpathref="xdoclet.classpath" classname="xdoclet.modules.web.WebDocletTask" name="webdoclet" /> <webdoclet destDir="src" verbose="true"> <fileset dir="src" includes="**/*Servlet.java"> </fileset> <deploymentdescriptor Servletspec="2.3" destDir="src/WEB-INF"> </deploymentdescriptor> <jbosswebxml Version="4.0" destDir="src/WEB-INF"> </jbosswebxml> </webdoclet> </target> Définition d’un task  <webdoclet> subtask task subtask

Pattern de génération de code :  Comment est ce que les subtasks génèrent du code?

Le Template : Le template est une version prototype du fichier qu’on veut générer. Utilise les tags XML qui précisent au moteur template comment ajuster le codé généré en se basant sur : les classes en entrée les metadata qu’elles contiennent (balises javadoc et tag XDoclet). Ces tag se présentent selon deux types différents : <XDtClass : …> <XDtMethod : …>

Les tag : Recherche : <XDtClass:ifHasClassTag tagName=“NomTag"> Utilisation : <XDtClass:classTagValue tagName=" NomTag " /> Recherche : <XDtMethod:ifHasMethodTag tagName=" NomTag "> Utilisation : <XDtMethod:methodTagValue tagName=" NomTag " />

Exemple: fichier « .xdt »

Récapitulation: Pour générer du code avec XDoclet on doit : Si on n’utilise pas les modules déjà développés pour XDoclet, créer son propre template de déploiement .xdt Commenter son code avec les balises Javadoc spécifiques XDoclet. Créer un fichier de déploiement build.xml pour Ant intégrant des demandes de génération de code XDoclet. Lancer Ant sur le fichier build.xml => les fichiers désirés sont générés.

Demo …

ANT,XDoclet,CVS CVS (Concurrent Version System)

Plan : Présentation de CVS Logique de fonctionnement Étapes de travail avec CVS (commandes) Quelques clients CVS

Présentation de CVS CVS (Concurrent Version System) est un système de contrôle de versions de fichiers. Développé par Cyclic Software et est sous licence GNU. Initialement développé pour Unix, disponible aussi sur MS Windows®

Qualités de CVS : ► Aide à gérer le développement d’un projet effectué en parallèle par plusieurs utilisateurs :  Permet Accès concurrentiel par plusieurs développeurs à un même projet. ► Identifie les changements et les zones de conflit pour lesquelles un arbitrage humain est requis :  Visualisation des différences qui sont sources de conflits. ► Conserve la trace des modifications successives effectuées sur les projets :  Archivage et Suivi de l’historique  Possibilité de retour à des versions anciennes

Logique de fonctionnement : Des outils existent: - RCS (Revisions Control System) - SCCS (Source Code Control)  Modèle: Lock-Modify-Unlock ( Contrôle par verrouillage) - CVSS,Subversion, Méta-CVS… Apparition de CVS :  Modèle : Copy-Modify-Merge. Copy-Modify-Merge ?

Copy-Modify-Merge ? CVS enregistre les projets dans un référentiel principal appelé Repository. L’utilisateur effectue une copie du projet dans le référentiel, puis la modifie. L’utilisateur effectue une synchronisation avec le référentiel pour voir s’il n’y a pas eu entre temps une modification du référentiel. CVS gère la nouvelle version en résolvant un certain nombre de conflits et crée un historique des versions.

Dépôt et copie de version : user1 user2 user3 Dépôt de projet(s) Standbox Standbox Référentiel Copie de projet(s) Standbox

Étapes de travail avec CVS : Définition d’un référentiel : variable d’environnement Ajout de(s) utilisateur(s) Connexion à un projet Copie du référentiel Update Commit

Définition d’un référentiel : L’ajout de la variable d’environnement se fait grâce à la commande suivante : set CVSROOT = c:\Dev_CVS\cvsrep

Ajouter de(s) utilisateur(s) : L’ajout d’un nouvel utilisateur se fait comme suit : cvs passwd –r <utilisateur> -a <password> Exemple : cvs passwd –r <user1> -a <my_pass>

Connexion au référentiel : Pour pointer sur un projet, l’utilisateur se connecte au référentiel en utilisant la commande : set cvsroot=:<protocole>:<utilisateur>@<hôte>:/CheminProjet Exemple : set cvsroot=:<pserver>:<utilisateur>@<hôte>:/CheminProjet Protocole pserver : se connecter en tant que serveur de mot de passe. D’autres protocoles existent : sserver et ssh.

cvs co <Chemin du projet> Exemple : Cvs co c:\Dev_CVS\projet_cvs Copie du projet : La commande checkout "co" permet d’avoir une copie locale du projet  il y a transfert d’une copie de ce projet à partir du référentiel dans le répertoire courant : cvs co <Chemin du projet> Exemple : Cvs co c:\Dev_CVS\projet_cvs

Update : Elle permet de mettre à jour les fichiers locaux à partir de versions situées sur le serveur : cvs update

Commit : Une fois l’utilisateur termine et vérifie son travail, il utilise la commande suivante pour enregistrer sa version dans le référentiel: cvs commit

La fusion : Problème : D'autres utilisateurs ont déjà publié une autre version : commit  il y a détection de la compatibilité entre les modifications. Si il y a compatibilité fusion avec le reste du projet dans le référentiel. • Sinon  CVS indique un conflit. Les utilisateurs le résolvent alors manuellement en se mettant d’accord pour valider la version finale.

Clients CVS : JCVS Smart CVS Intégration dans l’IDE Eclipse (Démo) Turtoise …

Démo …