FrançaisGet started

Dependency management

Declaring and controlling a project's libraries: manager, declaration file, semantic versioning, version constraints, transitive dependencies, scopes, lockfile and version conflicts.

  • 21 cards
  • 4 topics
  • Free
Study this deck

The outline, topic by topic

Each topic is weighted the way the exam weighs it.

  1. Concepts
  2. Questions
  3. Sort and link
  4. Scenarios

A few cards from the deck

  • Dependency manager: what is it?

    Show the answer

    A tool that reads the list of libraries a project needs, downloads them along with their own needs and makes them available to the build.

    Maven for Java, npm for JavaScript, pip for Python: it avoids copying files by hand and makes the project rebuildable on any machine.

  • Which versions does the npm constraint ^1.4.2 accept among 1.4.1, 1.4.2, 1.5.0, 1.9.3 and 2.0.0?

    • 1.4.2, 1.5.0 and 1.9.3
    • 1.4.1, 1.4.2 and 1.5.0
    • 1.4.2 only
    • 1.4.2, 1.5.0, 1.9.3 and 2.0.0
    Show the answer

    1.4.2, 1.5.0 and 1.9.3

    The caret accepts any version at least 1.4.2 that does not change the first number: from 1.4.2 included to 2.0.0 excluded. 1.4.1 is older, 2.0.0 breaks compatibility.

  • A Maven project declares its dependencies in the … file, whereas an npm project declares them in the … file.

    Show the answer

    A Maven project declares its dependencies in the pom.xml file, whereas an npm project declares them in the package.json file.

    Both files list the project's needs and their versions. The manager reads them to work out the full tree, transitive ones included.

  • Semantic versioning: what is it?

    Show the answer

    A numbering convention MAJOR.MINOR.PATCH: the first number changes when compatibility breaks, the second when something is added without breaking anything, the third when a bug is fixed.

    A number says what you risk by updating: a patch or minor change is meant to be safe, a major change calls for rereading the code.

  • A Java program compiles without error, then crashes at run time with NoSuchMethodError, on a method of a library that does exist in the declared version. What is the most likely cause?

    • The library's .jar file is missing from the classpath at run time
    • Two versions of the library are involved, and run time uses the one without the method
    • The source code has a typo in the method name
    • The virtual machine's memory is too low to load the class
    Show the answer

    Two versions of the library are involved, and run time uses the one without the method

    A typo would have been rejected at compile time, and a missing .jar would give NoClassDefFoundError. A transitive dependency imposed another version of the library: spot it with mvn dependency:tree, then pin the right version or exclude the other.

Study this deck