Apache Maven Essentials Quiz Quiz

Explore the key concepts, structure, and features of Apache Maven, including POM elements, conventions, dependency management, and multi-module builds.

1. Maven Conventions

   Where does Maven expect your main source code to be located by default?

   1. main/src/java
   2. src/app/source
   3. src/main/java
   4. code/java/main

   Explanation: Maven relies on conventions, placing main source code in 'src/main/java' by default. The other listed directories do not match Maven's standard structure and would require special configuration.

2. Understanding the POM

   Which file acts as the blueprint and core configuration file for a Maven project?

   1. manifest.json
   2. pom.xml
   3. build.gradle
   4. settings.cfg

   Explanation: The 'pom.xml' file defines the Maven project's configuration. 'build.gradle' belongs to Gradle, and 'settings.cfg' and 'manifest.json' are unrelated to Maven.

3. Project Identity

   What does 'artifactId' represent in the Maven POM's GAV coordinates?

   1. The organization creating the project
   2. The version of the overall POM model
   3. The name of the primary artifact the project produces
   4. A list of test resources

   Explanation: 'artifactId' specifies the base name of the main output artifact. 'groupId' is for the organization, 'version' is the artifact version, and test resources have their own configuration.

4. Dependency Scope

   In Maven, what does setting a dependency's scope to 'test' mean?

   1. The dependency is included in the production build
   2. The dependency is used only for compiling and running tests
   3. The dependency is downloaded but never used
   4. The dependency replaces all other scopes

   Explanation: A 'test' scope makes the dependency available only during the test phase. Production builds exclude these. Dependencies are not unused or overriding all scopes.

5. Default Output Location

   What is the default directory where Maven places compiled build output?

   1. builds/
   2. output/
   3. bin/
   4. target/

   Explanation: By default, Maven puts compiled classes and packaged artifacts into 'target/'. The other directory names are common in other tools but not in Maven's conventions.

6. Dependencies List

   Which XML tag wraps the complete set of libraries a Maven project relies on?

   1. <modules>
   2. <dependencies>
   3. <properties>
   4. <plugins>

   Explanation: <dependencies> is the container for all external libraries. <plugins> is for build tools, <modules> for subprojects, and <properties> for variable values.

7. Using Properties

   How can you re-use a version number across different dependencies in the Maven POM?

   1. Hard-code the version in each dependency tag
   2. Use the <module> tag for versions
   3. Define a property and reference it where needed
   4. Rely on Maven magic without configuration

   Explanation: Using <properties> lets you define a version once and reference it throughout. Hard-coding loses maintainability, <module> is unrelated to versions, and Maven needs explicit setup for this feature.

8. Customizing the Build Artifact

   Which tag in the build section of the POM allows you to set the output file's name?

   1. <scope>
   2. <id>
   3. <phase>
   4. <finalName>

   Explanation: <finalName> customizes the generated artifact's name. <id> is used elsewhere, <scope> is for dependency usage, and <phase> relates to lifecycle execution.

9. Multi-Module Builds

   Which tag lists all sub-projects in a Maven multi-module build?

   1. <plugin>
   2. <parent>
   3. <modules>
   4. <artifactId>

   Explanation: <modules> enumerates child modules to be built together. <parent> declares inheritance, <artifactId> is for naming, and <plugin> is for build tools.

10. Managing Dependency Versions

    How can a parent POM control dependency versions for its child modules without including the dependencies themselves?

    1. <dependencyManagement>
    2. <resource>
    3. <dependencies>
    4. <build>

    Explanation: <dependencyManagement> centrally defines versions for dependencies used by child modules. <dependencies> actually includes libraries, <resource> and <build> are not for managing versions.