Maven: "dependency vs module " - maven

Question

I would like to know the difference between the two. From what I understand the dependency needs a version etc but modules can be defined without the version and it takes the parent's version. Is there more to it?

Answer 1

A dependency and a module are different concepts.
From the Maven book about dependencies:
Maven can manage both internal and external dependencies. An external dependency for a Java project might be a library such as Plexus, the Spring Framework, or Log4J. An internal dependency is illustrated by a web application project depending on another project that contains service classes, model objects, or persistence logic.
Put simply, a dependency is saying: "To build my project, I need to use this library".
A dependency in Maven is defined by its coordinates, that are made of 4 elements:
groupId: The groupId groups a set of related artifacts. It generally resemble a Java package name. For example, the groupId org.apache.maven is the base groupId for all artifacts produced by the Apache Maven project.
artifactId: The artifactId is the project main identifier. When you generate an artifact, this artifact is going to be named with the artifactId. The artifactId, groupId combination must be unique. In other words, you can't have two separate projects with the same artifactId and groupId. Furthermore, you can't have the same artifactId for a given groupId.
version: When an artifact is released, it is released with a version number, such as "1.0", "1.1.1", or "1.1.2-alpha-01". You can also use what is known as a snapshot version for a component which is under development, like "1.0-SNAPSHOT".
classifier: A classifier is not needed and is generally not used. It is only relevant when you need to produce several artifacts from a single project: it then serves as a distinction in the file names, that otherwise would be made simply with the artifactId and version and thus conflicts.
In the POM, it looks like this:
<project xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
https://maven.apache.org/xsd/maven-4.0.0.xsd">
...
<dependencies>
<dependency>
<groupId>org.some.project</groupId>
<artifactId>my-project</artifactId>
<version>4.0</version>
</dependency>
...
</dependencies>
...
</project>
This declares a dependency to the my-project library identified by the given coordinates.
A module is used in the context of multi-module Maven project. From the Maven book:
A multimodule project simply manages a group of other subprojects or modules. [...] When setting up a multimodule project, you are simply telling a project that its build should include the specified modules. Multimodule builds are to be used to group modules together in a single build.
Put simply, having a module is saying "To build my project, I need to build this project".
In the POM, this is done like this:
<project xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
https://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>org.codehaus.mojo</groupId>
<artifactId>my-parent</artifactId>
<version>2.0</version>
<packaging>pom</packaging>
<modules>
<module>my-project</module>
<module>another-project</module>
</modules>
</project>
You are saying that this project, identified by org.codehaus.mojo:my-parent:2.0:pom, declared 2 modules which are my-project and another-project. Thus, when you build my-parent, those two modules will also be built.

Answer 2

Conceptually they're different, but they go hand-in-hand as well.
All of them parents, modules and libraries are referenced, by convention, using a unique name composed of a group-id, artifact-id and version. Unless you need otherwise (seldom happened to me) a module can indeed inherit its version from the parent but you do have the option of changing it.
A maven module is like a sub-project of your project. It allows you to separate a big projects into smaller parts which can be managed individually, and in the end aggregated to build whatever you require. We could picture a car as the end product, being composed of several modules such as engine, wheels, chairs etc.
A dependency is a library your project or module requires to compile and/or function. Coming back to our car, it's true that it requires an engine module to function. However, the current version of the engine itself requires a certain type (version) of pistons to run correctly. Too big and they won't fit, too small and it won't work at all.
Applied to a java project, you can imagine having several modules which access a DB, call some web services, provide an UI, all of them linked together by their parent. Also the DB module will probably require a certain DB driver (MYSql, Oracle, etc), matching the version of the DB you're using, and the web service module an HTTP library, and so on.