Styjun

I am currently learning Maven for a specific project. In this project, I need to have multiple modules (in the sense of a collection of classes and resources) that depend on each-other. Specifically, I need a module to store the classes of a public-facing API (the API is a Java API, as the desktop program can load addons at runtime), another for a set of common classes that are shared between the client and server but that are not part of the API, and of course the client and server themselves need a module each.

Using the system that I used before Maven (IntelliJ Idea's build system), I would simply create different modules and setup dependencies using IntelliJ's GUI. This works well because I can then put the whole IntelliJ Idea project in a git repository, and keep everything nicely tracked together with no fuss and no problems.

When researching how to do this in Maven, however, I ran into some problems. Maven's documentation has a section that seems to explain how to accomplish something similar, but its technique seems to have two problems. When Each sub-project, with its own pom.xml, needs to specify the version of the other sub-projects that it depends on¹. This implies that I need to make many changes all over the project whenever the version changes. This will (hopefully) be quite frequent. As it is perfectly plausible that my project will grow to have hundreds of modules, this is obviously impractical.

Additionally, based on my other research, it seems like a Maven repository is involved in the documented technique. Specifically, it seems like when, for example, the API module is built to be included in the client and server modules it will first be placed in a local repository and then the client and server modules will retrieve it from there. This sounds problematic as the API module will also be published in a public repository (maybe Maven central, I haven't really thought about this too much -- but it will be public in a repo), and this repository step seems like it could end up building the client and server with a published jar rather than the local one, which is problematic for many reasons. (eg. if a developer is making local changes to the api jar, building half the project without those changes is a problem).

Is there some better way to combine multiple modules to mitigate these problems (versions all over the place, and getting wrong jars from repos)? Is it better to modify the technique in the linked documentation instead? Am I misunderstanding something and the problems don't exist?

I have checked DuckDuckGo and all relevant questions that I can find on StackOverflow, and none address either of the two aforementioned problems.

¹:

 <dependencies>
 <dependency>
 <groupId>com.mycompany.app</groupId>
 <artifactId>my-app</artifactId>
 <version>1.0-SNAPSHOT</version>
 </dependency>
 </dependencies>

In your multi-module project, you usually use just one version for all modules. This means that you can define dependencies between modules with <version>$project.version</version> where the property $project.version$ is resolved during the build. Maven builds all the modules in the correct order.

Regarding your first question: you can create a parent pom over your whole project. In this parent pom you can add a dependencyManagement section where you can list your own modules with their version. In your modules you then only need to specify the dependeny without the version.

Here an example:

in parent pom:

<dependencyManagement>
 <dependencies>
 <dependency>
 <groupId>yourgroup</groupId>
 <artifactId>yourmoduleA</artifactId>
 <version>3.0.1-SNAPSHOT</version>
 </dependency>
 <dependency>
 <groupId>yourgroup</groupId>
 <artifactId>yourmoduleB</artifactId>
 <version>3.0.1-SNAPSHOT</version>
 </dependency>
 </dependencies>
</dependencyManagement>

and if your module A uses module B, you can add in pom of module A

 <dependencies>
 <dependency>
 <groupId>yourgroup</groupId>
 <artifactId>yourmoduleB</artifactId>
 </dependency>
 </dependencies>