Scribd
Upload
26 views2 pages

Maven "Convention Over Configuration" Example: An Illustration of This Notion Inside The Maven

The document discusses how Maven uses conventions like standardized directory structures and naming strategies to simplify project configuration. It provides an example of corrections made to a POM file fragment and explains how Maven uses version ranges in dependencies to provide flexibility.

Uploaded by

Techloggie Production
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
26 views2 pages

Maven "Convention Over Configuration" Example: An Illustration of This Notion Inside The Maven

The document discusses how Maven uses conventions like standardized directory structures and naming strategies to simplify project configuration. It provides an example of corrections made to a POM file fragment and explains how Maven uses version ranges in dependencies to provide flexibility.

Uploaded by

Techloggie Production
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 2

A.

Tools such as Java play an essential part in the automation and efficiency of the process of
developing software. These tools assist in the management of project dependencies,
compilation of source code, execution of tests, packaging of the application, and facilitation of
other stages within the build process. Maven adheres to the notion of "convention above
configuration," wherein it imposes a predefined set of rules and defaults in order to streamline
project setup.

Maven "convention over configuration" example: An illustration of this notion inside the Maven
framework is the use of a standardized directory structure. By default, Maven assumes that the source
code is located in the "src/main/java" directory, the resources are stored in the "src/main/resources"
directory, and the tests are placed in both the "src/test/java" and "src/test/resources" directories. The
software adheres to a consistent naming strategy for both sources and test files. Developers are not
required to explicitly define these parameters; Maven leverages these standards to perform tasks like as
compiling, testing, and packaging the project.

B. Fragment with corrections: This pom file fragment is repaired.:

<reporting>

<plugins>

<plugin>

<groupId>org.apache.maven.plugins</groupId>

<artifactId>maven-project-info-reports-plugin</artifactId>

<version>3.1.2</version>

<dependencies>

<dependency>

<groupId>massey.ac.nz.se.foo</groupId>

<artifactId>foo-foo</artifactId>

<version>1.0.0</version>

</dependency>

<dependency>

<groupId>massey.ac.nz.se.bar</groupId>

<artifactId>bar-bar</artifactId>

<version>1.11.5</version>

<scope>test</scope>

</dependency>
</dependencies>

</plugin>

</plugins>

</reporting>

Corrections and explanations:

The <reporting> element should include <plugins> and <plugin> elements.

Add <dependencies> tag to <plugin> to define plugin dependencies.

Included <version> tags for both dependencies (e.g., "1.0.0" for "foo-foo").

C. Explaining Maven Dependency Versioning: The Maven dependency specifies JUnit Jupiter version
"[5.6.0,5.7.0)." The "version ranges" or "version intervals" versioning technique provides for flexible
compatibility selection.

Here, "[5.6.0,5.7.0)" says the dependency will use any JUnit Jupiter version between 5.6.0 and 5.7.0. The
square brackets "[]" contain the boundary values (5.6.0 and 5.7.0), whereas the parenthesis "()" expand
the range and exclude the specified versions.

This technique allows any compatible version within the given range, providing flexibility. Maven will use
the latest version (5.6.0 <= version < 5.7.0) during dependency resolution if there are several versions
available.

You might also like