CSC 4102 – Introduction au génie logiciel pour applications orientées objet

Voici le message de la DISI pour l'accès extérieur à la forge logicielle :
« Nous avons ouvert la plateforme GitLab depuis l’extérieur du campus a un nombre limité de Fournisseurs d'Acces Internet (FAI), principalement Orange, SFR, Bouygues, Free, mais il est possible que nous n'ayons pas énuméré toutes les adresses sources dont ils disposent. Si vous avez un refus d'acces, merci de retourner à la DISI via le helpdesk l’adresse Internet (adresse IP) de votre point d’accès (box, mobile, lieu d’hébergement... ?), adresse disponible depuis votre terminal en allant sur le site https://ip.lafibre.info/, afin que la DISI adapte les filtres IP d’accès à GitLab. Retournez l'information (adresse IPv4) obtenue sur cette page en envoyant un mail: "Subject: controle d'acces IP a gitlab CSC4102, To: helpdesk@tem-tsp.eu, Body: contenu de https://ip.lafibre.info/" »

Dans le cas ou vous avez plusieurs couples de clefs (privée, publique) SSH sur votre machine (dans le répertoire ~/.ssh), ou dans le cas vous avez des clefs avec des noms personnels, il est necessaire de pouvoir choisir la clef à utiliser suivant les usages (p.ex. pour les commandes ssh et git).

• pour les commandes ssh avec une clef spécifique : ssh -i ~/.ssh/maClef ..... ;
• pour les commandes git et pour tous les dépôts Git sur la machine : git config --global core.sshCommand "ssh -i ~/.ssh/maClef -F /dev/null" 
• pour les commandes git d'un dépôt Git (uniquement) :
  • lorsque le dépôt a déjà été cloné, dans le répertoire racine du dépôt : cd ...dansledépôt ; git config core.sshCommand "ssh -i ~/.ssh/maClef -F /dev/null" ;
  • lorsque le dépôt n'est pas encore cloné, lors de la commande de clonage : git clone -c "core.sshCommand=ssh -i ~/.ssh/maClef -F /dev/null" URLIDÉPÔT.

Informations fournies par Pascal Hennequin. Merci à lui. Et discutez avec lui pour plus d'explications.

Par défaut, la branche main est dite « protected », c'est-à-dire que seuls les utilisateurs avec les droits main peuvent la modifier. Dans la configuration des projets lors de la séance 1, les encadrants possèdent les droits developer. Pour que les utilisateurs avec des droits developer puissent modifier la branche main, procédez comme suit : projet > repository > branches > project settings > protected branches > unprotect sur la branche main. Un message indiquant que les developers pourront modifier la branche main demande la confirmation.

Dans la page settings, voir le bas de la page.

• Voici l'URL de la page dans la documentation de référence de Git pour le paramétrage à la première utilisation de Git : https://git-scm.com/book/fr/v2/D%C3%A9marrage-rapide-Param%C3%A9trage-%C3%A0-la-premi%C3%A8re-utilisation-de-Git
• Dans l'énoncé du TP de la séance 1, nous utilisons l'option --global.

• Voici l'URL de la page dans la documentation de référence de Git : https://git-scm.com/book/fr/v2/Les-bases-de-Git-Enregistrer-des-modifications-dans-le-d%C3%A9p%C3%B4t

• Je cherche l'URL SSH du dépôt.
• Je clône le dépôt avec la commande git clone.
• Je choisis la branche sur laquelle travailler avec l'outil gitk --all.
• Je me déplace dans la branche choisie avec la commande git checkout.

• Je vérifie que je suis bien sur la branche en question avec la commande git branch.
  • Si j'ai des modifications non validées, je les valident. Si je ne sais pas que faire de ces modifications, je peux préferer repartir dans un nouveau répertoire et cloner dans un nouveau dépôt local.
• Je charge les dernières modifications poussées sur le dépôt d'origine/de référence avec la commande git fetch.
• Je vérifie l'état de ma branche par rapport avec ces dernières mises à jour avec l'outil gitk --all.
• Si je suis d'accord pour avancer jusqu'à la dernière image de la branche, j'avance pour me mettre à jour avec la commande git pull.
• Si je préfère partir sur une autre branche, je crée la branche et commence à travailler dessus avec la commande git checkout -b ma_nouvelle_branche.

• Je liste les répertoires et les fichiers non suivi (untracked) avec la commande git status.
• Je liste les répertoires et les fichiers qui seraient supprimés avec la commande git clean -nd
• Si je suis sûr que toutes les entrées sont à supprimer, j'utilise la commande git clean -fd

• Je liste les outils avec la commande git mergetool --tool-help.
• Nous suggérons d'utiliser l'outil meld ; pour configurer Git pour qu'il utilise meld, utilisez la commande git config --global merge.tool meld.

• Je liste ces outils avec la commande git mergetool --tool-help.
• Je vérifie ma configuration avec la commande git config --global merge.tool.
• Je configure mon dépôt pour utiliser, par exemple meld, avec la commande git config --global merge.tool meld.

• Je vérifie que le répertoire de travail est « propre », c'est-à-dire qu'il n'y a ni contenu non suivi (untracked) ni contenu modifié non validé (commit), avec la commande git status.
• Au besoin, je valide les dernières modifications avec les commandes git add et git commit.
• Je me déplace dans la branche d'arrivée, par exemple la branche main, avec la commande git checkout develop.
• Je fusionne de façon à voir un instantané qui montre la fusion, avec la commande git merge --no-ff : par exemple git merge --no-ff branche_feature_a_fusionner.
• Si des conflits sont détectés, j'exécute la commande git mergetool pour utiliser un outil aidant à la résolution du conflit : par exemple git mergetool -t meld
  • Chaque outil possède son propre mode de fonctionnement. Pour aller plus loin, nous vous conseillons de consulter la page suivante : ici

• Je liste les étiquettes existantes avec la commande git tag -l ou l'outil gitk --all.
• J'ajoute une étiquette avec la commande git tag -a : par exemple git tag -a seance1.
• Je pousse l'étiquette sur le dépôt d'origine/de référence avec la commande git push : par exemple git push origin seance1.
  • Vous pouvez pousser toutes les étiquettes avec la commande git push origin --tags, mais avec le risque de pousser des étiquettes que vous ne souhaitiez pas pousser.

• Je liste les étiquettes existantes avec la commande git tag -l ou l'outil gitk --all.
• Je supprime l'étiquette distante avec la commande git push --delete origin tag_to_remove ou la commande git push origin :tag_to_remove.
• Au besoin, je supprime l'étiquette locale avec la commande git tag -d tag_to_remove.

• Je vérifie que je n'ai pas de modifications en cours dans la branche courante ; si j'ai des fichiers en cours de modifications, je peux :
  1. (le plus simple) terminer ces modifications, les ajouter à la zone de transit (staging area) avec la commande git add et les valider avec la commande git commit, ou
  2. (pour ceux qui veulent aller plus loin) mettre de côté ces modifications avec la commande git stash.
• Je change de branche, par exemple la branche autre_branche, avec la commande git checkout autre_branche.

• Je ne veux pas faire de fusion de branche par exemple car il y aurait trop de changements. Je souhaite récupérer la dernière version, c'est-à-dire le fichier du dernier instantané (snapshot).
  • Il est possible de récupérer d'un autre instantané en indiquant dans la suite l'identifiant (SHA1) en lieu et place du nom de la branche.
• Je peux récupérer uniquement un fichier, par exemple chemin_vers_fichier/fichier_a_recuperer, d'une branche, par exemple autre_branche, avec la commande git checkout autre_branche chemin_vers_fichier/fichier_a_recuperer.
• Comme cette récupération n'est pas visible dans l'arbre des instantanés, je valide ce changement en mettant un message approprié avec la commande git commit -m "fichier_a_recuperer en provenance de la branche autre_branche".

• Je mets à jour mon dépôt local avec l'option -p (pour prune) de la commande git fetch, ce qui donne la commande git fetch -p.
  • Les anciennes branches qui n'existent plus sur le dépôt distant ont disparu.

• Je me mets sur une autre branche avec la commande git checkout autre_branche.
• Je supprime la branche sur le dépôt distant avec la commande git push origin :branche_a_supprimer (notez le caractère « : »).
• Au besoin, je supprime aussi la branche locale avec la commande git branch -d branche_a_supprimer, voire avec la commande git branch -D branche_a_supprimer même si je perds du contenu (des instantanés) par exemple parce que la branche n'a pas été fusionnée.

• La suppression de branches peut laisser des parties de graphes non incluses dans une branche : c'est du contenu « mort ». Je peux nettoyer mon dépôt avec la commande git gc.

• Vous pouvez lire ici.

• Essayez les options -s et --porcelain.

• Avec la commande git status --ignored.

• Essayez la commande git log --graph puis git log --graph --oneline.

Voici quelques informations (Michel Simatic).

Installez l'extension Markdown All in One. Lisez la documentation du site Web pour voir ce qu'apporte cette extension à l'édition de fichiers Markdown. En particuler, pour avoir une prévisualisation de votre fichier, touches Ctrl + K, puis touche V.

Voici quelques informations (Olivier Berger).

Emacs édite les fichiers Markdown à l'aide du mode markdown-mode. A priori, c'est automatique si le paquet est installé par la distribution. Sinon, on peut l'installer explicitement depuis le référentiel des paquets Emacs ELPA (dans Emacs, menu Options / Manage Emacs Packages).

Ainsi, depuis un tampon en mode Markdown, on peut faire un « live preview" » (par le menu Markdown / Preview & Export / Live Export, ou le raccourci C-c C-c l) qui ouvre une deuxième frame directement dans Emacs.

Cette visualisation correspond en fait à une conversion du fichier Markdown en HTML, et la frame est rafraîchie à chaque sauvegarde du fichier Markdown d'origine.

Voici quelques informations (Olivier Berger).

Pour que la visualisation dans Emacs mette en forme correctement les tableaux « à la » GitLab ou GitHub, il faut configurer la façon dont l'export HTML temporaire est réalisé par Emacs.

Cela est effectué en configurant la variable markdown-command d'Emacs. Par défaut, elle contient markdown (qui va lancer l'exécution de /usr/bin/markdown, qui vient du package markdown de la distribution). Si on choisit la valeur pandoc, la commande exécutée à la place est /usr/bin/pandoc, qui comprend mieux la syntaxe GitLab ou GitHub pour les tableaux. Ainsi, vous devez :

• installer le paquet pandoc de la distribution (par exemple, sudo apt install pandoc) ;
• configurer la variable markdown-command avec la commande suivante dans Emacs : M-x customize-variable 'markdown-command', et remplacer markdown par pandoc, puis utiliser le bouton "State / Save for future sessions" pour sauver cette configuration Emacs pour votre compte.

• C-x 8 RET + LOGICAL AND donne « ∧ » ;
• C-x 8 RET + LOGICAL AND donne « ∨, etc.

Voici quelques informations (Michel Simatic).

Installez l'extension Rich PlantUML support. Comme expliqué dans la documentation, pour prévisualiser un fichier contenant des instructions PlantUML (fichier d'extension « .pu »), touches Alt+D. Pour générer votre fichier au format image, clic-droit sur le contenu de votre fichier .pu, puis Export Current Diagram, puis clic-gauche sur le format de sortie souhaité (notre préférence va aux images au format vectoriel SVG). Le fichier est créé dans un sous-répertoire ayant pour nom le nom de votre fichier .pu (sans cette extension).

• Il faut ajouter l'option -ea à la commande d'exécution java.
• Dans Eclipse, deux possibilités :
  1. Pour l'exécution d'une classe ou d'un test JUnit, dans le menu Run as, choisir Run configurations..., puis ouvrir l'onglet Arguments et dans le formulaire VM arguments, ajoutez l'option -ea.
  2. Pour toutes les exécutions, dans le menu global Window/Preferences, choisir la page Java/Installed JREs, puis dans la page Edit de celle qui est sélectionnée, dans le formulaire Default VM arguments, ajoutez l'option -ea.

Une fois le contenu d'une classe ouvert, menu Source, puis generate...

L'équipe enseignante n'utilisant pas VSCode, l'information qui suit a été fournie par un étudiant. Merci donc à Gauthier Carpentier (message du Forum Moodle posté le vendredi 5 mars 2021)

« faire fonctionner les .xml avec le plugin checkstyle de VSCode (Checkstyle for Java - Visual Studio Marketplace). La solution est assez simple mais ça vous évite se chercher sur internet! Dans le fichier json de configuration du Workspace .vscode/settings.json se situant à la racine du projet. (Si vous ne l'avez pas je vous invite à le créer et n'oubliez pas de rajouter **/.vscode au .gitignore pour éviter la prise en compte du dossier de configuration par Git). Rajoutez :

Puis comme expliqué sur la page du plugin, clic droit sur le xml(version 2019) et set the checkstyle... Et voila normalement checkstyle fonctionne. PS : pour voir les logs si il y a encore des erreurs la commande est la suivante  : Ctrl + maj + p, puis Java: Open All Log Files »

• Avec la command mvn eclipse:clean eclipse:eclipse : greffon Eclipse de Maven, goals clean et eclipse.

• Les dépendances sont affichées par la commande mvn dependency:tree.

• Tout d'abord, nous avons ajouté le greffon Surefire dans le fichier pom.xml pour exécuter les tests avec Junit. Ce greffon génère un rapport pour chaque exécution d'une classe de tests. Nous trouvons les informations sur l'exécution des tests dans le répertoire target/surefire-reports.

• En ajoutant les options suivantes à la ligne de commande « mvn clean install » :
  • -DskipTests : les tests ne sont pas exécutés, mais sont compilés ;
  • -Dmaven.test.skip=true : les tests ne sont pas compilés, et donc non exécutés.

• En ajoutant l'option « -Dmaven.javadoc.skip=true » à la ligne de commande « mvn clean install ».

• Javadoc de l'API

• Site Maven

• Cf. le paquetage eu.telecomsudparis.csc4102.utilisationdelabibliothequeutil du projet GitLabEns des exemples.