EnglishCommencer

La gestion des dépendances

Déclarer et maîtriser les bibliothèques d'un projet : gestionnaire, fichier de déclaration, versionnage sémantique, contraintes de version, dépendances transitives, portées, fichier de verrouillage et conflits de versions.

  • 21 cartes
  • 4 thèmes
  • Gratuit
Réviser ce deck

Le programme, thème par thème

Le poids de chaque thème suit celui que lui donne l'examen.

  1. Notions
  2. Questions
  3. Ranger et relier
  4. Mises en situation

Quelques cartes du deck

  • Gestionnaire de dépendances : de quoi s'agit-il ?

    Voir la réponse

    Outil qui lit la liste des bibliothèques dont un projet a besoin, les télécharge avec leurs propres besoins et les met à disposition du build.

    Maven pour Java, npm pour JavaScript, pip pour Python : il évite de copier des fichiers à la main et rend le projet reconstructible sur toute machine.

  • Quelles versions la contrainte npm ^1.4.2 accepte-t-elle parmi 1.4.1, 1.4.2, 1.5.0, 1.9.3 et 2.0.0 ?

    • 1.4.2, 1.5.0 et 1.9.3
    • 1.4.1, 1.4.2 et 1.5.0
    • 1.4.2 seulement
    • 1.4.2, 1.5.0, 1.9.3 et 2.0.0
    Voir la réponse

    1.4.2, 1.5.0 et 1.9.3

    Le caret accepte toute version au moins égale à 1.4.2 qui ne change pas le premier nombre : de 1.4.2 inclus à 2.0.0 exclu. 1.4.1 est plus ancienne, 2.0.0 casse la compatibilité.

  • Un projet Maven déclare ses dépendances dans le fichier …, alors qu'un projet npm les déclare dans le fichier ….

    Voir la réponse

    Un projet Maven déclare ses dépendances dans le fichier pom.xml, alors qu'un projet npm les déclare dans le fichier package.json.

    Les deux fichiers listent les besoins du projet et leurs versions. Le gestionnaire les lit pour calculer l'arbre complet, transitives comprises.

  • Versionnage sémantique : de quoi s'agit-il ?

    Voir la réponse

    Convention de numérotation MAJEUR.MINEUR.CORRECTIF : le premier nombre change quand on casse la compatibilité, le deuxième quand on ajoute sans rien casser, le troisième quand on corrige.

    Un numéro dit ce qu'on risque en mettant à jour : un changement de correctif ou de mineur est censé être sans danger, un changement de majeur demande de relire le code.

  • Un programme Java compile sans erreur, puis plante à l'exécution avec NoSuchMethodError, sur une méthode d'une bibliothèque qui existe bien dans la version déclarée. Quelle est la cause la plus probable ?

    • Le fichier .jar de la bibliothèque manque au classpath à l'exécution
    • Deux versions de la bibliothèque sont en jeu, et l'exécution utilise celle qui n'a pas la méthode
    • Le code source contient une faute de frappe dans le nom de la méthode
    • La mémoire de la machine virtuelle est trop faible pour charger la classe
    Voir la réponse

    Deux versions de la bibliothèque sont en jeu, et l'exécution utilise celle qui n'a pas la méthode

    Une faute de frappe aurait été refusée à la compilation, et un .jar absent donnerait NoClassDefFoundError. Une dépendance transitive a imposé une autre version de la bibliothèque : on la repère avec mvn dependency:tree, puis on fixe la bonne version ou on exclut l'autre.

Réviser ce deck